Hello Anton,<div><br></div><div>The qcow2 drivers assume, like with shared, that the datastore is exported to the host using a distrubuted file system like NFS.</div><div><br></div><div>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.</div>


<div><br></div><div>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".</div>


<div><br>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.</div><div><br></div>


<div>cheers,<br>Jaime </div><div><br></div><div>On Sun, Sep 9, 2012 at 10:13 PM, Anton Gulenko <span dir="ltr"><<a href="mailto:anton.gulenko@student.hpi.uni-potsdam.de" target="_blank">anton.gulenko@student.hpi.uni-potsdam.de</a>></span> wrote:</div>


<div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear OpenNebula community,<br>
<br>
We are using OpenNebula 3.6 to set up a private cloud for a university<br>
research project.<br>
We use the FileSystem Datastore Manager and the qcow2 Transfer Manager.<br>
For the preparation of VMs, it is important for us to use persistent images.<br>
Using non-persistent images posed no problems at all. However,<br>
persistent deploying a VM with a persistent image would not work.<br>
<br>
Inspecting the scripts in the $ONE_LOCATION/var/remotes/tm/qcow2<br>
directory, we noticed, that persistent images are handled the same way<br>
as by the Shared Transfer Manager: by creating a filesystem-link from<br>
the image-datastore into the System-datastore.<br>
Is that really the intention of the ln-script in the qcow2 Transfer<br>
Manager? We had expected a 'qemu-img create' command.<br>
We also noticed, that the mvds-script, that is responsible for<br>
committing the changes of the VM-disk back into the datastore, is<br>
using the 'qemu-img convert' command.<br>
We expected it to use the 'qemu-img commit' command, so that the<br>
changes are pushed back into the backing image-file.<br>
<br>
Did we misunderstand the purpose of the mentioned scripts?<br>
<br>
By making the following changes to the scripts, we got the qcow2<br>
Transfer Manager running just the way we expected it to:<br>
- Delete the original ln-script and replace it with a copy of the clone-script<br>
- Replace the 'qemu-img convert' command in the mvds-script with an<br>
appropriate 'qemu-img commit' command<br>
<br>
Best regards,<br>
Anton and Frank<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
</blockquote></div><br></div><br clear="all"><div><br></div>-- <br>Jaime Melis<br>Project Engineer<br>OpenNebula - The Open Source Toolkit for Cloud Computing<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:jmelis@opennebula.org" target="_blank">jmelis@opennebula.org</a><br>