Bug 597981
| Summary: | libvirt: "vpc" format file volume is detected as "raw" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Justin Clift <justin> |
| Component: | libvirt | Assignee: | Daniel Berrangé <berrange> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.0 | CC: | ajia, berrange, dallan, hbrock, mjenner, xen-maint, xhu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-0_8_1-8_el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-11-11 14:48:30 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
Created attachment 418186 [details]
Screenshot 2 - Volume settings used in volume creation.
Created attachment 418187 [details]
Screenshot 3 - Storage pool after volume creation
Created attachment 418188 [details]
virt-manager (0.8.4 mercurial master compiled) debug log during volume creation
Created attachment 418189 [details]
libvirtd log from during volume creation
This is a bug in libvirt's file format detection.
In src/util/storage_file.c, the VPC check is commented out:
/* Connectix / VirtualPC */
/* XXX Untested
{ VIR_STORAGE_FILE_VPC, "conectix", NULL,
LV_BIG_ENDIAN, -1, 0,
-1, 0, 0, -1, NULL},
*/
As the comment suggests we need someone who has a real VPC disk image handy to test this. The code is commented out because I didn't know what byte offset the logical disk size is stored at (that first -1 on the 3rd line needs to be an offset of some kind following the examples in other formats).
If you have a suitable disk image, please uncomment the lines Cole mentions and see if that detects the format correctly.
For the offset of the logical disk size, there are two possible options I now see from the QEMU vpc.c struct definition of 'struct vhd_footer'
uint64_t orig_size;
uint64_t size;
The struct offsets for these are either
8 + 4 + 4 + 8 + 4 + 4 + 2 + 2 + 4
Or
8 + 4 + 4 + 8 + 4 + 4 + 2 + 2 + 4 + 4
The key is to see that 'virsh vol-info VOLPATH' returns same size info as 'qemu-img info VOLPATH'.
Sorry, I don't have any vpc images handy. I was kind of expecting that qemu-img would create a vpc image when told to, through libvirt, the same as the other image types. Guessing there's a reason why "qemu-img info" isn't directly used to verify correct creation, but I don't know what that is yet. ;) This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. Originally qemu-img was unable to create VPC files, but I see it has recently been enhanced to support that. So we ought to be able to handle this now afterall. libvirt-0_8_1-8_el6 has been built in RHEL-6-candidate with the fix. Dave The bug has been fixed on RHEL6-beta with libvirt-0.8.1-13.el6.x86_64 and
virt-manager-0.8.4-6.el6.noarch.
For virt-manager operation, please see attachment.
# qemu-img info /var/lib/libvirt/images/test.img
image: /var/lib/libvirt/images/test.img
file format: vpc
virtual size: 5.9G (6291726336 bytes)
disk size: 16K
#virsh vol-list default
Name Path
-----------------------------------------
demo /var/lib/libvirt/images/demo
rhel6.img /var/lib/libvirt/images/rhel6.img
sparse-file /var/lib/libvirt/images/sparse-file
test.img /var/lib/libvirt/images/test.img
# virsh vol-dumpxml /var/lib/libvirt/images/test.img
<volume>
<name>test.img</name>
<key>/var/lib/libvirt/images/test.img</key>
<source>
</source>
<capacity>6291726336</capacity>
<allocation>16384</allocation>
<target>
<path>/var/lib/libvirt/images/test.img</path>
<format type='vpc'/>
<permissions>
<mode>0600</mode>
<owner>0</owner>
<group>0</group>
<label>system_u:object_r:nfs_t:s0</label>
</permissions>
</target>
</volume>
# cat /etc/redhat-release
Red Hat Enterprise Linux release 6.0 Beta (Santiago)
[root@dhcp-66-70-128 workspace]# uname -a
Linux dhcp-66-70-128.nay.redhat.com 2.6.32-37.el6.x86_64 #1 SMP Sun Jun 20 19:29:35 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
[root@dhcp-66-70-128 workspace]# rpm -q libvirt
libvirt-0.8.1-13.el6.x86_64
[root@dhcp-66-70-128 workspace]# rpm -q virt-manager
virt-manager-0.8.4-6.el6.noarch
Created attachment 430243 [details]
virt-manager-1
Created attachment 430244 [details]
virt-manager-2
Verified this bug with RHEL6 RC build and it passed: libvirt-0.8.1-27.el6.x86_64 qemu-kvm-0.12.1.2-2.113.el6.x86_64 kernel-2.6.32-71.el6.x86_64 Red Hat Enterprise Linux 6.0 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |
Created attachment 418185 [details] Screenshot 1 - Storage pool prior to volume creation. Description of problem: When creating a new "vpc" format volume in a pre-formatted block device storage pool, the volume is created but Virt Manager (and vol-dumpxml) report the volume type to be raw. Checking the volume type created using qemu-img shows it to be of type "vpc" after all. Unsure if this is a virt-manager or libvirtd problem, but it looks to lie somewhere between the two. Perhaps the XML being passed to libvirt in this instance is not how it wants it? This bug does not occur for any of the other format types. Version-Release number of selected component (if applicable): RHEL 6 beta (x86_64). # rpm -qa | grep virt libvirt-cim-0.5.8-1.el6.x86_64 fence-virtd-serial-0.2.1-3.el6.x86_64 virt-top-1.0.4-3.1.el6.x86_64 python-virtinst-0.500.1-3.el6.noarch fence-virtd-libvirt-0.2.1-3.el6.x86_64 virt-viewer-0.2.1-1.el6.x86_64 fence-virtd-0.2.1-3.el6.x86_64 virt-v2v-0.2.0-2.el6.x86_64 libvirt-python-0.7.6-2.el6.x86_64 libvirt-debuginfo-0.7.6-2.el6.x86_64 virt-manager-0.8.2-3.el6.noarch libvirt-qpid-0.2.17-7.el6.x86_64 fence-virtd-multicast-0.2.1-3.el6.x86_64 libvirt-java-0.4.1-1.el6.noarch libvirt-client-0.7.6-2.el6.x86_64 libvirt-0.7.6-2.el6.x86_64 # This bug also happens when manually compiling virt-manager from mercurial master (0.8.4+), then remotely connecting to the above server. How reproducible: Every time. Steps to Reproduce: 1. Use the virt-manager wizard to add a new storage volume, setting the format to vpc. Screenshots 1 & 2. 2. In the storage pool window that shows the result, the format is reported as "raw" instead of "vpc". Screenshot 3. This is the bug. Actual results: The format of the volume is reported wrongly as "raw", even though it was created correctly. Expected results: The format of the volume to be reported correctly as "vpc". Additional info: "vpctest.img" volume created as per above. Checking the actual volume created shows: # qemu-img info /guest_images_fs/vpctest.img image: /guest_images_fs/vpctest.img file format: vpc virtual size: 8.0G (8590417920 bytes) disk size: 20K # Using virsh to check the xml shows a problem: # virsh vol-dumpxml --pool guest_images_fs vpctest.img <volume> <name>vpctest.img</name> <key>/guest_images_fs/vpctest.img</key> <source> </source> <capacity>18944</capacity> <allocation>20480</allocation> <target> <path>/guest_images_fs/vpctest.img</path> <format type='raw'/> <----- problem is here <permissions> <mode>0600</mode> <owner>0</owner> <group>0</group> <label>unconfined_u:object_r:file_t:s0</label> </permissions> </target> </volume> # Creating the same type of volume through virsh doesn't exhibit this problem: # virsh vol-create-as guest_images_fs vpctest_virsh-create-as.img 8G --format vpc Vol vpctest_virsh-create-as.img created # virsh vol-list guest_images_fs Name Path ----------------------------------------- vpctest.img /guest_images_fs/vpctest.img vpctest_virsh-create-as.img /guest_images_fs/vpctest_virsh-create-as.img # virsh vol-dumpxml --pool guest_images_fs vpctest_virsh-create-as.img <volume> <name>vpctest_virsh-create-as.img</name> <key>/guest_images_fs/vpctest_virsh-create-as.img</key> <source> </source> <capacity>8589934592</capacity> <allocation>20480</allocation> <target> <path>/guest_images_fs/vpctest_virsh-create-as.img</path> <format type='vpc'/> <permissions> <mode>0600</mode> <owner>0</owner> <group>0</group> <label>unconfined_u:object_r:file_t:s0</label> </permissions> </target> </volume> #