OK, I see. Actually everything looks good in there - after investigating how libvirt does its thing and checking with 'virsh dumpxml' it looks as though the default CPU type is 64-bit so that's OK.
I've tried running the following: - sudo virsh create /var/lib/one/20/images/deployment.0 Domain one-20 created from /var/lib/one/20/images/deployment.0 (hangs after grub loads and presumably tries to boot the kernel) - running via open nebula (hangs after grub loads and presumably tries to boot the kernel) I've tried modifying the command that gets run via virsh create: /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 2048 -smp 4,sockets=4,cores=1,threads=1 -name one-20 -uuid 86deda31-a094-7f1b-2553-cca612afd067 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/one-20.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -boot c -drive file=/var/lib/one//20/images/disk.0,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/var/lib/one//20/images/disk.1,if=none,id=drive-ide0-1-1,format=raw -device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -device rtl8139,vlan=0,id=net0,mac=02:00:c0:a8:2a:0b,bus=pci.0,addr=0x3 -net tap,fd=60,vlan=0,name=hostnet0 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:20 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 as follows: -Fails: +Works: *- -S* - -name one-20 - -uuid 86deda31-a094-7f1b-2553-cca612afd067 + -name one-21 + -uuid 86deda31-a094-7f1b-2553-cca612afd068 - -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/one-20.monitor,server,nowait + -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/one-21.monitor,server,nowait *- -net tap,fd=60,vlan=0,name=hostnet0* - -vnc 0.0.0.0:20 + -vnc 0.0.0.0:21 So running nearly the same command by hand works just fine. I can only infer it has something to do with the networking, but why would that make it fail after grub loads? M. On 12-02-07 06:03 PM, Ruben S. Montero wrote: > Hi > > OpenNebula uses libvirt to interact with KVM. Check the deployment > file in /var/lib/one/<vm_id>. That is the file used by OpenNebula to > start the VM through virsh create.... > > You can take a look to that deployment file (and use it to debug the > process by hand) and see what it is misssing... I am not sure about > the version of libvirt shipped with Debian 6.0 but it may be a problem > with your libvirt installation... > > Cheers > > Ruben > > On Tue, Feb 7, 2012 at 11:55 PM, Michael Brown <mich...@netdirect.ca> wrote: >> OK, I found one error I was making. I had BOOT and ARCH as top-level >> parameters instead of having them under OS. >> >> Now I have: >> CPU=1 >> DISK=[ >> BUS=virtio, >> IMAGE=debian-root-disk ] >> DISK=[ >> SIZE=2048, >> TYPE=swap ] >> GRAPHICS=[ >> TYPE=vnc ] >> INPUT=[ >> BUS=usb, >> TYPE=tablet ] >> MEMORY=2048 >> NAME=debian_vm >> NIC=[ >> NETWORK=br0 ] >> OS=[ >> ARCH=x86_64 ] >> TEMPLATE_ID=3 >> VCPU=4 >> >> But now ON is firing up KVM without any -cpu parameter: >> >> /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 2048 -smp >> 4,sockets=4,cores=1,threads=1 -name one-20 -uuid >> 86deda31-a094-7f1b-2553-cca612afd067 -nodefaults -chardev >> socket,id=monitor,path=/var/lib/libvirt/qemu/one-20.monitor,server,nowait >> -mon >> chardev=monitor,mode=readline -rtc base=utc -boot c -drive >> file=/var/lib/one//20/images/disk.0,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 >> -device >> virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 >> -drive >> file=/var/lib/one//20/images/disk.1,if=none,id=drive-ide0-1-1,format=raw >> -device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 >> -device rtl8139,vlan=0,id=net0,mac=02:00:c0:a8:2a:0b,bus=pci.0,addr=0x3 >> -net tap,fd=60,vlan=0,name=hostnet0 -usb -device usb-tablet,id=input0 >> -vnc 0.0.0.0:20 -vga cirrus -device >> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 >> >> I'm running ON 3.2.1 on a freshly-installed debian 6.0 setup with >> similarly configured KVM hosts. >> >> M. >> >> On 12-02-07 05:38 PM, Michael Brown wrote: >>> How do I ask Open Nebula to use a 64-bit CPU? >>> >>> I've tried using: >>> ARCH=qemu64 >>> ARCH=x86_64 >>> ARCH=x64 >>> >>> in my machine template, but it always launches kvm with '-cpu qemu32'. >>> >>> Turns out this is what's been causing my booting troubles all along >>> (except for trying to convince open nebula to boot an image from CD - I >>> ended up just calling kvm by hand to do so). >>> >>> What are the correct values for the ARCH parameter? >>> >>> M. >>> >> >> -- >> Michael Brown | `One of the main causes of the fall of >> Systems Consultant | the Roman Empire was that, lacking zero, >> Net Direct Inc. | they had no way to indicate successful >> ☎: +1 519 883 1172 x5106 | termination of their C programs.' - Firth >> >> >> _______________________________________________ >> Users mailing list >> Users@lists.opennebula.org >> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org > > -- Michael Brown | `One of the main causes of the fall of Systems Consultant | the Roman Empire was that, lacking zero, Net Direct Inc. | they had no way to indicate successful ☎: +1 519 883 1172 x5106 | termination of their C programs.' - Firth
_______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org