On 7/20/25 19:04, Roman Bogorodskiy wrote:
> Currently, virBhyveProcessStop() uses the virDomainDeleteConfig()
> helper to clean up domain status. It passes BHYVE_STATE_DIR as
> a configuration dir and NULL as autostart dir, so the helper does its
> job, even though it has a different purpose. However, the issue is that
> it also resets the autostart (and autostartOnce) property.
> 
> This results in a situation that when a persistent domain with autostart
> enabled gets destroyed, its autostart state is reported as disabled,
> which is not correct.
> 
> To fix that, implement the bhyveProcessRemoveDomainStatus() which
> removes the status file without side effects on the virDomainObj object.
> 
> Signed-off-by: Roman Bogorodskiy <bogorods...@gmail.com>
> ---
>  src/bhyve/bhyve_process.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/src/bhyve/bhyve_process.c b/src/bhyve/bhyve_process.c
> index 5e77a9c4d6..79be6f7aba 100644
> --- a/src/bhyve/bhyve_process.c
> +++ b/src/bhyve/bhyve_process.c
> @@ -427,6 +427,17 @@ virBhyveProcessStart(bhyveConn *driver,
>      return virBhyveProcessStartImpl(driver, vm, reason);
>  }
>  
> +static void
> +bhyveProcessRemoveDomainStatus(const char *statusDir,
> +                               const char *name)
> +{
> +    g_autofree char *file = virDomainConfigFile(statusDir, name);
> +
> +    if (unlink(file) < 0 && errno != ENOENT && errno != ENOTDIR)
> +        VIR_WARN("Failed to remove domain XML for %s: %s",
> +                 name, g_strerror(errno));

Nit pick, since this body is more than one line long, please wrap it in
curly braces.

> +}
> +
>  int
>  virBhyveProcessStop(struct _bhyveConn *driver,
>                      virDomainObj *vm,
> @@ -483,7 +494,7 @@ virBhyveProcessStop(struct _bhyveConn *driver,
>  
>   cleanup:
>      virPidFileDelete(BHYVE_STATE_DIR, vm->def->name);
> -    virDomainDeleteConfig(BHYVE_STATE_DIR, NULL, vm);
> +    bhyveProcessRemoveDomainStatus(BHYVE_STATE_DIR, vm->def->name);
>  
>      return ret;
>  }

Reviewed-by: Michal Privoznik <mpriv...@redhat.com>

Michal

Reply via email to