On Fri, Apr 13, 2012 at 09:15:18 -0600, Eric Blake wrote:
On 04/13/2012 08:46 AM, Jiri Denemark wrote:
> I guess I wasn't paying enough attention somewhere but why do we forbid block
> copy for persistent domains? I understand why we want to forbid certain
> operations when block copy is active but I don't see a reason for penalizing
> persistent domains.
It was in patch 8/18 where I added the restrictions, and hopefully
documented in that commit message why limiting things to transient is a
good first step:
1. the first client of live migration is oVirt, which uses transient domains
2. qemu does not (yet) provide a way to resume a mirror when restarting
a domain, so anything that would require restoring a domain from saved
state is broken: incoming migration, virsh restore, and virsh start
after a managed save. But users would be upset if they saved a domain,
only to find out that they cannot then restore it, so I squelched things
one step earlier in the process, by preventing any save of a domain so
that we never have a broken save image in the first place.
My worry now comes from the fact that managedsave is on the list of
forbidden operations. If a domain is transient, managedsave is already
forbidden (it is assumed that you either don't care about the domain if
the host dies, or that you are running a higher-level app like oVirt
that knows how to rebuild the guest on a different host). But if a
guest is persistent, and you use the libvirt-guests init script, then
Yeah, this was the part I didn't see. Failing manually issued commands is fine
but failing managedsave called from libvirt-guests during host shutdown/reboot
is not nice. I agree with forbidding block copy for persistent domains then.
Jirka