Hi,<div><br></div><div>The rationale behind this is the following:</div><div><br></div><div>The current datastore system allows you to setup a host that uses multiple datastores, each one with a different transfer driver. In this way, you can have FS datastores that is exported through a shared FS other FS datasores with SSH, and even one using an iSCSI server. With OpenNebula 3.4 you can use all of them at the same time in every single host (each host using tm_shared, tm_ssh, tm_iscsi depending on the image).</div>

<div><br></div><div>In previous version you are restricted to a single TM for each host. This usually means for example that you are restricted to a single NFS export or iSCSI server. IMHO this is a clear gain on the storage subsystem.</div>

<div><br></div><div>Now, the system datastore . It is used to create end-points in the target host, so the operations specific to the system datastore are just:</div><div><br></div><div>context, mkimage, and mkswap: These by default create files for the ISO context CD-ROM or volatile disks</div>

<div><br></div><div>mv: that mv's VM directories across hosts</div><div><br></div><div>delete: to delete any temporal content created in the system datastore</div><div><br></div><div>NOTE: clone, mvds, and ln operations are datastore specific, and we are not using the system ones.</div>

<div><br></div><div>So I think that there is no regression. Note that the use of multiple system datastores will basically affect cold migrations (mv), which are not possible across hypervisors, and in general very limited across hosts with different configurations (i.e migrating a VM with a LVM as disk that need to be converted to a file in other host) </div>

<div><br></div><div>However, I see situations where creating a context volume or a volatile volume in a LVM device or in a file depending on the host can be useful. So, probably a good trade-off would be setting up the system datastore per cluster instead of opennebula installation. What do you think?</div>

<div><br></div><div>Thanks for your comments! </div><div><br></div><div>BTW, Hope this helps you to tune the LVM2 drivers... Thanks also for that one :)</div><div><br></div><div>Cheers</div><div><br></div><div>Ruben</div>

<div><br></div><div><br></div><div><br><div class="gmail_quote">On Tue, Jun 26, 2012 at 12:43 PM, Rolandas Naujikas <span dir="ltr"><<a href="mailto:rolandas.naujikas@mif.vu.lt" target="_blank">rolandas.naujikas@mif.vu.lt</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
In opennebula 3.4.x there is not possible to setup different transfer manager for system datastore on different hosts. That was possible in opennebula 3.2.x and early. That looks like REGRESSION.<br>
<br>
That could be useful for opennebula with different visualization hosts types (KVM, Xen, VMware) or different system datastore storage configurations (filesystem + ssh/shared, filesystem + lvm2ssh/shared).<br>
<br>
Regards, Rolandas Naujikas<br>
______________________________<u></u>_________________<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/<u></u>listinfo.cgi/users-opennebula.<u></u>org</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Ruben S. Montero, PhD<br>Project co-Lead and Chief Architect<br>OpenNebula - The Open Source Solution for Data Center Virtualization<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:rsmontero@opennebula.org" target="_blank">rsmontero@opennebula.org</a> | @OpenNebula<br>


</div>