[libvirt] bug: try to take disk snapshot for LVM2 Volume

[Eric Blake]

On 09/29/2011 11:26 PM, MATSUDA, Daiki wrote:
> I tried the new snapshot function implemented by Eric Blake.
> 
> It works very well for QCOW2 disk image system.
> But I often use LVM2 volume for QEMU virtual machines and tried to take
> disk snapshot by virsh command ( snapshot-create DOMNAME --disk-only).
> So, finally qemu monitor command 'snapshot_blkdev' accepts the LVM2
> volume and create QCOW2 snapshot image. In addition, domain's
> configuration file is replaced to use snapshot disk image instead of
> LVM2 volume.

It sounds like virsh did what it was told, but that you told it so
little information that it had to fill in the gaps and choose its own
destination file name (hence the .1317357844 suffix after the action).
Your situation sounds like a case where you may want a bit more control
over the destination file name.

> 
> configuration file
> from
> ....
> <disk type='block' device='disk>
>    <driver name='qemu' type='raw' cache='none'/>
>    <source dev='dev/VG1/LVM2_dom'/>
> ....
> 
> to
> <disk type='block' device='disk>
>    <driver name='qemu' type='qcow2' cache='none'/>
>    <source dev='dev/VG1/LVM2_dom.1317357844'/>

Are you pasting literal chunks, or retyping this?  You're missing the /
in front of dev/VG1, so I can't help but wonder what else might have
been mistyped.

>
> After then, the domain runs well till it is shutdowned.

I'm surprised that it got that far - generally, libvirt can't create
random regular files under the /dev/VG1/ device-mapper hierarchy, and if
a file can't be created, then what was open() doing, and what did qemu
actually do?  It may be worth looking at lsof says that qemu has open,
if you still have it running.  Or it may be that you've found a bug in
libvirt and/or qemu for not accurately reporting failure to create the
snapshot image.

I think we need to step back a bit and look at the bigger picture.  Do
you want your new qcow2 file to be its own LVM volume (in which case,
I'd suggest that you pre-create the LVM volume, and pass in the file
name within /dev/VG1/ of the existing block device to use), or are you
okay with it being a regular file (in which case, I'd suggest that you
do not pre-create the file, but that you still pass in the desired
filename to some absolute path that lives outside of /dev/)?

Either way, it sounds like you do _not_ want libvirt to be generating
its own filename, since libvirt only knows how to generate a name in the
same directory as the snapshot is taking place, but your lvm is in a
special directory.  To do this, you either need to create an XML file
yourself, and call 'virsh snapshot-create dom --disk-only file', or you
need to have virsh create the xml for you with 'virsh snapshot-create-as
dom --disk-only vda,file=/path/to/file'.  You can see the xml that
snapshot-create-as would generate (in case you need to further fine-tune
it for your own use in snapshot-create) via the --print-xml option.

> I started the
> domain, but it does not with following error
> virtsh # start LVM2_dom
> error: Failed to start domain LVM2_dom
> error: 内部エラー Process exited while reading console log output: char
> device redirected to /dev/pts/7
> qemu: could not open disk image /dev/VG1/LVM2_dom.1317357844: Invalid
> argument.

That makes sense, if that file doesn't exist (but why qemu didn't reject
the snapshot in the first place still remains to be investigated).

> 
> I think that if the volume but qcow2 is given libvirt should be refuse,

No, qemu does just fine with a non-qcow2 backing file.  The real problem
here is that the new qcow2 file was not created, not the type of the
original file.

> e.g. in qemuDomainSnapshotCreateDiskActive() with voulme driver type.
> But currently the structures concerning with snapshot or disk has no
> member to hold such a volume driver information. In addition, as we want
> to add the LVM2 and other volume snapshot function, we hope you add its
> information and fix.

Yes, I have much longer-term plans for refactoring device snapshots to
move the work into more virStorageVolPtr operations, and teach
virDomainSnapshotCreateXML to reuse virStorageVol actions rather than
hard-coding the actions itself, at which point we can then use lvm
snapshots rather than qcow2 snapshots.  But that's a lot more effort, so
no promise of how long it will take me to get to that point.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org