Bug 597981 - libvirt: "vpc" format file volume is detected as "raw"
libvirt: "vpc" format file volume is detected as "raw"
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Daniel Berrange
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-31 03:19 EDT by Justin Clift
Modified: 2010-11-11 09:48 EST (History)
7 users (show)

See Also:
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 09:48:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot 1 - Storage pool prior to volume creation. (49.24 KB, image/png)
2010-05-31 03:19 EDT, Justin Clift
no flags Details
Screenshot 2 - Volume settings used in volume creation. (46.06 KB, image/png)
2010-05-31 03:20 EDT, Justin Clift
no flags Details
Screenshot 3 - Storage pool after volume creation (51.73 KB, image/png)
2010-05-31 03:20 EDT, Justin Clift
no flags Details
virt-manager (0.8.4 mercurial master compiled) debug log during volume creation (2.42 KB, application/x-bzip2)
2010-05-31 03:22 EDT, Justin Clift
no flags Details
libvirtd log from during volume creation (421.44 KB, application/x-bzip2)
2010-05-31 03:23 EDT, Justin Clift
no flags Details
virt-manager-1 (1.03 MB, image/png)
2010-07-08 02:23 EDT, Alex Jia
no flags Details
virt-manager-2 (1010.42 KB, image/png)
2010-07-08 02:24 EDT, Alex Jia
no flags Details

  None (edit)
Description Justin Clift 2010-05-31 03:19:31 EDT
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>

  #
Comment 1 Justin Clift 2010-05-31 03:20:21 EDT
Created attachment 418186 [details]
Screenshot 2 - Volume settings used in volume creation.
Comment 2 Justin Clift 2010-05-31 03:20:55 EDT
Created attachment 418187 [details]
Screenshot 3 - Storage pool after volume creation
Comment 3 Justin Clift 2010-05-31 03:22:35 EDT
Created attachment 418188 [details]
virt-manager (0.8.4 mercurial master compiled) debug log during volume creation
Comment 5 Justin Clift 2010-05-31 03:23:40 EDT
Created attachment 418189 [details]
libvirtd log from during volume creation
Comment 6 Cole Robinson 2010-06-01 11:21:37 EDT
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},
    */
Comment 7 Daniel Berrange 2010-06-02 06:38:59 EDT
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'.
Comment 8 Justin Clift 2010-06-02 07:32:56 EDT
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. ;)
Comment 9 RHEL Product and Program Management 2010-06-07 11:59:02 EDT
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.
Comment 10 Daniel Berrange 2010-06-08 06:19:13 EDT
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.
Comment 12 Dave Allan 2010-06-10 17:31:18 EDT
libvirt-0_8_1-8_el6 has been built in RHEL-6-candidate with the fix.

Dave
Comment 14 Alex Jia 2010-07-08 02:22:08 EDT
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
Comment 15 Alex Jia 2010-07-08 02:23:59 EDT
Created attachment 430243 [details]
virt-manager-1
Comment 16 Alex Jia 2010-07-08 02:24:48 EDT
Created attachment 430244 [details]
virt-manager-2
Comment 17 xhu 2010-09-08 02:54:21 EDT
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
Comment 18 releng-rhel@redhat.com 2010-11-11 09:48:30 EST
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.

Note You need to log in before you can comment on or make changes to this bug.