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

MATSUDA, Daiki matsudadik at intellilink.co.jp
Tue Nov 15 22:48:44 UTC 2011


(2011/11/16 0:35), Dave Allan wrote:
> On Mon, Nov 14, 2011 at 04:02:21PM -0700, Eric Blake wrote:
>> On 11/13/2011 09:08 PM, MATSUDA, Daiki wrote:
>>>> NACK.  There is nothing inherently wrong with the source file not being
>>>> a qcow2 file.  The whole point of creating a runtime snapshot is that
>>>> the original file (of _any_ format) becomes the backing file of a new
>>>> qcow2 file, so that the original file now serves as the snapshot.
>>>> Forbidding a live snapshot of a raw source file interferes with this intent.
>>>>
>>>
>>> I have some tested since you replied. Certainly other image file, e.g.
>>> raw type, has no problem after snapshot is taken in qcow2 format.
>>>
>>> But in the case that direct disk block, e.g. /dev/sdc, is given for the
>>> guest OS, the same error occurs. It may not be accepted by qemu-kvm.
>>
>> I'm not following you.  As I already said, there's nothing wrong with a
>> direct disk block as the backing file of a qcow2 image.
>>
>>>
>>> I do not understand which qemu-kvm or libvirt should be fixed. But at
>>> least libvirt should be stop to take snapshot for block device with
>>> following patch.
>>
>> I still say NACK.  Your patch is merely attempting to forbid a useful
>> case, rather than fix a demonstrated problem.
>
> Matsuda-san,
>
> I must admit that I don't understand the problem that you are
> attempting to solve either.  I have reread the thread from the
> beginning, but I don't understand what your goal is.  Could you
> explain to us more about your use case?
>
> Regards,
> Dave Allan

Mr. Dave.

The problem is that the guest does not boot after 'virsh snapshot-create 
.... --disk-only' under the specific situation.

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.
<domain type='kvm'>
   <name>abc</name>
   <uuid>791ede5a-e617-ca6b-125d-4e9704a2ddc2</uuid>
   <memory>524288</memory>
   <currentMemory>524288</currentMemory>
   <vcpu>1</vcpu>
   <os>
     <type arch='x86_64' machine='rhel6.1.0'>hvm</type>
     <boot dev='hd'/>
   </os>
   <features>
     <acpi/>
     <apic/>
     <pae/>
   </features>
   <clock offset='utc'/>
   <on_poweroff>destroy</on_poweroff>
   <on_reboot>restart</on_reboot>
   <on_crash>restart</on_crash>
   <devices>
     <emulator>/usr/libexec/qemu-kvm</emulator>
     <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>
     <disk type='block' device='cdrom'>
       <driver name='qemu' type='raw'/>
       <target dev='hdc' bus='ide'/>
       <readonly/>
       <address type='drive' controller='0' bus='1' unit='0'/>
     </disk>
     <controller type='ide' index='0'>
       <address type='pci' domain='0x0000' bus='0x00' slot='0x01' 
function='0x1'/>
     </controller>
     <interface type='bridge'>
       <mac address='52:54:00:0d:53:c6'/>
       <source bridge='br0'/>
       <model type='virtio'/>
       <address type='pci' domain='0x0000' bus='0x00' slot='0x03' 
function='0x0'/>
     </interface>
     <serial type='pty'>
       <target port='0'/>
     </serial>
     <console type='pty'>
       <target type='serial' port='0'/>
     </console>
     <input type='tablet' bus='usb'/>
     <input type='mouse' bus='ps2'/>
     <graphics type='vnc' port='-1' autoport='yes'/>
     <sound model='ich6'>
       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' 
function='0x0'/>
     </sound>
     <video>
       <model type='cirrus' vram='9216' heads='1'/>
       <address type='pci' domain='0x0000' bus='0x00' slot='0x02' 
function='0x0'/>
     </video>
     <memballoon model='virtio'>
       <address type='pci' domain='0x0000' bus='0x00' slot='0x06' 
function='0x0'/>
     </memballoon>
   </devices>
</domain>

2. Do the 'virsh snapshot-create abc --disk-only' with libvirt-0.9.6 or 
upper.
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.
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>

And 'snapshot-create ... --disk-only' works well for image format file, 
e.g. qcow2, raw and etc.

So, I think that the restriction is needed for the taking snapshot 
disk-only for the disk volume.

Regards
MATSUDA Daiki

>> If I recall correctly, you started this thread when you used 'virsh
>> snapshot-create --disk-only' without arguments, and thus fell victim to
>> virsh picking the snapshot name for you, but trying to pick that name
>> under /dev instead of a more typical location for a non-device file.
>> But that's a usage error in you not taking time to provide virsh with
>> the alternate name to use for the qcow2 file, and not a flaw that needs
>> correcting in libvirt itself.  Or even if there is a flaw in libvirt,
>> the fix is not to forbid snapshots of a raw block device, but to be
>> smarter about ensuring that any generated qcow2 file name is likely to
>> be correct (a qcow2 file created under /dev probably only makes sense if
>> the qcow2 data is being written atop a pre-existing block device, rather
>> than trying to use open(O_CREAT) to create a regular file in /dev).
>>
>> --
>> Eric Blake   eblake at redhat.com    +1-919-301-3266
>> Libvirt virtualization library http://libvirt.org
>>
>
>
>
>> --
>> libvir-list mailing list
>> libvir-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
>
>
>




More information about the libvir-list mailing list