pvetest: machine q35 and spice error

[XueSheng]

I'm on pvetest and noticed that "machine: q35" is only working if spice (vga: qxl) is disabled. See configs/logs for details:

# pveversion -v
proxmox-ve-2.6.32: 3.2-134 (running kernel: 3.10.0-4-pve)
pve-manager: 3.2-23 (running version: 3.2-23/bd7b6eb4)
pve-kernel-3.10.0-4-pve: 3.10.0-15
pve-kernel-2.6.32-32-pve: 2.6.32-134
pve-kernel-2.6.32-31-pve: 2.6.32-132
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.7-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.10-1
pve-cluster: 3.0-14
qemu-server: 3.1-30
pve-firmware: 1.1-3
libpve-common-perl: 3.0-19
libpve-access-control: 3.0-15
libpve-storage-perl: 3.0-21
pve-libspice-server1: 0.12.4-3
vncterm: 1.1-8
vzctl: 4.0-1pve6
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 2.1-3
ksm-control-daemon: 1.1-1
glusterfs-client: 3.4.2-1

# cat /etc/pve/qemu-server/100.conf
#Proxmox DEV Installation
balloon: 512
boot: c
bootdisk: virtio0
cores: 2
ide2: none,media=cdrom
machine: q35
memory: 2048
name: mySandbox
net0: virtio=86:33:BC:FF:66:86,bridge=vmbr0
ostype: l26
sockets: 1
vga: qxl
virtio0: local:100/vm-100-disk-1.qcow2,format=qcow2,backup=no,size=20G

Error on VM start:

kvm: -device virtio-serial,id=spice,bus=pci.0,addr=0x9: Bus 'pci.0' not found
TASK ERROR: start failed: command '/usr/bin/kvm -id 100 -chardev 'socket,id=qmp,path=/var/run/qemu-server/100.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -vnc unix:/var/run/qemu-server/100.vnc,x509,password -pidfile /var/run/qemu-server/100.pid -daemonize -name mySandbox -smp 'sockets=1,cores=2' -nodefaults -boot 'menu=on' -vga qxl -cpu kvm64,+lahf_lm,+x2apic,+sep -k de -spice 'tls-port=61001,addr=127.0.0.1,tls-ciphers=DES-CBC3-SHA,seamless-migration=on' -device 'virtio-serial,id=spice,bus=pci.0,addr=0x9' -chardev 'spicevmc,id=vdagent,name=vdagent' -device 'virtserialport,chardev=vdagent,name=com.redhat.spice.0' -m 2048 -readconfig /usr/share/qemu-server/pve-q35.cfg -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:d46c8540e99' -drive 'if=none,id=drive-ide2,media=cdrom,aio=native' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2' -drive 'file=/var/lib/vz/images/100/vm-100-disk-1.qcow2,if=none,id=drive-virtio0,format=qcow2,aio=native,cache=none' -device 'virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100' -netdev 'type=tap,id=net0,ifname=tap100i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,romfile=,mac=86:33:BC:FF:66:86,netdev=net0,bus=pci.0,addr=0x12,id=net0' -machine 'type=q35'' failed: exit code 1

As mentioned. Disabling "vga: qxl" solves this issue and VM starts flawlessly again. Any clue why this is happening?

 

[mcflym]

I think it is a expected behaviour.

 

[XueSheng]

mcflym, can you explain why this behaviour is expected?

I, as a enduser, would expect that it doesn't matter which video device I choose (even if q35/pcie is enabled).

 

[spirit]

Thanks for the report, it's indeed a bug.

I'm not sure it's a proxmox bug because it's working with other devices. maybe it's a qemu virtio-serial bug, not working on pci bridge.

I'll check that.

 

[spirit]

Ok, I have sent a fix to the dev mailing list.

Thanks again for the report.

 

[linum]

This is already reported as a bug (at 2014-06-13), see https://bugzilla.proxmox.com/show_bug.cgi?id=529

 

[mcflym]

Well, i was wrong... good to hear that it will work!

 

[XueSheng]

Yesterday I built the latest git qemu-server 3.1-31 package (including patch generate spice devices cmd line after pci bridge). Now machine q35 works as expected with and without spice (vga qxl).

Spirit, thanks for investigating and fixing this issue!

 

[spirit]

Yesterday I built the latest git qemu-server 3.1-31 package (including patch generate spice devices cmd line after pci bridge). Now machine q35 works as expected with and without spice (vga qxl).

Spirit, thanks for investigating and fixing this issue!

Yes,it was a proxmox bug finally