Bug 597981

Summary: libvirt: "vpc" format file volume is detected as "raw"
Product: Red Hat Enterprise Linux 6 Reporter: Justin Clift <justin>
Component: libvirtAssignee: Daniel Berrange <berrange>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: ajia, berrange, dallan, hbrock, mjenner, xen-maint, xhu
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
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: ---
Description Flags
Screenshot 1 - Storage pool prior to volume creation.
Screenshot 2 - Volume settings used in volume creation.
Screenshot 3 - Storage pool after volume creation
virt-manager (0.8.4 mercurial master compiled) debug log during volume creation
libvirtd log from during volume creation
virt-manager-2 none

Description Justin Clift 2010-05-31 07:19:31 UTC
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

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
      <format type='raw'/>                                 <----- problem is here


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
      <format type='vpc'/>


Comment 1 Justin Clift 2010-05-31 07:20:21 UTC
Created attachment 418186 [details]
Screenshot 2 - Volume settings used in volume creation.

Comment 2 Justin Clift 2010-05-31 07:20:55 UTC
Created attachment 418187 [details]
Screenshot 3 - Storage pool after volume creation

Comment 3 Justin Clift 2010-05-31 07:22:35 UTC
Created attachment 418188 [details]
virt-manager (0.8.4 mercurial master compiled) debug log during volume creation

Comment 5 Justin Clift 2010-05-31 07:23:40 UTC
Created attachment 418189 [details]
libvirtd log from during volume creation

Comment 6 Cole Robinson 2010-06-01 15:21:37 UTC
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 10:38:59 UTC
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


  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 11:32:56 UTC
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 15:59:02 UTC
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

Comment 10 Daniel Berrange 2010-06-08 10:19:13 UTC
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 21:31:18 UTC
libvirt-0_8_1-8_el6 has been built in RHEL-6-candidate with the fix.


Comment 14 Alex Jia 2010-07-08 06:22:08 UTC
The bug has been fixed on RHEL6-beta with libvirt-0.8.1-13.el6.x86_64 and 

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
    <format type='vpc'/>

# 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
[root@dhcp-66-70-128 workspace]# rpm -q virt-manager

Comment 15 Alex Jia 2010-07-08 06:23:59 UTC
Created attachment 430243 [details]

Comment 16 Alex Jia 2010-07-08 06:24:48 UTC
Created attachment 430244 [details]

Comment 17 xhu 2010-09-08 06:54:21 UTC
Verified this bug with RHEL6 RC build and it passed:

Comment 18 releng-rhel@redhat.com 2010-11-11 14:48:30 UTC
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.