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

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.