On 11/15/2011 03:48 PM, MATSUDA, Daiki wrote:
> I tested some cases and found it.
> 1. The guest use the raw disk volume or LVM2 volume, such as following
> the config file using raw disk volume created by RHEL 6.1 Virt Manager.
> <disk type='block' device='disk'>
> <driver name='qemu' type='raw' cache='none' io='native'/>
> <source dev='/dev/sdc'/>
> <target dev='vda' bus='virtio'/>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
> function='0x0'/>
> </disk>
Here, I'm assuming /dev/sdc is the LVM volume.
> 2. Do the 'virsh snapshot-create abc --disk-only' with libvirt-0.9.6 or
> upper.
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?
> 3. The guest runs well till it is shutdowned.
> 4. But the guest does not boot with following error.
> virtsh # start abc
> error: Failed to start domain abc
> error: internal error Process exited while reading console log output: char
> device redirected to /dev/pts/7
> qemu: could not open disk image /dev/sdc.1317357844: Invalid
> argument.
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.
> 5. Then the config file has been replaced by libvirtd. Especially
> difference is
> <disk type='block' device='disk'>
> <driver name='qemu' type='qcow2' cache='none'/>
> <source dev='/dev/sdc.1317357844'/>
> <target dev='vda' bus='virtio'/>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
> function='0x0'/>
> </disk>
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.
>
> And 'snapshot-create ... --disk-only' works well for image format file,
> e.g. qcow2, raw and etc.
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.
>
> So, I think that the restriction is needed for the taking snapshot
> disk-only for the disk volume.
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@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list