On 05/23/2014 08:54 AM, Eric Blake wrote: > For this to work, a > persistent guest definition needs to record the offset that was in use > at the time the guest powered off, and the next time qemu is started, > pass _that_ offset as the command-line offset against UTC. In libvirt's > case, we intentionally run qemu to stay alive even after the guest > quits, and send an event that the guest is no longer running; this event > could be our trigger to read the qemu offset and adjust the persistent > state to track the new offset to use on the next boot of the guest. Hmm, I wonder if we have a libvirt design dilemma on our hands. Remember, ever since qemu exposed the -no-shutdown flag, we have been using it in libvirt. It says that even though the guest has quit executing, the qemu process must stick around until we explicitly let go of it. This is because the guest can shut down during a libvirtd restart, so the new libvirtd can still connect to the qemu process, learn that the guest has shut down, and take appropriate actions (query qemu for other details like the final state of the RTC offset, tidy up any transient XML, generate the libvirt event to management app, etc). As long as the libvirt guest is persistent, the management app can still query about the guest even after it shuts down. But VDSM uses only transient guests. Similar to how libvirt uses -no-shutdown to keep qemu hanging around until libvirt acknowledges that the guest is done, what recourse does VDSM have to keep a transient guest's virDomainPtr around (even across libvirtd restarts) until VDSM has had time to query the RTC offset from libvirt? That is, since the only libvirt use of RTC offset is to adjust the persistent definition for the next boot, but VDSM is using only transient guests, VDSM needs a way to track the RTC offset to tell libvirt to use the next time VDSM creates a new transient guest for the same disk image. Or put another way, the moment that libvirt offloads persistence to a higher level application, that higher level application needs a way to grab all information that libvirt would have grabbed for a persistent guest, which means a transient guest needs to exist in the shutoff state for at least as long as VDSM hasn't closed it. Do we have a design flaw in that currently libvirt gets rid of transient guests as soon as they shutdown, rather than waiting for management to close their last reference to the shutdown domain? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list