Imported KVM instance will not boot

Submitted by rheilbroun on Mon, 02/21/2011 - 17:23

When using "Register a system for KVM hosting", the existing/runnning KVM instances on the machine are not imported correctly which causes them not to boot. When we try to boot them using cloudmin, the qemu-kvm process is started but the VM seems to be halted/not doing anything.

Booting the VM using virt-manager, the process looks like this:

/usr/libexec/qemu-kvm -S -M rhel5.4.0 -m 4096 -smp 4 -name my-svc -uuid 82973420-7fee-bc72-2c0b-f02ea9168bb8 -no-kvm-pit-reinjection -monitor pty -pidfile /var/run/libvirt/qemu//my-svc.pid -boot c -drive file=/boot_drives/my-svc.img,if=virtio,index=0,boot=on,cache=none -drive file=,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:12:c1:62,vlan=0,model=virtio -net tap,fd=23,script=,vlan=0,ifname=vnet3 -serial pty -parallel none -usb -vnc 127.0.0.1:3 -k en-us

When booting the imported VM using Cloudmin, the process looks like this:

/usr/libexec/qemu-kvm -name my-svc -m 4096 -drive file=/boot_drives/my-svc.img,if=virtio,index=0,boot=on,cache=none -drive file=,if=ide,media=cdrom,index=2 -boot c -monitor stdio -net tap,fd=23,script=,vlan=0,ifname=vnet3 -net nic,vlan=0,macaddr=54:52:00:12:c1:62 -vnc :3,password -k en-us -smp 4 -S -usb -parallel none -monitor pty -uuid 82973420-7fee-bc72-2c0b-f02ea9168bb8 -M rhel5.4.0 -no-kvm-pit-reinjection -pidfile /var/run/libvirt/qemu//my-svc.pid

There are a few differences between these 2 (aside from the order...)

  1. Cloudmin omits "model=virtio" from the "-net nic..." command line param
  2. Cloudmin omits the "-serial pty" command line param
  3. Cloudmin set the vnc param to listen on all i IPs and use password protection
  4. Cloudmin adds a second "-monitor" param with a value of "stdio" (the second one on the command line says "pty")

I'm not sure which of these differences is causing the VM not to boot but I'm thinking it may have to do with the duplicate "-monitor" params causing the KVM monitor to wait for commands on the pty instead of stdio.

I can fix the "model=virtio" issue using the Cloudmin UI although it would be better if it was detected correctly.

The other 2 differences ("-serial pty" and "-vnc") don't seem like a big deal.

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Mon, 02/21/2011 - 20:37

Thanks for the pointing this out - the failure to detect the virtio model is a bug, which I'll fix in the next release.

The -serial and VNC flags are omitted intentionally, as Cloudmin sets console-related options at boot time to ensure it has the needed access to the KVM monitor.

The second -monitor flag is also a bug, which I'll fix. The work-around is to edit the VMs file under /etc/webmin/servers , find the kvm_args line and remove -monitor pty from it.

You can correct the network interface model at System Configuration -> Network Interfaces -> eth0.

Submitted by rheilbroun on Tue, 02/22/2011 - 14:04

Even after making these changes, the VM does not seem to want to start up.

The command line looks like this now:

/usr/libexec/qemu-kvm -name my-svc -m 4096 -drive file=/boot_drives/my-svc.img,if=virtio,index=0,boot=on,cache=none -drive file=,if=ide,media=cdrom,index=2 -boot c -monitor stdio -net tap,fd=23,script=,vlan=0,ifname=vnet3 -net nic,vlan=0,macaddr=54:52:00:12:c1:62,model=virtio -vnc :3,password -k en-us -smp 4 -S -usb -parallel none -uuid 82973420-7fee-bc72-2c0b-f02ea9168bb8 -M rhel5.4.0 -no-kvm-pit-reinjection -pidfile /var/run/libvirt/qemu//my-svc.pid

Cloudmin lists its status as "Ping failed" and I can't access it through the network. The vnc console for the VM shows a single line that says "serial0 console".

If I shut it down through Cloudmin, I can then start it up using virsh with no problem.

The only differences I see now in the qemu-kvm command line are the missing "-serial pty" and the password option to vnc. Is there anything else that could be wrong?

Submitted by JamieCameron on Tue, 02/22/2011 - 14:59

The use of script= with no value seems like it could also cause a problem. If you start the VM using virsh, does it also have that parameter? If not, try editing the file under /etc/webmin/servers and correcting the kvm_net line.

Submitted by rheilbroun on Wed, 02/23/2011 - 09:58

Yes, starting up with virsh also adds a script= parameter with no value to the tap device.

I'll try to play with this some more today but the only differences I see between virsh and cloudmin are:

  1. No "-serial pty" option in Cloudmin version
  2. password option on vnc
  3. Cloudmin runs the qemu-kvm command using the /usr/bin/pty.pl script

I don't see how any of these could be causing a problem.

Looking at the -S option to qemu-kvm, the doc says:

Do not start CPU at startup (you must type ’c’ in the monitor).

I guess virsh starts the VM up in a halted state and then tells it to continue. Is this something that Cloudmin does also or should this option have been skipped when importing the VM?

Submitted by JamieCameron on Wed, 02/23/2011 - 14:30

Cloudmin won't use the -S flag normally, but it will copy flags from an imported VM .. so if virtsh was setting -S and then using the KVM monitor to start the VM, this could cause a problem.

Try editing that same file under /etc/webmin/servers , finding the kvm_args line and removing -S from it.

Submitted by rheilbroun on Thu, 02/24/2011 - 09:39

The only difference when removing the "-S" flag was that the CPU for qemu-kvm was stuck at 100%.

I also tried removing the "fd=23" from the "-net tap,fd=23,script=,vlan=0,ifname=vnet3". This caused the VM to no longer hang but qemu-kvm just exits after a few seconds instead of starting up the vm.

What does a qemu-kvm command line for a KVM VM created directly in Cloudmin look like?

Submitted by JamieCameron on Thu, 02/24/2011 - 23:17

A regular KVM command started by Cloudmin is like :

/usr/bin/kvm -name kvmcentos.home -m 376 -hda /dev/kvm_vg/kvmcentos_home_img -boot c -monitor stdio -net tap,vlan=0,script=/kvm/kvmcentos.home-eth0.sh -net nic,vlan=0,macaddr=02:54:00:02:AC:AC -vnc :15,password

Submitted by Issues on Thu, 03/10/2011 - 23:21

Automatically closed -- issue fixed for 2 weeks with no activity.