[one-users] OpenNebula 3.0RC1 with LVM

[Valentin Bud]

Hello Community,

I have updates regarding the situation described in the last email. I think
I nailed the problem. Following is what I did to debug the problem further.

First I ran the following command by hand as root on the node the VM got
deployed. I want to specify that the VM was in failed state in the frontend
(onevm list output) and that the LV is created on the node I ran the command
on.

(node02)# /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 1024 -smp 1 -name one-20
-uuid 4ed49c9f-b05b-b961-7fb2-4d24e06d0146 -chardev
socket,id=monitor,path=/var/lib/libvirt/qemu/one-20.monitor,server,nowait
-monitor chardev:monitor -boot c -drive
file=/var/lib/one//20/images/disk.0,if=ide,index=0,boot=on,format=qcow2
-drive file=/var/lib/one//20/images/disk.1,if=ide,index=3,format=raw -net
nic,macaddr=02:00:c0:a8:96:0c,vlan=0,name=nic.0 -net
tap,fd=40,vlan=0,name=tap.0 -serial none -parallel none -usb -vnc
0.0.0.0:<http://0.0.0.0:19/>20 -vga
cirrus

Nothing happens. What is odd though is that qemu doesn't complain that
operation is not permitted. Trying to connect with VNC doesn't work.

I have found here:
http://www.howtoforge.com/forums/archive/index.php/t-30329.html that dumping
a qcow2 formatted image on top of LV doesn't work with KVM/qemu. So next
step was to copy the image from the image repository to the node and convert
in raw format using qemu-img. After that I have zeroed out the LV using "dd
if=/dev/zero of=/dev/vg0/lv-one-20-0 bs=1M" and then I have dumped the raw
image on top of the LV using dd again (dd if=/home/debug-lvm/image.raw
of=/dev/vg0/lv-one-20-0 bs=1M).

Next I tried to start the VM again using the command posted above. Same
behavior, no error reported but VNC access doesn't work although in both
cases a TCP socket gets created (0.0.0.0:5920). I have checked for that
using "netstat -an -A inet".

What next? I said I'd start the VM using virsh. So I have copied
"/var/lib/one/20/deployment.0" file to the node and ran "virsh -c
qemu:///system define /home/debug-lvm/deployment.0". The command executed
successfully. Next I ran "virsh -c qemu:///system start one-20". This time
/var/log/libvirt/qemu/one-20.log showed the same error as when deploying the
VM using OpenNebula:

(node02)# cat /var/log/libvirt/qemu/one-20.log

LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 1024 -smp 1
-name one-20 -uuid 2eae1939-7107-fa87-17f3-f1bf2cd9d5fa -chardev
socket,id=monitor,path=/var/lib/libvirt/qemu/one-20.monitor,server,nowait
-monitor chardev:monitor -boot c -drive
file=/var/lib/one//20/images/disk.0,if=ide,index=0,boot=on,format=raw -drive
file=/var/lib/one//20/images/disk.1,if=ide,index=3,format=raw -net
nic,macaddr=02:00:c0:a8:96:0b,vlan=0,name=nic.0 -net
tap,fd=40,vlan=0,name=tap.0 -serial none -parallel none -usb -vnc
0.0.0.0:20-vga cirrus
qemu: could not open disk image /var/lib/one//20/images/disk.0: Operation
not permitted

Googling around I have found the following link:
http://adminboard.com/mediawiki/index.php/Virtualization_With_KVM_On_A_Debian_Lenny_Server_3,
a small how to qemu with LV.

There's no need to read the above wiki page. The problem, if it's really a
problem, is that the /var/lib/one/20/deployment.0 file is wrong.
Next follows the deployment.0 xml:

<domain type='kvm'>
   <name>one-20</name>
   <memory>1048576</memory>
   <os>
        <type arch='x86_64'>hvm</type>
        <boot dev='hd'/>
   </os>
   <devices>
        <emulator>/usr/bin/kvm</emulator>
        <disk type='file' device='disk'>
                <source file='/var/lib/one//20/images/disk.0'/>
                <target dev='hda' bus='ide'/>
                <driver name='qemu' type='raw' cache='default'/>
        </disk>
        <interface type='bridge'>
                <source bridge='vlan150'/>
                <mac address='02:00:c0:a8:96:0b'/>
        </interface>
        <graphics type='vnc' listen='0.0.0.0' port='5920'/>
   </devices>
   <features>
        <acpi/>
   </features>
</domain>

The <disk> section is what matters here. I have changed the disk section as
follows (without ###, I have used that to point out the differences):

<disk type= ### 'block' ### device='disk'>
                <source ### dev ###='/var/lib/one//20/images/disk.0'/>
                <target dev='hda' bus='ide'/>
                <driver name='qemu' type='raw' cache='default'/>
        </disk>

After this change I have (re)defined the machine using "virsh -c
qemu:///system define /home/debug-lvm/deployment.0" and started using "virsh
-c qemu:///system start one-20". This time the VM started and I connected
through VNC to its console.

So let me recap for the sake of understanding. When ONE starts (onetemplate
instantiate ID_X) a VM, using LVM as transfer manager, several things
happen. First of all the /var/lib/one/VM_ID/images directory gets created on
the node the VM is to be deployed. Then the LV is created and the image
defined in the VM template in dumped. Next step is to create the swap space.
VM enters BOOT state and the /var/lib/one/VM_ID/deployment.0 file is
generated. Shouldn't the deployment file contain the "type=block" and
"source dev=" entries when using LVM Transfer Manager?

Is this a bug in ONE or normal behavior? Is this a bug in qemu/KVM, meaning
that it should work with "type=file" and "source file=" entries? Can I
change in ONE those parameters in some configuration files so that LV backed
guests deployment file contains the entries "type=block" and "source dev="?

And most important, how to proceed further?

Thank you and have a great day,
v
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20110928/1371efc7/attachment-0003.htm>