Bug 1092886

Summary:	Fail to create qcow2 type volume with logical type pool without any error output
Product:	Red Hat Enterprise Linux 7	Reporter:	Shanzhi Yu <shyu>
Component:	libvirt	Assignee:	John Ferlan <jferlan>
Status:	CLOSED NOTABUG	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	acathrow, dyuan, jferlan, mzhan, yanyang
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-07-23 15:27:53 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Shanzhi Yu 2014-04-30 07:51:58 UTC

Description of problem:

Fail to create qcow2 type volume with logical type pool without any error output

Version-Release number of selected component (if applicable):

libvirt-1.1.1-29.el7.x86_64

How reproducible:

100%

Steps to Reproduce:

1.Define an logical type pool

# virsh pool-list --type logical
Name                 State      Autostart
-----------------------------------------
logical              active     no

2.create a qcow2 type volume
# virsh vol-create-as --pool logical qcow2 --format qcow2  1G
Vol qcow2 created


3. check volume type

# virsh vol-list logical
Name                 Path                                    
-----------------------------------------
qcow2                /dev/logical/qcow2  

# qemu-img info /dev/logical/qcow2
image: /dev/logical/qcow2
file format: raw
virtual size: 1.0G (1073741824 bytes)
disk size: 0


Actual results:


Expected results:

1) if libvirt don't support creating qcow2 type volume with logical pool, these should be some info in step 2 or 
2) succeed creating qcow2 type volume with logical pool


Additional info:

Comment 1 John Ferlan 2014-07-23 12:24:02 UTC

The documentation (http://libvirt.org/storage.html) states for a logical pool:

" Logical volume pools

This provides a pool based on an LVM volume group. For a pre-defined LVM volume group, simply providing the group name is sufficient, while to build a new group requires providing a list of source devices to serve as physical volumes. Volumes will be allocated by carving out chunks of storage from the volume group.

...
Valid pool format types

The logical volume pool supports the following formats:

    auto - automatically determine format
    lvm2 

Valid volume format types

The logical volume pool does not use the volume format type element.
"
...

The documentation describing the format field for the storage pools is vague about where to find this information - that will be corrected.

The code is functioning as expected, so the "expected results" from the problem description are invalid as a logical pool only supports target volumes of lvm2 type.

Comment 2 John Ferlan 2014-07-23 15:27:19 UTC

I just pushed a doc change to point at the valid pool values page and describe that the format type will be ignored if a valid pool value is not defined.

See:

commit b6938a7c880168b2b0bbb3f45b566b3d2318d49c
Author: John Ferlan <jferlan>
Date:   Wed Jul 23 08:36:50 2014 -0400

    docs: Point to list of valid pool target volume formats
    


git describe: v1.2.6-232-gb6938a7


I am going to close this since the code is working as expected.

Comment 3 Shanzhi Yu 2014-11-14 03:55:54 UTC

John,

Recently, I do some test with RHEV-M. When use a iscsi type storage, logical volume will be created for usage based iscsi storage on host. After I create a snapshot for vm, a new logical volume with type qcow2 will be created. So, I wonder, if we can add to support qcow2 type volume in logical pool.

Comment 4 John Ferlan 2014-11-17 20:50:04 UTC

I have no idea - not something I've thought about at all. I'm sure there's issues with having a specifically formatted file be considered for a logical volume pool element. I'm not sure I understand your use case entirely either.