[libvirt-users] problem cloning storage pool volume
Martin Kletzander
mkletzan at redhat.com
Mon Feb 22 11:10:52 UTC 2016
On Fri, Feb 19, 2016 at 12:33:10PM +0000, Andrei Perietanu wrote:
>On Fri, Feb 19, 2016 at 12:12 PM, Martin Kletzander <mkletzan at redhat.com>
>wrote:
>
>> On Fri, Feb 19, 2016 at 11:12:32AM +0000, Andrei Perietanu wrote:
>>
>>> I'm trying to clone a volume in a storage pool and I'm following the steps
>>> described here:
>>>
>>> http://libvirt.org/docs/libvirt-appdev-guide-python/en-US/html/libvirt_application_development_guide_using_python-Storage_Pools-Cloning.html
>>>
>>> My code looks like:
>>>
>>> destXML = """
>>> <volume>
>>> <name>"""+newDiskName+""".qcow2</name>
>>> <target>
>>>
>>> <path>/jffs2/disk0/"""+poolName+'/'+newDiskName+""".qcow2</path>
>>> <format type='qcow2'/>
>>> <permissions>
>>> <owner>-1</owner>
>>> <group>-1</group>
>>> <mode>0644</mode>
>>> <label>virt_image_t</label>
>>> </permissions>
>>> </target>
>>> </volume>"""
>>>
>>> srcDisk = tmpPool.storageVolLookupByName(vDisk)
>>> newVol = sp.createXMLFrom(destXML,srcDisk, 0)
>>>
>>> According to the steps described in the link, this should be it; but I
>>> can't start any VM that are using this volume.
>>>
>>> Also comparing the volume XML files for src/dest it looks like the format
>>> is not copied over:
>>> source:
>>> <volume type='file'>
>>> <name>k.qcow2</name>
>>> <key>/jffs2/disk0/sp/vDisk.qcow2</key>
>>> <source>
>>> </source>
>>> <capacity unit='bytes'>3221225472</capacity>
>>> <allocation unit='bytes'>332075008</allocation>
>>> <target>
>>> <path>/jffs2/disk0/sp/vDisk.qcow2</path>
>>> *<format type='qcow2'/>*
>>> <permissions>
>>> <mode>0644</mode>
>>> <owner>0</owner>
>>> <group>0</group>
>>> </permissions>
>>> <timestamps>
>>> <atime>1455879195</atime>
>>> <mtime>1455879171</mtime>
>>> <ctime>1455879171</ctime>
>>> </timestamps>
>>> </target>
>>>
>>>
>>> dest:
>>> <volume type='file'>
>>> <name>newDiskName.qcow2</name>
>>> <key>/jffs2/disk0/sp/newDiskName.qcow2</key>
>>> <source>
>>> </source>
>>> <capacity unit='bytes'>3221225472</capacity>
>>> <allocation unit='bytes'>326868992</allocation>
>>> <target>
>>> <path>/jffs2/disk0/sp/newDiskName.qcow2</path>
>>> *<format type='raw'/>*
>>>
>>
>>
>> So there are two bugs here, probably. Does this go away if you refresh
>> the pool?
>>
> No, refreshing the pool does not help. The problem is not that I
>don't see the new volume, the problem is I get a "raw" file instead of
>"qcow2"
>
I know, I wanted to see whether that format changed. Are those files
really cloned? I tried the same thing you did and I have the right
format there. What libvirt version are you running?
>>
>> The other thing is that it doesn't matter what's here, you should
>> explicitly specify the format in the domain XML anyway. Do you do that?
>>
> The tutorial I followed (libvirt.org) says:
>"Cloning a storage volume is similar to creating a new storage volume,
>except that an existing storage volume is used for most of the attributes.
>Only the name and permissions in the XML parameter are used for the new
>volume, everything else is inherited from the existing volume."
>So I don't specifically mention the file formal in the xml for the new
>volume.
>
>>
>> <permissions>
>>> <mode>0644</mode>
>>> <owner>0</owner>
>>> <group>0</group>
>>> </permissions>
>>> <timestamps>
>>> <atime>1455878686</atime>
>>> <mtime>1455878681</mtime>
>>> <ctime>1455878681</ctime>
>>> </timestamps>
>>> </target>
>>> </volume>
>>>
>>> I this a bug in libvirt->createXMLFrom ?? Or am I missing something?
>>>
>>> Thanks,
>>> Andrei
>>>
>>> --
>>>
>>>
>>> The information transmitted is intended only for the person or entity to
>>> which it is addressed and may contain confidential and/or privileged
>>> material. Any review, retransmission, dissemination or other use of or
>>> taking of any action in reliance upon this information by persons or
>>> entities other than the intended recipient is prohibited. If you receive
>>> this in error please contact the sender and delete the material from any
>>> computer immediately. It is the policy of Klas Limited to disavow the
>>> sending of offensive material and should you consider that the material
>>> contained in the message is offensive you should contact the sender
>>> immediately and also your I.T. Manager.
>>>
>>> Klas Telecom Inc., a Virginia Corporation with offices at 1101 30th St.
>>> NW,
>>> Washington, DC 20007.
>>>
>>> Klas Limited (Company Number 163303) trading as Klas Telecom, an Irish
>>> Limited Liability Company, with its registered office at Fourth Floor, One
>>> Kilmainham Square, Inchicore Road, Kilmainham, Dublin 8, Ireland.
>>>
>>
>> _______________________________________________
>>> libvirt-users mailing list
>>> libvirt-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/libvirt-users
>>>
>>
>
>--
>
>
>The information transmitted is intended only for the person or entity to
>which it is addressed and may contain confidential and/or privileged
>material. Any review, retransmission, dissemination or other use of or
>taking of any action in reliance upon this information by persons or
>entities other than the intended recipient is prohibited. If you receive
>this in error please contact the sender and delete the material from any
>computer immediately. It is the policy of Klas Limited to disavow the
>sending of offensive material and should you consider that the material
>contained in the message is offensive you should contact the sender
>immediately and also your I.T. Manager.
>
>Klas Telecom Inc., a Virginia Corporation with offices at 1101 30th St. NW,
>Washington, DC 20007.
>
>Klas Limited (Company Number 163303) trading as Klas Telecom, an Irish
>Limited Liability Company, with its registered office at Fourth Floor, One
>Kilmainham Square, Inchicore Road, Kilmainham, Dublin 8, Ireland.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20160222/926be135/attachment.sig>
More information about the libvirt-users
mailing list