Block LVM use existing LV incorrect size calculation


I’ve been trying for days now with different settings to use my image (an LV of 20GB) as the base for creating a new image in a block LVM datastore.

Each time I create it with path /dev/<vg>/<lv> it works but it calculates the size as 1MB. This makes that creating new instances get a LV with size of 1MB and thus the dd fails.

I can’t seem to change the size.

I’m trying to convert an existing setup from ganeti to opennebula but not being able to create images from an existing LV makes this impossible.

Can someone explain what to do, or where this is calculated? As I’m about to give up on opennebula.


Update: Opennebula 4.12, ubuntu 14.04 LTS

from the docs


As this datastore does is just a container for existing devices images does
not take any size from it. All devices registered will render size of 0 and
the overall devices datastore will show up with 1MB of available space

You may try to set the SIZE in the image when it is created for information


I did try that, SIZE and value 20G also tried with 20480M but it fails to register it.

When the image is made it’s still reported as 1MB

SIZE is in megabytes (without M), what are the log messages? what
datastore drivers are you using?

I’m using the BLOCK LVM datastore, with the virtio drivers for kvm. When creating the image and setting SIZE 20480 as custom attributes, it still creates the image with 1MB size.


==> /var/log/one/oned.log <==
Tue May 26 20:25:52 2015 [Z0][ReM][D]: Req:2528 UID:0 ImageAllocate invoked , "NAME=“ubuntu sejo lt…”, 100
Tue May 26 20:25:52 2015 [Z0][ImM][I]: Copying /dev/data/9104e29c-54d5-4b87-8585-2dd430696724.disk0 to repository for image 15
Tue May 26 20:25:52 2015 [Z0][ReM][D]: Req:2528 UID:0 ImageAllocate result SUCCESS, 15
Tue May 26 20:25:52 2015 [Z0][ReM][D]: Req:6160 UID:0 ImageInfo invoked , 15
Tue May 26 20:25:52 2015 [Z0][ReM][D]: Req:6160 UID:0 ImageInfo result SUCCESS, “15<U…”

==> /var/log/one/sunstone.log <==
Tue May 26 20:25:52 2015 [I]: - - [26/May/2015 20:25:52] “POST /image HTTP/1.1” 201 - 0.0774
Tue May 26 20:25:52 2015 [I]: - - [26/May/2015 20:25:52] “GET /support/request?timeout=false&csrftoken=d98cecfcf62ac74e39c567044d4a7517 HTTP/1.1” 500 - 0.0010

==> /var/log/one/oned.log <==
Tue May 26 20:25:53 2015 [Z0][ImM][I]: Image (15) copied and ready to use.
Tue May 26 20:25:53 2015 [Z0][InM][D]: Monitoring datastore SeJoITLVM (100)
Tue May 26 20:25:53 2015 [Z0][ImM][D]: Datastore SeJoITLVM (100) successfully monitored.
Tue May 26 20:25:55 2015 [Z0][ReM][D]: Req:6480 UID:0 ImageInfo invoked , 15
Tue May 26 20:25:55 2015 [Z0][ReM][D]: Req:6480 UID:0 ImageInfo result SUCCESS, “15<U…”

output onedatastore show:

oneadmin@duvel:~$ onedatastore show 100
ID : 100
USER : oneadmin
GROUP : oneadmin
DS_MAD : lvm
TM_MAD : lvm
BASE PATH : /var/lib/one//datastores/100

TOTAL: : 4.8T
FREE: : 4.7T
USED: : 41.9G
LIMIT: : -

OWNER : um-
GROUP : u–



The problem could be in the stat action we call on image registering. The driver is meant to register images into LVM and it’s using stat command to get the image size. This is the call sequence:

Maybe you can change the stat action from LVM datastore to one that retrieves the LV size. Do it in /var/lib/one/remotes/datastore/lvm/stat. Something like:

SIZE=$(lvdisplay $SRC | grep 'LV Size' | awk '{print $3}' | sed 's/\..*$//')

That gives me [ImageAllocate] Cannot parse SIZE in the browser when trying to create it.

Can you check the error in /var/log/one/oned.log. It may give more info.

Also check that the LV is visible in the frontend.

Still, as I said before, the drivers are meant to have files as origin. These steps are just hacks that can give you more problems than help unless you know what they’re doing.

Thu May 28 08:18:40 2015 [Z0][ReM][D]: Req:4976 UID:0 ImageAllocate invoked , "NAME=“ubuntu lts sej…”, 100
Thu May 28 08:18:40 2015 [Z0][ReM][E]: Req:4976 UID:0 ImageAllocate result FAILURE [ImageAllocate] Cannot parse SIZE

What do you mean disks directly to lvm are a hack? if so opennebula is not an option for me.


Doesn’t give much information unfortunately.

What I mean is a hack is the changes I’ve sent you. The driver was not designed to import LVs. Only images. This is the workflow it was designed for:

  • Import raw file image
  • The driver gets the size of the file and creates a LV of that size
  • The driver dd’s the file into the LV
  • Now the LV can be used for VMs or cloned in case it is not persistent

You are trying to import a LV, that’s the problem.

There are different solutions to use your LVs:

  • Create a file image with dd and import that file

  • Modify the drivers so it can import LVs directly. The changes I’ve sent you are a good start but I have not tested them

  • If the images are persistent (used by only one VM) you can use the devices datastore

  • Create an empty datablock image in the datastore with the same size, get its LV name (use oneimage show and search for SOURCE) and rename the LV you want to import to it