<div>Hi,</div><div><br></div><div>Thank you very much, Fabian and Carlos, for your help. Things are much more clear now, I think.</div><div><br></div><div>*Sharing the image repository.</div><div>If I understood right, the aim with sharing the image repository between the front-end and the workers is to increase performance
 by reducing (or eliminating) the time needed to transfer an image from the repository to the worker that will run an instance of such image. I have, however, a question/remark here. To really reduce or eliminate the transfer time, the image should already reside on the worker node or close to it. If the image resides on a central server (case of NFS, if I am not wrong) or on an external shared distributed storage space (case of MooseFS, GlusterFS, Lustre, and the like), there is still a need to transfer the image to the worker, right? In the case of a distributed storage solution like MooseFs, etc., the worker could itself be part of the distributed storage space. In that case, the image may already reside on the worker, although not necessarily, right? But using the worker as both a storage server and client may actually compromise performance, for what I have read.</div>
<div>Am I totally wrong with my thoughts here? If not, do we really increase transfer performance by sharing the image repository using, e.g. NFS? Are there any performance numbers for the different cases that could be shared?</div>
<div><br></div><div>* Sharing the <VM_dir>.</div><div>Sharing the <VM_dir> between the front-end and the workers is not really needed, but it is more of a convenient solution, right?</div><div>Sharing the <VM_dir> between the workers  themselves might be needed for live migration. I say "might" because i have just seen that, for example, with KVM we may perform live migrations without a shared storage [2]. Has anyone experimented with this?</div>
<div><br></div><div>Regarding the documentation, Carlos, it looks fine. I would only suggest the possibility of documenting the 3rd case where the image repository is not shared but the <VM_dir> is shared.</div><div>
<br></div><div>Thanks!</div><div><br></div><div>Cheers,</div><div>Humberto</div><div><br></div><div>[1] <a href="http://opennebula.org/documentation:rel3.0:sfs#considerations_limitations">http://opennebula.org/documentation:rel3.0:sfs#considerations_limitations</a></div>
<div>[2] <a href="http://www.mail-archive.com/libvir-list@redhat.com/msg23674.html">http://www.mail-archive.com/libvir-list@redhat.com/msg23674.html</a></div><div><br></div><div><br></div><div>Date: Mon, 17 Oct 2011 16:30:13 +0200<br>
</div>
From: Fabian Wenk <<a href="mailto:fabian@wenks.ch">fabian@wenks.ch</a>><br>
To: <a href="mailto:users@lists.opennebula.org">users@lists.opennebula.org</a><br>
Subject: Re: [one-users] Storage subsystem: which one?<br>
Message-ID: <<a href="mailto:4E9C3BF5.1060900@wenks.ch">4E9C3BF5.1060900@wenks.ch</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Hello Carlos<br>
<br>
On 17.10.2011 11:34, Carlos Mart?n S?nchez wrote:<br>
> Thank you for your great contributions to the list!<br>
<br>
You're welcome.<br>
<br>
> I'd like to add that we tried to summarize the implications of the shared<br>
> [1] and non-shared [2] approaches in the documentation, let us know if there<br>
> are any big gaps we forgot about.<br>
<br>
Thank you for documenting it on the website. I think it is<br>
complete and mentions all important facts about the two storage<br>
possibilities.<br>
<br>
<br>
bye<br>
Fabian<br>
<br>
<br>