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

On 11/15/2011 03:48 PM, MATSUDA, Daiki wrote: Here, I'm assuming /dev/sdc is the LVM volume. But here, since you failed to use the --xmlfile option with XML describing the new qcow2 file name (or used snapshot-create-as with the --diskspec option), you are asking libvirt to create the name for the new qcow2 file, and to create it in the same directory as the existing disk image. That is, you asked libvirt to create /dev/sdc.1317357844 (with that suffix being the timestamp of your attempt). Oddly enough, the kernel will allow you to create regular files directly in /dev/, although it seems rather dangerous; more particularly, when you reboot, since /dev is mounted on devtmpfs, and regular files created there previously will be lost: # id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 # mount | grep '/dev ' devtmpfs on /dev type devtmpfs (rw,nosuid,relatime,seclabel,size=1895732k,nr_inodes=473933,mode=755) # echo hi > /dev/sdc.123 # cat /dev/sdc.123 hi So _this_ is the point where libvirt could be smarter, and say that if the open("/dev/sdc.1317357844", O_CREAT, 0600) would be creating a regular file on devtmpfs or any other unusual file system, that the operation should be rejected. Not because the backing file is a block device, but because the _new_ qcow2 file is not in a persistent location. Maybe the kernel should be patched to prohibit open(O_CREAT) from creating regular files inside devtmpfs? Yep, this is evidence that the qcow2 file that was previously created as a regular file inside devtmpfs is now lost, so you've lost all changes that were made in the running domain after the snapshot in step 1 but prior to the shutdown in step 2. That's correct - libvirt is _supposed_ to modify the domain XML with the name of the qcow2 file it creates. What went wrong is that since you failed to tell libvirt _what_ file name to use, it invented its own file name, and happened to invent a name that was on temporary storage and thus got lost in your situation. It works for any backing file format. Where it needs help is knowing what file name to use - if your backing file is a block device instead of a regular file, then it is up to you to help libvirt out by giving it a sensible file name for the new qcow2 image, either with the --xmlfile option of snapshot-create, or the --diskspec option of snapshot-create-as. This is where I disagree with your conclusion. Taking a disk-only snapshot of block devices works just fine, provided that you tell libvirt what file name to use for the qcow2 file it creates. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org