Bug 669935 - bad guest configuration generated for iscsi disks
bad guest configuration generated for iscsi disks
Status: CLOSED DUPLICATE of bug 647241
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
14
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-15 18:20 EST by Nathan Lynch
Modified: 2011-03-23 17:29 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-23 17:29:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nathan Lynch 2011-01-15 18:20:09 EST
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 19:51:19 EDT
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 17:29:31 EDT

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

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