Bug #465

opennebula_2.0.1-1 defaults to incorrect a DISK/DRIVER attribute of the VM

Added by Marlon Nerling over 10 years ago. Updated over 10 years ago.

Status:ClosedStart date:01/11/2011
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Resolution:worksforme Pull request:
Affected Versions:


If not DISK [ DRIVER = qcow2 ] attribute is set on the VM template opennebula (only version 2.0.1-1) defaults to raw, even though the images are qcow files.
This behavior was not seen under opennebula_2.0.1.
However, I don't ever see the point of it, since it been mandatory under the new versions of libvirt, it can be workarounded on the host:
(SNIP /etc/libvirt/qemu.conf:)
  1. If allow_disk_format_probing is enabled, libvirt will probe disk
  2. images to attempt to identify their format, when not otherwise
  3. specified in the XML. This is disabled by default. #
  4. WARNING: Enabling probing is a security hole in almost all
  5. deployments. It is strongly recommended that users update their
  6. guest XML <disk> elements to include <driver type='XXXX'/>
  7. elements instead of enabling this option.

Well the point beeing that opennebula don't ever tries to identify the file, but defaults to the same as libvirt would naturly do.
I workarounded it on the VMs gererated by 2.0.1 by editing vm_pool.template manually and added DRIVE = qcow2 on the templates of the new generated VMs.

Associated revisions

Revision 50e74647
Added by Vlastimil Holer almost 4 years ago

B #5172: Detect remote image size (#465)

Revision f417cfc3
Added by Vlastimil Holer almost 4 years ago

B #5172: Detect remote image size (#465)

(cherry picked from commit 50e74647693e4c471ec131caf163295f031d97fc)


#1 Updated by Ruben S. Montero over 10 years ago

  • Status changed from New to Closed
  • Resolution set to worksforme
The default driver for a disk can be set in two ways:
  • Driver-wise for all the images at etc/vmm_ssh/vmm_ssh_kvm.conf with
  • Image-wise in the Image repository by setting the DRIVER attribute for the image

#2 Updated by Marlon Nerling over 10 years ago

The Driver-wise workaround (sic) stills buggy if you use 2 or more disks of different type.
The main problem is not workarounding for new VMs, but for the VMS generated by early versions.
This would be the case for migration from opennebula_2.0.1 to 2.0.1-1. The VMS would boot, but the bootloader would complain about 'not bootable device found'

Also available in: Atom PDF