[one-users] Do not use qcow image format with latest ONE

[Carsten.Friedrich at csiro.au]

I have (had) this problem with 0.7.5 (the latest OpenNebula git repository source code fixes it):

virsh # version
Compiled against library: libvir 0.7.5
Using library: libvir 0.7.5
Using API: QEMU 0.7.5
Running hypervisor: QEMU 0.12.3



From: users-bounces at lists.opennebula.org [mailto:users-bounces at lists.opennebula.org] On Behalf Of Rangababu Chakravarthula
Sent: Sunday, 24 October 2010 2:38
To: Rich Wellner
Cc: users at lists.opennebula.org
Subject: Re: [one-users] Do not use qcow image format with latest ONE

Rich
It is libvirt that adds that flag. I am not exactly sure, starting which version it started to do this. It wasn't doing this in libvirt 0.75. I think starting 0.8 it has started to do this.

Unless specified otherwise, by default libvirt marks driver type as "raw" which gets passed as format flag to kvm. Because of this qcow virtual size is not exposed to the guest.

OpenNebula, when it creates the libvirt deployment file, doesn't add any flag. We had to change LibvirtDriver.cc and specifically add type=qcow2 attribute to the driver xml flag, and recompile one.

Here is a post regarding the same.
http://lists.opennebula.org/htdig.cgi/users-opennebula.org/2010-September/002894.html

Ranga
On Fri, Oct 22, 2010 at 1:47 PM, Rich Wellner <rkw at objenv.com<mailto:rkw at objenv.com>> wrote:
Using RC1 I just ran across a bug that was reported in August.  I've included the text of the email below.  I just wanted to give a heads up that it's still there.  The weird part is that I have no idea how it got triggered.  I was able to run images yesterday until about noon.  Started playing around with some other images and from there on out, nothing would start because one kept requesting the raw flag, including images that had previously been working.


--------------------- PREVIOUS REPORT BELOW -----------------------



Hello,



That is really weird as we have not added a format parameter to the

deployment file we use to create a VM. Could you please send us

$ONE_LOCATION/var/<vm_id>/deployment.0 of one of the VM's that fail?



Thank you



On Tue, Aug 24, 2010 at 2:17 PM, Martin Kopta <martin at kopta.eu<http://lists.opennebula.org/listinfo.cgi/users-opennebula.org>> wrote:

> Hello,

>

>  I am playing with latest checkout of ONE (branch one-2.0) and I found out

> that my old images aren't working anymore (getting 'no bootable device' on

> display). They were of type 'qcow2' which was no problem before (circa 3 weeks

> ago). Anyway, I noticed that 'kvm' process does have 'format=raw' [1], so I

> converted my images [2] to raw and it seems to be working now.

>

> Hope this helps someone.

>

> Best regards,

>  dum8d0g

>

> [1] /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name one-15 -uuid cea35f06-61cc-c87c-75bc-03e8c3cb637d -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/one-15.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -no-acpi -boot c -drive file=/home/one/vms/15/images/disk.0,if=none,id=drive-ide0-0-0,boot=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/home/one/vms/15/images/disk.1,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device rtl8139,vlan=0,id=net0,mac=02:00:c0:a8:7a:05,bus=pci.0,addr=0x3 -net tap,fd=41,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -vnc 0.0.0.0:0<http://0.0.0.0:0> -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4

> [2] qemu-img convert image.qcow2 -O raw image.raw

>


_______________________________________________
Users mailing list
Users at lists.opennebula.org<mailto:Users at lists.opennebula.org>
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20101101/6d56c8b4/attachment-0003.htm>