On 2012-06-26 20:39, Ruben S. Montero wrote:
Hi,
The rationale behind this is the following:
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).
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.
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:
context, mkimage, and mkswap: These by default create files for the ISO
context CD-ROM or volatile disks
mv: that mv's VM directories across hosts
delete: to delete any temporal content created in the system datastore
NOTE: clone, mvds, and ln operations are datastore specific, and we are not
using the system ones.
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)
At least I saw that in some (commercial) cloud software, which really
use VirtualBox/qemu-utils to convert different image formats for
different virtualization platform.
Regards, Rolandas
P.S. Really I didn't test it too much, because I hate UI in browser made
with Flash Player.
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?
Thanks for your comments!
BTW, Hope this helps you to tune the LVM2 drivers... Thanks also for that
one :)
Cheers
Ruben
On Tue, Jun 26, 2012 at 12:43 PM, Rolandas Naujikas <
[email protected]> wrote:
Hi,
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.
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).
Regards, Rolandas Naujikas
______________________________**_________________
Users mailing list
[email protected]
http://lists.opennebula.org/**listinfo.cgi/users-opennebula.**org<http://lists.opennebula.org/listinfo.cgi/users-opennebula.org>
_______________________________________________
Users mailing list
[email protected]
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
