Bug 669935

Summary: bad guest configuration generated for iscsi disks
Product: [Fedora] Fedora Reporter: Nathan Lynch <ntl>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: berrange, crobinso, hbrock, jforbes, jonathon.padfield, thughes, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-23 21:29:31 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:

Description Nathan Lynch 2011-01-15 23:20:09 UTC
Description of problem:

Set up an iSCSI storage pool and created a KVM guest as described in these blog posts:

http://berrange.com/posts/2010/05/04/provisioning-kvm-virtual-machines-on-iscsi-with-qnap-virt-manager-part-1-of-2/

http://berrange.com/posts/2010/05/04/provisioning-kvm-virtual-machines-on-iscsi-with-qnap-virt-manager-part-2-of-2/

Everything works until I attempt to start the installation of the guest, which gives the error:

"qemu: 'unknown' invalid format"

I get the same error if I add an iSCSI-backed disk to an existing guest through the "Add Hardware" wizard.

The problem seems to be that the disk section in the guest xml generated for the iSCSI volume has 'unknown' for the <driver> "type" attribute, e.g.
<domain>
  ...
  <devices>
    ...
    <disk type='block' device='disk'>
      <driver name='qemu' type='unknown'/>
      <source dev='/dev/disk/by-path/ip-192.168.2.4:3260-iscsi-iqn.2004-04.com.qnap:ts-459:iscsi.kvmguests.c5bae7-lun-0'/>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>   
    </disk>

Removing the "type='unknown" from the driver line makes the guest bootable.


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

virt-manager-0.8.5-1.fc14.noarch
libvirt-client-0.8.3-2.fc14.x86_64
python-virtinst-0.500.4-1.fc14.noarch
libvirt-0.8.3-2.fc14.x86_64
libvirt-python-0.8.3-2.fc14.x86_64


How reproducible: always

Comment 1 Tim Hughes 2011-03-22 23:51:19 UTC
Pretty much the same issue , I am exporting the iscsi lun from the host machine. Followed the same instructions 

[root@titanium ~]# getenforce 
Permissive


[root@titanium ~]# cat /etc/tgt/targets.conf 
default-driver iscsi
<target test-target>
	backing-store /dev/vg_titanium/lv_iscsi01
</target>
	
[root@titanium ~]# iscsiadm -m session
tcp: [2] 127.0.0.1:3260,1 test-target

[root@titanium ~]# virsh pool-dumpxml test-target
<pool type='iscsi'>
  <name>test-target</name>
  <uuid>23668446-3df5-736c-d792-2e88db2d16fc</uuid>
  <capacity>3221225472</capacity>
  <allocation>3221225472</allocation>
  <available>0</available>
  <source>
    <host name='127.0.0.1'/>
    <device path='test-target'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0700</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>



[root@titanium ~]# rpm -qa|egrep 'virt|kvm|qemu'
gpxe-roms-qemu-1.0.1-1.fc14.noarch
qemu-img-0.13.0-1.fc14.x86_64
python-virtkey-0.50-8.fc14.x86_64
virtuoso-opensource-6.1.2-1.fc14.x86_64
python-virtinst-0.500.4-1.fc14.noarch
libvirt-python-0.8.3-2.fc14.x86_64
qemu-kvm-0.13.0-1.fc14.x86_64
libvirt-0.8.3-2.fc14.x86_64
libvirt-client-0.8.3-2.fc14.x86_64
qemu-common-0.13.0-1.fc14.x86_64
virt-manager-0.8.5-1.fc14.noarch
virt-viewer-0.2.1-1.fc13.x86_64
redland-virtuoso-1.0.12-1.fc14.x86_64
qemu-kvm-tools-0.13.0-1.fc14.x86_64
qemu-system-x86-0.13.0-1.fc14.x86_64



Attempting the install through virt manager gives this error 



[root@titanium ~]# uname -a
Linux titanium 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux


Unable to complete install '<class 'libvirt.libvirtError'> internal error Process exited while reading console log output: char device redirected to /dev/pts/2
qemu: 'unknown' invalid format

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 1567, in do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1023, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1088, in _do_install
    "install")
  File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1059, in _create_guest
    dom = self.conn.createLinux(start_xml, 0)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1277, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error Process exited while reading console log output: char device redirected to /dev/pts/2
qemu: 'unknown' invalid format



From the command line gives the following

[root@titanium ~]# NAME=iscsi01   ;virt-install -vv -n $NAME -r 512 --vcpus=1 --disk vol=test-target/7.0.0.1,size=2,bus=virtio --location http://192.168.122.1:8080/mirrors/download.fedora.redhat.com/pub/fedora/linux/releases/14/Fedora/x86_64/os --extra-args="ks=http://192.168.122.1:8080/kickstarts/fedora_base.ks"

Starting install...
Retrieving file .treeinfo...                                                                                                                       | 2.0 kB     00:00 ... 
Retrieving file vmlinuz...                                                                                                                         | 7.2 MB     00:00 ... 
Retrieving file initrd.img...                                                                                                                      |  61 MB     00:00 ... 
ERROR    internal error Process exited while reading console log output: char device redirected to /dev/pts/2
qemu: 'unknown' invalid format


Domain installation does not appear to have been
successful. If it was, you can restart your domain
by running 'virsh start iscsi01'; otherwise, please
restart your installation.

Comment 2 Cole Robinson 2011-03-23 21:29:31 UTC

*** This bug has been marked as a duplicate of bug 647241 ***