← Back to team overview

registry team mailing list archive

[Bug 607355] [NEW] Problems launching instances

 

Public bug reported:

I'm struggling to launch an image (on physical hardware, using KVM)

I've tried building my own image, using ubuntu's vmbuilder, and got that
to build an image.  However, I can't launch this through nova.

The compute service logs this error:

DEBUG:root:Starting instance i-lrpnh3ta...
DEBUG:root:Result was 1
DEBUG:root:Starting VLAN inteface for 100 network
DEBUG:root:Result was 1
DEBUG:root:Result was 1
DEBUG:root:Result was 255
DEBUG:root:Finished init of Instance with id of i-lrpnh3ta
INFO:root:Instances current state is 0
DEBUG:root:Instance state is: 0
DEBUG:root:Starting spawn in Instance
DEBUG:root:Starting the toXML method
DEBUG:root:Finished the toXML method
INFO:root:self <nova.compute.node.Instance object at 0x2e56e50>
INFO:root:Creating image for: i-lrpnh3ta
WARNING:root:Input partition size not evenly divisible by sector size: 169 / 512
libvir: QEMU error : monitor socket did not show up.: Connection refused
DEBUG:root:monitor socket did not show up.: Connection refused


Peeking behind the libvirt obfuscation:

sudo more /var/log/libvirt/qemu/i-lrpnh3ta.log 
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin /usr/bin/qemu-system-x86_64 -S -M pc-0.12 -no-kvm -m 1024 -smp 1 -name i-lrpnh3ta -uuid b43ba850-2170-6a96-18ec-0f4f67a472dc -nographic -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/i-lrpnh3ta.monitor,server,nowait -monitor chardev:monitor -boot c -kernel /home/justinsb/openstack/iscsi-volumes/data/instances/i-lrpnh3ta/kernel -initrd /home/justinsb/openstack/iscsi-volumes/data/instances/i-lrpnh3ta/ramdisk -append root=/dev/vda1 console=ttyS0 -drive file=/home/justinsb/openstack/iscsi-volumes/data/instances/i-lrpnh3ta/disk,if=virtio,index=0,boot=on -net nic,macaddr=00:16:3e:76:88:f5,vlan=0,name=nic.0 -net tap,fd=44,vlan=0,name=tap.0 -chardev file,id=serial0,path=/home/justinsb/openstack/iscsi-volumes/data/instances/i-lrpnh3ta/console.log -serial chardev:serial0 -parallel none -usb 
qemu: linux kernel too old to load a ram disk


I'm using the kernel from /boot/vmlinuz-$(uname -r) on the host (Lucid
Lynx); this might not be right.

However, taking that KVM command, I can change it so that I can boot the
original VM:

* I remove the -S (stop) and monitor stuff so that it won't wait for
libvirt, and the -nographic arg so that I can see what's going on.

* If I remove the -kernel, -initrd, and -append arguments I can get KVM
to stop complaining about "kernel too old to load a ram disk"

* If I leave the disk image as-is, it won't boot - it just hangs at the
BIOS "Booting from Hard Disk" message  (maybe nova is creating a
corrupted disk image, c.f. "Input partition size not evenly divisible by
sector size: 169 / 512" message?)

* If I swap the disk image to the original disk image created by
vmbuilder, it hangs at "GRUB loading stage2"

* If I remove -no-kvm, I can use the grub menu, but it then hangs when starting the actual image (at "Starting up").  I now get these error messages from KVM:
TUNGETIFF ioctl() failed: Bad file descriptor
TUNSETOFFLOAD ioctl() failed: Bad file descriptor

* If I remove the tap device (-net tap,fd=44,vlan=0,name=tap.0), then
the machine boots and I can log in.

* (If I put the disk image back to the disk image nova created, it hangs
as before on "Booting from Hard Disk")


There's a whole bunch of questions here:

Why are we using a kernel and ramdisk anyway - why not just rely on hardware virtualization?  We presumably also wouldn't need to mess with the disk image...
How is that -no-kvm argument sneaking in there?  I'm guessing it's something I've misconfigured in the libvirt template?
What is the correct way to build disk images, and where should the ramdisk & kernel come from?  Is there a way to boot a raw image without ramdisk/kernel?

** Affects: nova
     Importance: Undecided
         Status: New

-- 
Problems launching instances
https://bugs.launchpad.net/bugs/607355
You received this bug notification because you are a member of Registry
Administrators, which is subscribed to OpenStack.



Follow ups

References