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

[MATSUDA, Daiki]

> 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.

virsh outputs
virsh # snapshot-create LVM2_dom --disk-only
Domain snapshot 1317357844 created

And I confirmed that the qcow2 image file is created under /dev/VG1
# file /dev/VG1/LVM2_dom.1317357844
/dev/VG1/LVM2_dom.1317686816: Qemu Image, Format: Qcow , Version: 2

>> 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.

I am sorry. They are my mistyping and correct is '/dev/VG1/LVM2_dom' and
'/dev/VG1/LVM2_dom.1317357844'.

>> 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.

But in reality the file is created by qemu-kvm with snapshot_blkdev in
qemu-monitor command. I use libvirt-0.9.6 and qemu-kvm-0.12.12.1.2-2.160
and August's snapshot.

> 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/)?

No, I do not want qcow2 file on LVM volume. I found the bug at simply
tesing. I will never create the snapshot with 'snapshot-create ...
--disk-only' for LVM2 volume, but users will try... So, I think that it
is better not to refuse in libvirt.

> 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.

At least its phenomenon is reproduced easily. So I hope you test.

>> 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.

Okay, if possible, I hope you to show the schedule ?

Regards
MATSUDA, Daiki