On 06/23/2011 07:03 AM, Daniel P. Berrange wrote: > On Thu, Jun 23, 2011 at 06:52:47AM -0600, Eric Blake wrote: >> On 06/23/2011 04:58 AM, Daniel P. Berrange wrote: >>> I am building an application which uses KVM to run specific tasks, rather >>> than as a general purpose guest OS. I want to ensure that when the app >>> exits, the guest goes away too. To enable this, this series introduces >>> the concept of 'autokill', whereby a guest is forcably destroyed when >>> the virConnectPtr that launched it closes. This also lets us fix a long >>> standing problem with migration leaving an unkillable guest >> >> Cool! >> >> How does this interact with migration? If a domain is currently marked >> autokill on the source, should that mean that attempts to migrate it are >> forbidden (since the connection to the source would end up being useless >> after the migration, at which point the connection is gone and autokill >> should kick in)? > > That's a good point. I reckon we should forbid migration and save/restore > for such guests. save/restore might work, if you keep the connection alive in the meantime; but seeing as how save is basically a form of migration (to a file rather than to another host), it's probably easier to just forbid that as well, and state that an autokill guest is one-shot. And another thought - it might be nice to expose the qemu -snapshot option, which creates a throwaway run of a guest (where all the disks are snapshotted prior to running any guest code, then when qemu exits the state rolled back to that snapshot). Seems like a new flag could easily expose this feature, and that it would either imply autokill or often be used with autokill. -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 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