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

[Anton Gulenko]

Dear Jaime,

thank you for the quick reply.

Thanks to your explanations, we have managed to get the whole process
working as we wanted it to, without modifying the qcow2-scripts.

But to achieve that, we had to manually convert our image to the
qcow2-format before importing it into OpenNebula.
Is there a way to get OpenNebula to do that conversion task
automatically? E.g. it could detect, when a raw image is imported into
a
qcow2-datastore, and instead of simply copying the image, invoke the
"qemu-img convert" command.

Cheers,
Anton


2012/9/10 Jaime Melis <jmelis at opennebula.org>:
> 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