Question about Raw Device Mapping (RDM) Datastores

Hi all

We want to use RDM datastores in our current production setup. We have several disks from our hypervisors and the idea is to use a RDM datastore for some specific internal VMs managed by the oneadmin user.

The question is about the scheduler, when we create a new image within a RDM datastore we should specify the PATH like:


but this path should be available from any host in our setup? or is the scheduler able to detect which disks are available from each hypervisor? should we create a specific cluster for these kind of datastores?

Thanks in advance!


I have another question also related with the DRM datastores.
It would be possible to specify the real disk path instead of the operating system device name? like:


This is a bit safer because the disk name could change, but the disk path prevails.
I have tried that but unfortunately the symbolic link from the hypervisor does match with the real disk path when the VM is deployed:

1099511629440 1 lrwxrwxrwx 1 oneadmin oneadmin 20 Jan 30 10:33 disk.1 -> 18:00.0-scsi-0:2:5:0

Instead of:

1099511629440 1 lrwxrwxrwx 1 oneadmin oneadmin 20 Jan 30 10:33 disk.1 -> /dev/disk/by-path/18:00.0-scsi-0:2:5:0

Any idea how to fix that? probably the full path is not parsed correctly and it expects a regular /dev/sdx…

Cheers and thanks!

The scheduler wont check if the device exists or not in the destination host/datastore. It will just check if the destination match or not the sched requirements. As you said you can create a new cluster containing the hosts and datastores with these devices for managing this.

Regarding on how to specify the block device OpenNebula just pass the value to libvirt, here is what libvirt documentation says (

The dev attribute specifies the fully-qualified path to the host device to serve as the disk. Since 0.0.3

hi @cgonzalez

Thanks a lot for the reply. I think we found the issue with the path, the problem was the colons, we have to escape the colons to set correctly the path for libvirt. Somehow the destination link was truncated.

Cheers and thanks!

Nice, thanks for sharing the info!