> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list