Can't attach disk after upgrade to 5.4


I’ve just realized that we can’t attach new disk anymore after upgrade from ONE 5.2 to 5.4.

It seems that the image is created in RAW format instead of qcow2. And then the disk.2.attach always mention a qcow2 format. So we are stuck. Any idea how to fix this problem ?

The datastore is set with driver and TM_MAD as qcow2.

As I said it was working with 5.2.

Log in libvirt for the concerned VM:
Image is not in qcow2 format

<disk type=‘file’ device=‘disk’>
<driver name=‘qemu’ type=‘qcow2’ />
<source file=’/var/lib/one//datastores/100/2844/disk.2’ >
<target dev=‘vdb’/>

Best regards,

This is the VM definition :
vm.xml (15.6 KB)

How can I debug this ?

What’s the process to create a new image? In Sunstone the type qcow2 is selected by default when I create a new empty datablock on a qcow2 datastore.

The process is via Sunstone. I will try on an other OpenNebula 5.4 that was also upgraded from 5.2 to see if the problem is reproducible.

When we click on attach disk in storage section of the vm, we choose qcow2 instead of raw and then validate. The vm goes in HOTPLUG state and a can see on the storage tab view that a raw image is created instead of the qcow2 we asked for.

I will also try to do this operation with the CLI.

Thank you for your help

is it possible to attache volatile disk with the CLI ?
It seems the onevm disk-attach asks for an image file.

I have bad news, this is 100% reproductible (at leat on 2 platforms for the moment, will have a third soon to be upgraded to 5.4). This happens with Ssh AND qcow2 type datastores.

Did you try to reproduce ?

Create 1 vm (we are using centos 7 kvm template from marketplace)
While the VM is running, go to storage tab, click on attach disk
Choose volatile, type 1 GB for the size, and just change Filesystem format to qcow2
Click on attach

The page will refresh to show the VM is now in HOTPLUG state, and you can see the new disk is added but in raw format.
After a few second, if you refresh, state is back to RUNNING, adding the disk has failed tho. Errors in log say image is not in qcow2 format.

We are using CentOS7

Should I open a bug report ?

I’ve tested adding a new volatile disk and you are right that the image is created as raw even if you specify qcow2. In my case it is correcty attached as as raw image though.

Anyway, it is indeed a bug. Can you open that bug report please? Thanks.

Thanks Javi. I’m opening a bug report right now.

This is bug #5336

do you know Javi where the command qemu-img create is done ? I would like to force it in qcow2 instead of raw as a workaround because we are blocked with this bug.

I’m slightly looking on it and looks to me like a Sunstone only problem. If you are only on KVM and don’t use vCenter, here is a workaround main.js.patch (1.9 KB) for /usr/lib/one/sunstone/public/dist/main.js. Simply, there are two FORMAT selection fields (for KVM and vCenter), and the latter (although hidden) always overrides the visible KVM configuration.

Please check if it’s better. Thanks.

I have applied the patch with no error. Is there anything else to do? I don’t see any difference ? Do I have to restart sunstone ?

ok I’ve just had the opportunity to restart sunstone and it works ! Thanks. At least disk are now in qcow2 format.