Comment 1 Philipp Hahn 2011-03-25 16:26:35 CET

Dann habe ich das in Bug #20253 kaputt gemacht, denn vorher ging das.

Comment 2 Philipp Hahn 2011-03-25 20:00:36 CET

PY DUMP: {
'kernel': None,
'curMem': 0L,
'vcpus': 1,
'uuid': 'c3dd2ea2-748b-3d15-f63e-64eaa2399a4a',
'boot': ['cdrom', 'hd'],
'interfaces': [<univention.uvmm.protocol.Interface object at 0x7f2484569a50>],
'disks': [<univention.uvmm.protocol.Disk object at 0x7f24845693d0>],
'bootloader_args': None,
'state': 5,
'cputime': [0.0, 0.0, 0.0],
'domain_type': u'kvm',
'cmdline': None,
'initrd': None,
'snapshots': {},
'graphics': [<univention.uvmm.protocol.Graphic object at 0x7f2484569650>],
'maxMem': 805306368L,
'os_type': u'hvm',
'bootloader': None,
'arch': u'i686',
'annotations': {
  'contact': '',
  'os': u'Microsoft Windows 2003',
  'uuid': 'c3dd2ea2-748b-3d15-f63e-64eaa2399a4a',
  'description': ''},
'name': u'w2k3-vnc'
}

XML DUMP:
<?xml version="1.0"?>
<domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm">
  <name>w2k3-vnc</name>
  <uuid>c3dd2ea2-748b-3d15-f63e-64eaa2399a4a</uuid>
  <memory>786432</memory>
  <currentMemory>786432</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch="i686" machine="pc-0.14">hvm</type>
    <boot dev="cdrom"/>
    <boot dev="hd"/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset="utc"/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>destroy</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <controller index="0" type="ide">
      <address bus="0x00" domain="0x0000" function="0x1" slot="0x01" type="pci"/>
    </controller>
    <input bus="usb" type="tablet"/>
    <memballoon model="virtio">
      <address bus="0x00" domain="0x0000" function="0x0" slot="0x03" type="pci"/>
    </memballoon>
    <disk device="disk" type="file">
      <driver name="qemu" type="qcow2"/>
      <source file="/var/lib/libvirt/images/w2k3-vnc-0.qcow2"/>
      <target bus="ide" dev="hda"/>
      <address bus="0" controller="0" type="drive" unit="0"/>
    </disk>
    <interface type="bridge">
      <mac address="52:54:00:25:3f:c6"/>
      <source bridge="eth0"/>
      <address bus="0x00" domain="0x0000" function="0x0" slot="0x02" type="pci"/>
    </interface>
    <graphics autoport="yes" keymap="de" listen="0.0.0.0" port="-1" type="vnc"/>
  </devices>
  <qemu:commandline xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0"/>
</domain>

"PCI address 0:0:2" ist bereits durch den Netzwerkkarte belegt, keine Ahnung warum der VNC-Grafikkarte die gleiche Adresse unbedingt zugewiesen werden soll. Aus UVMM-Sicht wird das zumindest nirgendwo erzwungen, scheint also ein Problem in libvirt zu sein:

src/qemu/qemu_command.c:988#qemuDomainAssignPCIAddresses()
      /* First VGA is hardcoded slot=2 */

Comment 3 Philipp Hahn 2011-03-25 20:01:22 CET

Created attachment 3144 [details]
Reserve first 3 slots for hardcoded devices

In modifizierte Form an die libvirt-ML geschickt.

Comment 4 Philipp Hahn 2011-04-08 08:45:25 CEST

Upstream-Patch für libvirt-0.9.0: <http://www.redhat.com/archives/libvir-list/2011-April/msg00243.html>

Comment 5 Philipp Hahn 2012-09-20 09:09:21 CEST

Da wir mit UCS-3.1 libvirt 0.9.14 verwendet, ist der Bugfix darin enthalten und das Problem damit gelöst.
Es ist lediglich zu beachten, daß bei alten VMs das immer noch nicht funktionieren wird, solange dort die PCI-Adresse 0:0:2 durch ein anderes Gerät blockiert ist. I.d.R. kann man per "virsh edit $VM" einfach die <address...>-Einträge herauslöschen, wodurch libvirt die dann beim Speichern automatisch neu vergiebt.

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

Comment 6 Stefan Gohmann 2013-06-26 11:50:15 CEST

OK