Problem with pve-qemu-kvm: 0.15.0-1

Frank.Pawlik

Member
Oct 21, 2009
47
0
6
Hello.
After upgrading to 1.9 one vm was not starting.
The vm is a Windows2003 Standard Server with virtio as HD and NIC.
pveversion -v
pve-manager: 1.9-24 (pve-manager/1.9/6542)
running kernel: 2.6.32-6-pve
proxmox-ve-2.6.32: 1.9-43
pve-kernel-2.6.32-6-pve: 2.6.32-43
qemu-server: 1.1-32
pve-firmware: 1.0-13
libpve-storage-perl: 1.0-19
vncterm: 0.9-2
vzctl: 3.0.28-1pve5
vzdump: 1.2-15
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.15.0-1
ksm-control-daemon: 1.0-6

After downgrading pve-qemu-kvm the vm started smooth.
pveversion -v
pve-manager: 1.9-24 (pve-manager/1.9/6542)
running kernel: 2.6.32-6-pve
proxmox-ve-2.6.32: 1.9-43
pve-kernel-2.6.32-4-pve: 2.6.32-33
pve-kernel-2.6.32-6-pve: 2.6.32-43
qemu-server: 1.1-32
pve-firmware: 1.0-13
libpve-storage-perl: 1.0-19
vncterm: 0.9-2
vzctl: 3.0.28-1pve5
vzdump: 1.2-15
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.14.1-1
ksm-control-daemon: 1.0-6

I think this is a problem with graphics.
Machine was starting and should switch resolution but went with a black screen.
In save-mode the vm could start.


greets
 
post your VMID.conf file.

and do you run your windows as "standard PC"? i386 or amd64 windows version?

do you use the latest virtio windows drivers?

as soon as I got all these information I will try to reproduce this issue in our lab.
 
name: Mail
ostype: w2k3
memory: 3072
onboot: 1
sockets: 1
cores: 4
acpi: 1
kvm: 1
virtio1: LVM-VM-Disks:vm-101-disk-2,cache=none
virtio0: LVM-VM-Disks:vm-101-disk-1,cache=none
freeze: 0
cpuunits: 10000
bootdisk: virtio0
hostusb: 057c:1900
args: -cpu host
virtio2: LVM-VM-Disks:vm-101-disk-3,cache=none,backup=no
description: 192.148.150.3
ide0: none,media=cdrom
boot: c
vlan0: e1000=7E:04:97:0B:AF:D9

I switched nic to e1000. No change.
Computer is ACPI-Multiprozessor-PC (i386).
Virtio SCSI Controller is 6.0.0.10 .
 
Last edited:
Hello.

vga: std did the job for that vm.

But I have a vm with exactly the same configuration where
Standard VGA dis not work here.
 
I've done some tests.
I reinstalled
pve-qemu-kvm: 0.15.0-1 on machine 2 and rebootet vm2.
vm2 was booting.
I rebooted vm1 on machine 1 with
pve-qemu-kvm: 0.15.0-1 and it was not booting.
I installed pve-qemu-kvm: 0.14.1-1 on machine 1 and vm 1 booted again.
I think it have to do with usb-passtrough.
 
Maybe I have to blacklist the USB-ISDN-Adapter.

I blacklisted modules
avm
avmfritz

I will test it soon.

[Edited]
Blacklisting does not work.
I have to stick with pve-qemu-kvm: 0.14.1-1 until an update comes.
 
Last edited:
EDIT: Seems it does not work as expected - the vm boots now, but the usb device is not visible :-(
EDIT2: A much simpler solution is to downgrade the qemu-kvm package to 0.14.1 - would have save me a whole day if I had tought of it earlier.

wget ftp://download1.proxmox.com/debian/dists/lenny/pve1.8/binary-amd64/pve-qemu-kvm_0.14.1-1_amd64.deb
and
dpkg -i pve-qemu-kvm_0.14.1-1_amd64.deb

The following process does not work, but I'll leave it here for information about the actual problem:

I've had the same problem in conjunction with our usb avm isdn adapter, being the same as yours (057c:1900). Also here pve-qemu-kvm_0.15.0-2_amd64.deb from pvetest did not solve the problem.

When running kvm without the --daemonize switch an error was being displayed:
hw/usb.c:333: usb_packet_complete: Assertion `p->owner != ((void *)0)' failed.

I've found the following patch, which I applied manually to the kvm 0.15.1 from http://sourceforge.net/projects/kvm/

http://patchwork.ozlabs.org/patch/118726/

And while I was at editing, I just commented out the annoying assert-statement too.

Then I applied the patches for qemu for proxmox pve 2.0 beta (needed several manual corrections as some patches were already applied as they are for a older qemu version) and now my vm is up and running including usb support.

The process of applying the patches was not too easy, so only try this if you know patch/configure/make and enough C to fix errors.

It would be great if proxmox could supply a patched version. I myself just could not wait for this as my collouges need it for their daily work.

@Proxmox: Thanks for this great product.
 
Last edited: