[libvirt] [PATCHv4 12/18] blockjob: implement block copy for qemu

Jiri Denemark jdenemar at redhat.com
Mon Apr 16 14:05:10 UTC 2012


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




More information about the libvir-list mailing list