openSuSE 13.1: virt-manager fails to create virtual machine

English Virtualization
1

Greetings!

When attempting to create a virtual machine the virt-manager somehow gets upset when attempting to allocate the storage pool.

The situation:
Box A:

  • Xen-aware kernel 3.11.6-4-xen
  • Xen: 4.3.0_14
  • libvirt: 1.1.2
    All properly set up and running
    Intended vm layout on box A:
  • Memory allocation: 2GB
  • CPU allocation: 2
  • Networking: Delegated to libvirt without xend interfering (routed virtual nnetworking; NO NAT, NO bridging!) - looks o.k.
  • Installation media: DVD-ROM (attached as pre-formatted fs) - looks o.k.
  • Disk (complete disk image within /dev/sda4) - failure!
  • Intended guest OSes: openSuSE 13.1 and Windoze 7 (in two separate VMs)

Box B:

  • Normal kernel without Xen
  • Running virt-manager for access to box A

Box A has the port assigned to libvirt open in its firewall so remote connections are possible.
Remote connection configured as xen+tcp (with SASL authentication) - authentication successful.

When I attempt to generate a new machine the installation wizard first starts setting things up when clicking on “Finish”, but eventually complains with the following detailed output (no matter which OS I have chosen):


Installation konnte nicht fertiggestellt werden: «POST-Operation schlug fehl: xend_post: Fehler von xen-Daemon: (xend.err 'Error creating domain: Block device type "qemu" is invalid.')»

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 2022, in do_install
    guest.start_install(False, meter=meter)
  File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1251, in start_install
    noboot)
  File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1319, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2886, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: POST-Operation schlug fehl: xend_post: Fehler von xen-Daemon: (xend.err 'Error creating domain: Block device type "qemu" is invalid.')

When I try to edit the configuration before actually installing the guest everything can be properly edited, again except for the mass storage (complaining with this error message as soon as I click on the disk icon):


Fehler beim Neuladen der Hardwareseite: unsupported operand type(s) for /: 'NoneType' and 'int'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/details.py", line 1307, in hw_selected
    self.refresh_disk_page()
  File "/usr/share/virt-manager/virtManager/details.py", line 2921, in refresh_disk_page
    iotune_read_bytes_sec = disk.iotune_read_bytes_sec / 1024
TypeError: unsupported operand type(s) for /: 'NoneType' and 'int'

The same thing happens when I attempt to create a disk image file instead.

Any idea on what could be happening here? Something seems to go thoroughly haywire here, but I cannot figure out what it could be, especially since I cannot find any XML files that I could examine.

Any help would be greatly appreciated.

2

Digging through xend.log I noticed something strange:
When xend attempts to set up /dev/sda4 as a DASD for the VM, everything seems to be o.k.
However, when xend attempts to set up the DVD ROM, the entire process aborts.


[2013-12-31 21:43:50 780] DEBUG (XendDomainInfo:103) XendDomainInfo.create('vm', 'name', 'Arbeitsplatz'], 'memory', '2048'], 'maxmem', '2048'], 'vcpus', '2'], 'uuid', 'a67b0340-f252-1ba5-76c1-2e3c57db1d68'], 'on_poweroff', 'destroy'], 'on_reboot', 'destroy'], 'on_crash', 'destroy'], 'image', 'hvm', 'kernel', '/usr/lib/xen/boot/hvmloader'], 'vcpus', '2'], 'boot', 'dc'], 'acpi', '1'], 'apic', '1'], 'pae', '1'], 'usb', '1'], 'parallel', 'none'], 'serial', 'pty'], 'soundhw', 'es1370'], 'device_model', '/usr/lib64/xen/bin/qemu-dm'], 'vnc', '1'], 'vncunused', '1'], 'keymap', 'en-us'], 'rtc_timeoffset', '0'], 'localtime', '0']]], 'localtime', '0'], 'device', 'vbd', 'dev', 'hda:disk'], 'uname', 'phy:/dev/sda4'], 'mode', 'w']]], 'device', 'vbd', 'dev', 'hdc:cdrom'], 'uname', 'qemu:/dev/sr0'], 'mode', 'r']]], 'device', 'vif', 'mac', '00:16:3e:5b:e8:b6'], 'bridge', 'veth0'], 'script', 'vif-bridge']]]])
[2013-12-31 21:43:50 780] DEBUG (XendDomainInfo:2594) XendDomainInfo.constructDomain
[2013-12-31 21:43:50 780] DEBUG (balloon:206) Balloon: 2131732 KiB free; need 16384; done.
[2013-12-31 21:43:50 780] DEBUG (XendDomain:476) Adding Domain: 10
[2013-12-31 21:43:50 780] DEBUG (XendDomainInfo:2940) XendDomainInfo.initDomain: 10 256
[2013-12-31 21:43:50 780] DEBUG (image:343) Stored a VNC password for vfb access
[2013-12-31 21:43:50 780] DEBUG (image:981) args: boot, val: dc
[2013-12-31 21:43:50 780] DEBUG (image:981) args: fda, val: None
[2013-12-31 21:43:50 780] DEBUG (image:981) args: fdb, val: None
[2013-12-31 21:43:50 780] DEBUG (image:981) args: soundhw, val: es1370
[2013-12-31 21:43:50 780] DEBUG (image:981) args: localtime, val: 0
[2013-12-31 21:43:50 780] DEBUG (image:981) args: serial, val: 'pty']
[2013-12-31 21:43:50 780] DEBUG (image:981) args: std-vga, val: None
[2013-12-31 21:43:50 780] DEBUG (image:981) args: isa, val: None
[2013-12-31 21:43:50 780] DEBUG (image:981) args: acpi, val: 1
[2013-12-31 21:43:50 780] DEBUG (image:981) args: usb, val: 1
[2013-12-31 21:43:50 780] DEBUG (image:981) args: usbdevice, val: None
[2013-12-31 21:43:50 780] DEBUG (image:981) args: gfx_passthru, val: None
[2013-12-31 21:43:50 780] DEBUG (image:981) args: watchdog, val: None
[2013-12-31 21:43:50 780] DEBUG (image:981) args: watchdog-action, val: None
[2013-12-31 21:43:50 780] INFO (image:909) Need to create platform device.[domid:10]
[2013-12-31 21:43:50 780] DEBUG (XendDomainInfo:2967) _initDomain:shadow_memory=0x0, memory_static_max=0x80000000, memory_static_min=0x0.
[2013-12-31 21:43:50 780] INFO (image:188) buildDomain os=hvm dom=10 vcpus=2
[2013-12-31 21:43:50 780] DEBUG (image:1074) domid          = 10
[2013-12-31 21:43:50 780] DEBUG (image:1075) image          = /usr/lib/xen/boot/hvmloader
[2013-12-31 21:43:50 780] DEBUG (image:1076) store_evtchn   = 4
[2013-12-31 21:43:50 780] DEBUG (image:1077) memsize        = 2048
[2013-12-31 21:43:50 780] DEBUG (image:1078) target         = 2048
[2013-12-31 21:43:50 780] DEBUG (image:1079) vcpus          = 2
[2013-12-31 21:43:50 780] DEBUG (image:1080) vcpu_avail     = 3
[2013-12-31 21:43:50 780] DEBUG (image:1081) acpi           = 1
[2013-12-31 21:43:50 780] DEBUG (image:1082) apic           = 1
[2013-12-31 21:43:50 780] DEBUG (image:1083) smbios_firmware= 
[2013-12-31 21:43:50 780] DEBUG (image:1084) acpi_firmware  = 
[2013-12-31 21:43:50 780] INFO (XendDomainInfo:2453) createDevice: vfb : {'vncunused': '1', 'keymap': 'en-us', 'vnc': '1', 'uuid': '28905c9b-7b24-36ac-ad41-789ca3b53e2b', 'other_config': {'vncunused': '1', 'keymap': 'en-us', 'vnc': '1'}}
[2013-12-31 21:43:50 780] DEBUG (DevController:95) DevController: writing {'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend/vfb/10/0'} to /local/domain/10/device/vfb/0.
[2013-12-31 21:43:50 780] DEBUG (DevController:97) DevController: writing {'vncunused': '1', 'domain': 'Arbeitsplatz', 'frontend': '/local/domain/10/device/vfb/0', 'uuid': '28905c9b-7b24-36ac-ad41-789ca3b53e2b', 'frontend-id': '10', 'state': '1', 'keymap': 'en-us', 'online': '1', 'vnc': '1'} to /local/domain/0/backend/vfb/10/0.
[2013-12-31 21:43:50 780] INFO (XendDomainInfo:2453) createDevice: vbd : {'uuid': '2e495735-42bf-7431-dd32-999697ec0ad3', 'bootable': 1, 'driver': 'paravirtualised', 'dev': 'hda:disk', 'uname': 'phy:/dev/sda4', 'mode': 'w'}
[2013-12-31 21:43:50 780] DEBUG (DevController:95) DevController: writing {'backend-id': '0', 'virtual-device': '768', 'device-type': 'disk', 'state': '1', 'backend': '/local/domain/0/backend/vbd/10/768'} to /local/domain/10/device/vbd/768.
[2013-12-31 21:43:50 780] DEBUG (DevController:97) DevController: writing {'domain': 'Arbeitsplatz', 'frontend': '/local/domain/10/device/vbd/768', 'uuid': '2e495735-42bf-7431-dd32-999697ec0ad3', 'bootable': '1', 'dev': 'hda', 'state': '1', 'params': '/dev/sda4', 'mode': 'w', 'online': '1', 'frontend-id': '10', 'type': 'phy'} to /local/domain/0/backend/vbd/10/768.
[2013-12-31 21:43:50 780] INFO (XendDomainInfo:2453) createDevice: vbd : {'uuid': '120cb710-e459-870c-673e-bf2bac33ef30', 'bootable': 0, 'driver': 'paravirtualised', 'dev': 'hdc:cdrom', 'uname': 'qemu:/dev/sr0', 'mode': 'r'}
[2013-12-31 21:43:50 780] ERROR (XendDomainInfo:3029) XendDomainInfo.initDomain: exception occurred
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 3018, in _initDomain
    self._createDevices()
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 2460, in _createDevices
    devid = self._createDevice(devclass, config)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 2418, in _createDevice
    return self.getDeviceController(deviceClass).createDevice(devConfig)
  File "/usr/lib64/python2.7/site-packages/xen/xend/server/DevController.py", line 63, in createDevice
    (devid, back, front) = self.getDeviceDetails(config)
  File "/usr/lib64/python2.7/site-packages/xen/xend/server/blkif.py", line 68, in getDeviceDetails
    raise VmError('Block device type "%s" is invalid.' % typ)
VmError: Block device type "qemu" is invalid.
[2013-12-31 21:43:50 780] ERROR (XendDomainInfo:505) VM start failed
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 491, in start
    XendTask.log_progress(31, 60, self._initDomain)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendTask.py", line 209, in log_progress
    retval = func(*args, **kwds)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 3032, in _initDomain
    raise exn
VmError: Block device type "qemu" is invalid.
[2013-12-31 21:43:50 780] DEBUG (XendDomainInfo:3187) XendDomainInfo.destroy: domid=10
[2013-12-31 21:43:51 780] DEBUG (XendDomainInfo:2497) Destroying device model
[2013-12-31 21:43:51 780] ERROR (XendDomainInfo:2500) Device model destroy failed X86_HVM_ImageHandler instance has no attribute 'sentinel_lock'
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 2498, in _releaseDevices
    self.image.destroyDeviceModel()
  File "/usr/lib64/python2.7/site-packages/xen/xend/image.py", line 708, in destroyDeviceModel
    self.sentinel_lock.acquire()
AttributeError: X86_HVM_ImageHandler instance has no attribute 'sentinel_lock'
[2013-12-31 21:43:51 780] DEBUG (XendDomainInfo:2504) Releasing devices
[2013-12-31 21:43:51 780] DEBUG (XendDomainInfo:2510) Removing vbd/768
[2013-12-31 21:43:51 780] DEBUG (XendDomainInfo:1310) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
[2013-12-31 21:43:51 780] DEBUG (XendDomainInfo:2510) Removing vfb/0
[2013-12-31 21:43:51 780] DEBUG (XendDomainInfo:1310) XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0
[2013-12-31 21:43:51 780] ERROR (XendDomainInfo:108) Domain construction failed
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 106, in create
    vm.start()
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 491, in start
    XendTask.log_progress(31, 60, self._initDomain)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendTask.py", line 209, in log_progress
    retval = func(*args, **kwds)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 3032, in _initDomain
    raise exn
VmError: Block device type "qemu" is invalid.
[2013-12-31 21:43:51 780] ERROR (SrvBase:88) Request create failed.
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/web/SrvBase.py", line 85, in perform
    return op_method(op, req)
  File "/usr/lib64/python2.7/site-packages/xen/xend/server/SrvDomainDir.py", line 82, in op_create
    raise XendError("Error creating domain: " + str(ex))
XendError: Error creating domain: Block device type "qemu" is invalid.

The offending line here seems to be this one:
[2013-12-31 21:43:50 780] INFO (XendDomainInfo:2453) createDevice: vbd : {‘uuid’: ‘120cb710-e459-870c-673e-bf2bac33ef30’, ‘bootable’: 0, ‘driver’: ‘paravirtualised’, ‘dev’: ‘hdc:cdrom’, ‘uname’: ‘qemu:/dev/sr0’, ‘mode’: ‘r’}

Something seems to get the storage type completely wrong, thereby screwing up the installation process.
Any ideas on how this could be corrected?

3

For starters,
In 12.2 and 12.3 I encountered issues creating and using Storage Pools that were non-default (and reported to bugzilla). I haven’t followed up to test whether those issues were resolved.

So, did you set up custom Storage Pools at all (I don’t see that you have mentioned anything).

Storage Pools aren’t necessarily a “must” requirement, I’ve also pointed to locations manually. Is that what you are doing? If so, one of the things you need to do is make sure you have “World” Read/Write permissions on the locations. Default permissions may not be sufficient, especially since I see that you may be storing your images on a machine separate from your virtualization technology (Xen on Box A and I’m not sure but may be QEMU/KVM on Box B).

Regarding your remote vm manager, did you setup through vm manager? You may need to describe your steps to verify it was done properly.

When first setting up for the first time, I’d recommend if possible a default configuration (local app, local storage, default locations). That almost certainly gets you a working configuration. From there, you can customize (eg remote storage, even remote management) and can better isolate any issues you encounter.

HTH,
TSU

4

Thanks for your reply.

As far as the current layout is concerned, everything concerning virtualization is taking place on box A (the one that’s running xen). Box B merely serves as a remote control for xend/libvirtd, so the storage in question resides entirely on box A.

The only thing that has to do with virtualization that is actually running on box B therefore is virt-manager.

Now, what I did for starters is the following:

  • Manually disable xend’s networking capability (by editing its config file) so that it doesn’t interfere with libvirtd (the latter neatly sets up the virtual interface in dom0 which I can ping without any problems). This NIC is properly recognized when attempting to set up the VM.
  • Register the system’s hd as a storage pool (physical disk) - I need access to /dev/sda3 and /dev/sda4, each is supposed to be available to distinct VMs. However, without generating this pool I haven’t found any way to attach any of the partitions.
  • Register the DVD ROM as a pre-formatted file system (physical disk wouldn’t work), otherwise I cannot select it as an installation source.
  • All storage pools are residing on box A (IMO it doesn’t make sense to generate them somewhere else and then export them back to the box running xen).

Now, libvirtd is perfectly reachable for box B (port 16509 opened in the firewall) and SASL set up for authentication.
The connection type that I’m using to connect virt-manager to box A is xen - QEMU/KVM failed (the connection is rejected), and I haven’t tried LXC yet.

Then, when I attempt to generate a virtual machine, I just follow the installation wizard which queries for certain settings (installation from physical CD ROM is only available when it has previously been registered and physical storage also requires a storage pool).
However, when I click on “Finish” the installation process hiccups and throws an exception when attempting to configure the CD ROM. As I can tell from the logs the virtual hd seems to be set up o.k.
However, what bothers me is that virt-manager prepends qemu: as a “device type” to /dev/sr0 (my DVD ROM) - which is what’s causing things to go haywire. In contrast, when setting up the hd it correctly prepends phy: to /dev/sda4.

The point is that I may have a KDM running on box A, but no KDE (since I’m going to set up the actual workspace in a domU I see no point in adding users to dom0 or setting up a full-fledged KDE there. I instead intend it to act as a router and security layer as well as an XDMCP client).

You mentioned setting up things manually. Unfortunately I currently have absolutely no idea on how to do that (I might have already taken a brief look into virsh, but most of its options still beat me).

5

If your problem is only the virtual CDROM,
I wonder if your problem might be one I identified a long time ago but was fixed.

If you are able to select an ISO file using the wizard, doublecheck the path to the ISO file. Awhile back, there was an error prepending a string to the correct path. If you remove the prepended string (or otherwise manually enter a correct path), the virtual CDROM would work fine.

If this is the problem, it should be reported in bugzilla as re-appearing.

TSU

6

Unfortunately the exact same nonsense happens when I attempt to install from an ISO image (here qemu: is prepended to the path of the ISO file instead of file: as it should have been).
When generating a hd image file that one is correctly prepended with file: …

That should definitely leave the part that is supposed to set up the virtual CD ROM as the culprit.

I’m currently digging through bugzilla - if this kind of bug has already been reported, I should find it (maybe something got messed up by transitioning to the current version of virt-manager?).

7

If you search on my handle (TSU2) it should come up.
But if it doesn’t, don’t worry too much.
Just report it mentioning this bug has been fixed before and someone else will tie the bugs together.
Make sure this is <NEW> and <UNRESOLVED> despite the bug having been fixed before.

TSU

8

The point is that there’s no spurious addition to the path (therefore nothing can be corrected here), but instead the wrong device type (i. e. something that I cannot influence) is prepended.
And strangely enough, the DASD is set up correctly (by prepending phy: as a device type for a hd partition and file: for a hd image file), merely the installation media is messed up.

I also have reported this bug - however, tying it to the problem you had reported doesn’t seem to make sense, because they seem to be two distinct problems.

Is there any way that I could possibly inject the parameters (then with correct values) from virt-manager directly into libvirtd to trigger an installation (e. g. by abusing Telnet, etc.)? Setting up an XML file describing the desired VM and then applying it with the aid of virsh is not an option so far, because I wouldn’t even know how to do so correctly…

9

If you’re using vm install (a gui install tool), then <after> selecting the iso file to assign to the virtual CDROM but <before> clicking “OK” (or whatever) to confirm the selection you should have an opportunity to inspect the path to the iso file or physical device (in general you should be using iso files all the time anyway instead of burning plastic). The path should make sense, and should be similar to a path you would see if you browsed to the file using a File Manager like Dolphin. Although likely the same path as what you might see in a console but I wouldn’t recommend that for doublechecking because the console environment can be different than the Desktop environment.

If you’re running libvirt in the CLI, then…
YMMV. As I said, the environment might be different. But, in that case I’d consider simply mounting the device or file before accesing.

TSU