On 06/23/2011 07:11 AM, Eric Blake wrote:
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.
Oops. As implemented, the documentation states that autodestroy domains
cannot be saved, but the qemu code allows that, while instead enforcing
that autodestroy domains cannot be suspended (paused). I think we
botched that. And while fixing it, I'm going to also make autodestroy
domains reject use with snapshots (another use of the one-shot principle
- save/restore is a special case of snapshot/revert).
(Can you tell that I revisited this email because it mentions qemu
-snapshot, and then started thinking about the ramifications with my
recent snapshot work? :)
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org