[one-users] Asking Open Nebula to use 64-bit CPU
Michael Brown
michael at netdirect.ca
Wed Feb 8 08:07:28 PST 2012
I've tried getting ttylinux to run and hit the exact same problem.
After the bootloader the machine hangs on 'Loading ttylinux'.
My ttylinux.one file:
NAME = ttylinux
CPU = 0.1
MEMORY = 64
DISK = [
source = "/var/lib/one/definitions/ttylinux/ttylinux.img",
target = "hda",
readonly = "no" ]
#NIC = [ NETWORK = "br0" ]
FEATURES=[ acpi="no" ]
GRAPHICS = [ type="vnc" ]
ip_public="192.168.0.254"
(I added the vnc graphics when I couldn't get to the machine. I also
commented out the network as a I suspected that as a problem, but no
change ;( )
So my best guess at this point is something to do with the monitor
interaction. Urgh.
M.
On 12-02-08 10:20 AM, Michael Brown wrote:
> 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 <michael at 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 at 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
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20120208/37117e0f/attachment-0002.htm>
More information about the Users
mailing list