libvirt users - Sep 2015 - Re: Backup a VM (using live external snapshot and blockcommit)

Hi Eric.

Thank you so much for your quick and relieving answer.

Le 2015-09-11 17:05, Eric Blake a écrit :
> Yes, using active block-commit is the ideal way to perform a live backup.
Great.
> Yep, that about covers it.  Note that the --quiesce step in snapshot
> creation requires qemu-guest-agent running in the guest, and that you
> trust interaction with your guest.
Yes, I think I get this. I don't really figure out what these cases
could be. We're using Debian Jessie and I installed qemu-guest-agent.
Other VM could use other systems, but most likely Linux based.

Do you mean that, in cases where you shouldn't trust the guest, using
'--quiesce' might end up being worse than nothing? Or just useless?
 
>> -> Anything wrong about my snapshot-create-as and blockcommit
command
>> lines? May I remove the snapshot with only a rm command?
> 
> Looks correct to me, and matches my recent KVM Forum slides:
>
http://events.linuxfoundation.org/sites/events/files/slides/2015-qcow2-expanded.pdf
I'll have a look at these, thanks.
 
>> Now, a few side questions, as I might have messed up with the VM I was
>> experimenting with.
>>
>> I used the same command lines as described above, except I didn't
pass
>> the '--no-metadata' option. Once the backing file was copied, I
deleted
>> the snapshot qcow2 file and thought I was done with it, until I
realized
>> the snapshot was still listed by virsh snapshot-list. And I
couldn't
>> find a way to delete it. (For the record, I asked on serverfault about
>> that [3].)
> 
> virsh snapshot-delete --metadata $dom $badname
> 
> to remove $badname snapshot that no longer exists because you changed
> things behind the scenes.
Before removing the .xml file, I tried the command indicated in the wiki
[1] with no success.

"NOTE-2: Optionally, you can also supply '--no-metadata' option to
tell
libvirt to not track the snapshot metadata -- this is useful currently
as at a later point when you merge snapshot files, then you have to
explicitly clean the libvirt metadata (by invoking: virsh
snapshot-delete vm1 --delete --current -- repeat this as needed.)"

Shouldn't the 

    virsh snapshot-delete vm1 --delete --current

be rephrased as 

    virsh snapshot-delete vm1 --metadata --current 

?

I see '--delete' is not listed in the man.

Or even

    virsh snapshot-delete vm1 --metadata $badname

since after the blockcommit, the snapshot is unused, I'm not sure it is
considered current.

Anyway, I'm glad you confirm I now have the correct sequence.

Thanks again.

Enjoy the WE.

[1]
http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit

-- 
Jérôme

On 09/11/2015 10:18 AM, Jérôme wrote:
>> Yep, that about covers it.  Note that the --quiesce step in snapshot
>> creation requires qemu-guest-agent running in the guest, and that you
>> trust interaction with your guest.
> 
> Yes, I think I get this. I don't really figure out what these cases
> could be. We're using Debian Jessie and I installed qemu-guest-agent.
> Other VM could use other systems, but most likely Linux based.
qga with support for quiesce has also been ported to Windows guests.
> 
> Do you mean that, in cases where you shouldn't trust the guest, using
> '--quiesce' might end up being worse than nothing? Or just useless?
If the agent is not running, using --quiesce will fail the entire
command; you'd learn pretty quickly to retry without --quiesce for
guests that don't know how to handle it. . But if the guest is
malicious, it can pretend to be a guest agent, but intentionally refuse
to reply to the --quiesce request, and leave libvirt hung waiting for a
reply.  So it boils down to whether you trust your guests to be
reasonable with their guest agent connection (fine if it is your own
guests, not so much if you are hosting a cloud for other people's guests).
>  
>>> -> Anything wrong about my snapshot-create-as and blockcommit
command
>>> lines? May I remove the snapshot with only a rm command?
>>
>> Looks correct to me, and matches my recent KVM Forum slides:
>>
http://events.linuxfoundation.org/sites/events/files/slides/2015-qcow2-expanded.pdf
> 
> I'll have a look at these, thanks.
The libvirt commands were towards the end, in part 3; but the first two
parts might give a better understanding of the overall operations of
what is happening.

>> virsh snapshot-delete --metadata $dom $badname
>>
>> to remove $badname snapshot that no longer exists because you changed
>> things behind the scenes.
> 
> Before removing the .xml file, I tried the command indicated in the wiki
> [1] with no success.
> 
> "NOTE-2: Optionally, you can also supply '--no-metadata'
option to tell
> libvirt to not track the snapshot metadata -- this is useful currently
> as at a later point when you merge snapshot files, then you have to
> explicitly clean the libvirt metadata (by invoking: virsh
> snapshot-delete vm1 --delete --current -- repeat this as needed.)"
> 
> Shouldn't the 
> 
>     virsh snapshot-delete vm1 --delete --current
> 
> be rephrased as 
> 
>     virsh snapshot-delete vm1 --metadata --current 
Yep, sounds like a bug in the wiki, so I fixed it.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[. . .]

On Fri, Sep 11, 2015 at 10:45:34AM -0600, Eric Blake
wrote:
> On 09/11/2015 10:18 AM, Jérôme wrote:
> 
> >> Yep, that about covers it.  Note that the --quiesce step in
snapshot
> >> creation requires qemu-guest-agent running in the guest, and that
you
> >> trust interaction with your guest.
> > 
> > Yes, I think I get this. I don't really figure out what these
cases
> > could be. We're using Debian Jessie and I installed
qemu-guest-agent.
> > Other VM could use other systems, but most likely Linux based.
> 
> qga with support for quiesce has also been ported to Windows guests.
> 
> > 
> > Do you mean that, in cases where you shouldn't trust the guest,
using
> > '--quiesce' might end up being worse than nothing? Or just
useless?
> 
> If the agent is not running, using --quiesce will fail the entire
> command; you'd learn pretty quickly to retry without --quiesce for
> guests that don't know how to handle it. . But if the guest is
> malicious, it can pretend to be a guest agent, but intentionally refuse
> to reply to the --quiesce request, and leave libvirt hung waiting for a
> reply.  So it boils down to whether you trust your guests to be
> reasonable with their guest agent connection (fine if it is your own
> guests, not so much if you are hosting a cloud for other people's
guests).
> 
> >  
> >>> -> Anything wrong about my snapshot-create-as and
blockcommit command
> >>> lines? May I remove the snapshot with only a rm command?
> >>
> >> Looks correct to me, and matches my recent KVM Forum slides:
> >>
http://events.linuxfoundation.org/sites/events/files/slides/2015-qcow2-expanded.pdf
> > 
> > I'll have a look at these, thanks.
Yes, I highly recommend it.  This talk gives an excellent under-the-hood
details of virtual machine disk image backing chain management.
Associated video:

    https://www.youtube.com/watch?v=etIGp12RHRE
> The libvirt commands were towards the end, in part 3; but the first two
> parts might give a better understanding of the overall operations of
> what is happening.
> 
> 
> >> virsh snapshot-delete --metadata $dom $badname
> >>
> >> to remove $badname snapshot that no longer exists because you
changed
> >> things behind the scenes.
> > 
> > Before removing the .xml file, I tried the command indicated in the
wiki
> > [1] with no success.
> > 
> > "NOTE-2: Optionally, you can also supply '--no-metadata'
option to tell
> > libvirt to not track the snapshot metadata -- this is useful currently
> > as at a later point when you merge snapshot files, then you have to
> > explicitly clean the libvirt metadata (by invoking: virsh
> > snapshot-delete vm1 --delete --current -- repeat this as
needed.)"
> > 
> > Shouldn't the 
> > 
> >     virsh snapshot-delete vm1 --delete --current
> > 
> > be rephrased as 
> > 
> >     virsh snapshot-delete vm1 --metadata --current 
> 
> Yep, sounds like a bug in the wiki, so I fixed it.
Indeed, it was a typo.  I didn't even notice it until now as I just type
these commands from muscle memory.

Thanks, Eric, for fixing it (and for all the detailed responses).

-- 
/kashyap

Le Fri, 11 Sep 2015 10:45:34 -0600,
Eric Blake <eblake@redhat.com> a écrit :
> But if the guest is
> malicious, it can pretend to be a guest agent, but intentionally
> refuse to reply to the --quiesce request, and leave libvirt hung
> waiting for a reply.  So it boils down to whether you trust your
> guests to be reasonable with their guest agent connection (fine if it
> is your own guests, not so much if you are hosting a cloud for other
> people's guests).
Of course. I didn't think of this use case.
 
> >     virsh snapshot-delete vm1 --metadata --current 
> 
> Yep, sounds like a bug in the wiki, so I fixed it.
I thought so but didn't dare to be too affirmative about it.

Glad it is fixed. Hopefully, it will save someone some time and
trouble. Let this be my micro-contribution...

Thanks again.

-- 
Jérôme