[one-users] [OpenNebula 3.6] Problem with persistent images using FileSystem DM & qcow2 TM

Jaime Melis jmelis at opennebula.org
Mon Sep 10 04:10:15 PDT 2012


Hello Anton,

The qcow2 drivers assume, like with shared, that the datastore is exported
to the host using a distrubuted file system like NFS.

Considering we're talking about persistent images, why bother doing
"qemu-img create" and then "qemu-img commit" to save the changes, if you
can just do "ln -s" and use the image in place? It will be deployed faster,
saved faster and more importantly, it will run faster since it won't have a
backing-store.

Since the datastore is exported to the host, the MVDS script is doing
"qemu-img convert" only when the image has been marked as SAVE_AS,
otherwise it silently exits. For the SAVE_AS case, we want a new,
indepedent image, so we need to use "qemu-img convert".

Another thing we wanted to avoid was to have images depending on other
images. Consider the case where image A is the backing-store of image B. If
you remove image A, image B will stop working.

cheers,
Jaime

On Sun, Sep 9, 2012 at 10:13 PM, Anton Gulenko <
anton.gulenko at student.hpi.uni-potsdam.de> wrote:

> Dear OpenNebula community,
>
> We are using OpenNebula 3.6 to set up a private cloud for a university
> research project.
> We use the FileSystem Datastore Manager and the qcow2 Transfer Manager.
> For the preparation of VMs, it is important for us to use persistent
> images.
> Using non-persistent images posed no problems at all. However,
> persistent deploying a VM with a persistent image would not work.
>
> Inspecting the scripts in the $ONE_LOCATION/var/remotes/tm/qcow2
> directory, we noticed, that persistent images are handled the same way
> as by the Shared Transfer Manager: by creating a filesystem-link from
> the image-datastore into the System-datastore.
> Is that really the intention of the ln-script in the qcow2 Transfer
> Manager? We had expected a 'qemu-img create' command.
> We also noticed, that the mvds-script, that is responsible for
> committing the changes of the VM-disk back into the datastore, is
> using the 'qemu-img convert' command.
> We expected it to use the 'qemu-img commit' command, so that the
> changes are pushed back into the backing image-file.
>
> Did we misunderstand the purpose of the mentioned scripts?
>
> By making the following changes to the scripts, we got the qcow2
> Transfer Manager running just the way we expected it to:
> - Delete the original ln-script and replace it with a copy of the
> clone-script
> - Replace the 'qemu-img convert' command in the mvds-script with an
> appropriate 'qemu-img commit' command
>
> Best regards,
> Anton and Frank
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>



-- 
Jaime Melis
Project Engineer
OpenNebula - The Open Source Toolkit for Cloud Computing
www.OpenNebula.org | jmelis at opennebula.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20120910/8ef4ccd9/attachment-0002.htm>


More information about the Users mailing list