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

[Jaime Melis]

Oops, sorry, the "if" line should be negated:

wrong:
-    if file -b $DST|grep -q "QCOW"; then

good:
+    if ! file -b $DST|grep -q "QCOW"; then

cheers,
Jaime

On Mon, Sep 10, 2012 at 3:57 PM, Jaime Melis <jmelis at opennebula.org> wrote:

> Hello Anton,
>
> I would do something like: http://pastie.org/4695814 (untested!!)
>
> cheers,
> Jaime
>
> On Mon, Sep 10, 2012 at 3:33 PM, Anton Gulenko <
> anton.gulenko at student.hpi.uni-potsdam.de> wrote:
>
>> 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
>>
>
>
>
> --
> Jaime Melis
> Project Engineer
> OpenNebula - The Open Source Toolkit for Cloud Computing
> www.OpenNebula.org | jmelis at 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/21e52a10/attachment-0002.htm>