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
