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(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org