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 <[email protected]>: > 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 > <[email protected]> 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 >> [email protected] >> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org > > > > > -- > Jaime Melis > Project Engineer > OpenNebula - The Open Source Toolkit for Cloud Computing > www.OpenNebula.org | [email protected] _______________________________________________ Users mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
