Destroy is neither synchronous nor guaranteed. It's a request to the
hypervisor that isn't completed until all of the memory is completely
unmapped by any other domain that may be mapping it.
If you want to be really robust, you shouldn't assume that the domain is
actually destroyed after doing a destroy. The race conditions, in
practice, are usually very small but they are still there.
Regards,
Anthony Liguori
On Tue, 26 Sep 2006 18:07:06 -0400, Lon Hohberger wrote:
> i686
>
> libvirt-0.1.5-3
> xen-3.0.2-33
>
> Code:
>
> domain_desc = virDomainGetXMLDesc(vdp, 0); response =
> virDomainDestroy(vdp);
> if (response == 0 && domain_desc) {
> /* sleep(3); */
> virDomainCreateLinux(vp, domain_desc, 0);
> free(domain_desc);
> }
> }
> If I add the 'sleep()', the domain dies and virDomainCreateLinux() fails
> with the following error:
>
> libvir: Xen Daemon error : POST operation failed: No such domain
> futon1
> Failed to get devices for domain futon1
>
> That really doesn't bother me, and it's likely my fault anyway (it's not a
> fully configured domain; it's a dom-U sitting in the anaconda install
> screen). Of course, it's moot if we get a guaranteed synchronous reboot
> flag for virDomainReboot()... hint hint ;)
>
> What bothers me is that if I *don't* put the sleep in, the domain never
> actually gets destroyed. In this particular case, the domain is still
> sitting at the anaconda install screen; all I have to do is reconnect
> using xm console.
>
> If I only do a virDomainDestroy(), the domain gets destroyed. So, it
> looks like like the virDomainCreateLinux() cancels the destroy request
> before it can be completed.
>
> This makes it look like that the destroy request is not synchronous,
> and/or the result of the operation is not guaranteed (only that the
> request was made). Is it supposed to work this way, or is this a
> bug/problem?
>
> -- Lon