Bug 708347

Summary: koan can't handle LVM
Product: Red Hat Satellite 5 Reporter: Jens Kuehnel <bugzilla-redhat>
Component: VirtualizationAssignee: Milan Zázrivec <mzazrivec>
Status: CLOSED ERRATA QA Contact: Pavel Studeník <pstudeni>
Severity: low Docs Contact:
Priority: medium    
Version: 541CC: cperry, mmello, mminar, pstudeni, rdassen
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Previously, an attempt to provision a virtual machine with a logical volume as a disk drive caused koan to fail with a traceback. This error has been fixed, and provisioning of a virtual machine in the aforementioned scenario now works correctly.
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-22 10:34:54 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:
Bug Depends On:    
Bug Blocks: 715348    
Attachments:
Description Flags
patch to fix the problem
none
rhn_check -vvv output illustrating the problem none

Description Jens Kuehnel 2011-05-27 11:22:17 UTC
Created attachment 501284 [details]
patch to fix the problem

Description of problem:
Can't install VM with LVM backend via Satellite

Version-Release number of selected component (if applicable):
koan-2.0.7-6.el6sat.noarch


How reproducible:
Create a new virt machine in Satellite and select a VG as target

Steps to Reproduce:
1. Create a new virt machine in Satellite and select VG-name as target
2. run rhn_check -vvv
3. read the error
  
Actual results:
Installation failes


Expected results:
Installation succed

Additional info:
Patch to fix the problem is attached.

Comment 5 J.H.M. Dassen (Ray) 2011-07-20 08:57:30 UTC
Created attachment 513950 [details]
rhn_check -vvv output illustrating the problem

Comment 6 J.H.M. Dassen (Ray) 2011-08-09 12:19:01 UTC
This issue still affects koan-2.0.7-11.el6sat.noarch :

	The line 1458 (args = "LANG=C vgs...) will crash because of invalid
	literal for float(): 62.50g

	and therefor the "#remove gigabytes" is never executed.

	Adding --noprefix to the line 1458 will solve this.


Test results with koan-2.0.7-11.el6sat.noarch :
	- looking for Cobbler at http://lfsat02.foo.tld/cobbler_api
	- reading URL: http://lfsat02.foo.tld/cblr/svc/op/ks/system/otm0105:1:test
	install_tree: http://lfsat02.foo.tld/ty/DQ9p4sy4
	libvirtd (pid  3369) is running...
	vgs -o vg_name
	  VG
	  VGlocal

	LANG=C vgs --noheadings -o vg_free --units g VGlocal
	(62.50g)
	<type 'exceptions.ValueError'>
	invalid literal for float(): 62.50g
	  File "/usr/share/rhn/spacewalkkoan/spacewalkkoan.py", line 193, in initiate_guest
	    k.run()
	   File "/usr/lib/python2.6/site-packages/koan/app.py", line 338, in run
	    self.virt()
	   File "/usr/lib/python2.6/site-packages/koan/app.py", line 657, in virt
	    return self.net_install(after_download)
	   File "/usr/lib/python2.6/site-packages/koan/app.py", line 576, in net_install
	    after_download(self, profile_data)
	   File "/usr/lib/python2.6/site-packages/koan/app.py", line 655, in after_download
	    self.virt_net_install(profile_data)
	   File "/usr/lib/python2.6/site-packages/koan/app.py", line 1118, in virt_net_install
	    path_list           = self.calc_virt_path(pd, virtname)
	   File "/usr/lib/python2.6/site-packages/koan/app.py", line 1413, in calc_virt_                                                            path
	    path = self.calc_virt_path2(pd,name,offset=count,location=x,sizes=virt_sizes                                                            )
	   File "/usr/lib/python2.6/site-packages/koan/app.py", line 1465, in calc_virt_                                                            path2
	    freespace = int(float(freespace_str))


Output with fix:
	- looking for Cobbler at http://lfsat02.foo.tld/cobbler_api
	- reading URL: http://lfsat02.foo.tld/cblr/svc/op/ks/system/otm0105:1:test
	install_tree: http://lfsat02.foo.tld/ty/DQ9p4sy4
	libvirtd (pid  3369) is running...
	vgs -o vg_name
	  VG
	  VGlocal

	LANG=C vgs --noheadings -o vg_free --units g --nosuffix VGlocal
	(62.50)
	lvs -o lv_name VGlocal
	  LV
	  LVroot
	  LVswap
	  LVtmp
	  LVvar
	  vws0118-disk0

	lvcreate -L 40G -n test-disk0 VGlocal
	  Logical volume "test-disk0" created
	/usr/bin/chcon -t virt_image_t /dev/mapper/VGlocal-test--disk0
	/usr/sbin/semanage fcontext -a -t virt_image_t /dev/mapper/VGlocal-test--disk0

Comment 9 Milan Zázrivec 2011-08-15 09:22:16 UTC
*** Bug 729139 has been marked as a duplicate of this bug. ***

Comment 11 Milan Zázrivec 2011-08-23 15:51:33 UTC
Thanks for the patch provided!

thirdparty.git SATELLITE-5.4: c0ace59b4973d72657e849dc45b01fb60f0b8736

Comment 12 Milan Zázrivec 2011-08-23 15:53:51 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: Bug in cobbler / koan code.

Consequence: Koan would throw a traceback when attempting to provision a virtual machine with a logical volume as a disk.

Fix: Simple, yet elegant.

Result: Provisioning of a virtual machine in the specific situation now works.

Comment 14 Jaromir Hradilek 2011-08-25 14:25:40 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,7 +1 @@
-Cause: Bug in cobbler / koan code.
+Previously, an attempt to provision a virtual machine with a logical volume as a disk drive caused koan to fail with a traceback. This error has been fixed, and provisioning of a virtual machine in the aforementioned scenario now works correctly.-
-Consequence: Koan would throw a traceback when attempting to provision a virtual machine with a logical volume as a disk.
-
-Fix: Simple, yet elegant.
-
-Result: Provisioning of a virtual machine in the specific situation now works.

Comment 16 errata-xmlrpc 2011-09-22 10:34:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1331.html