I haven’t used Gluster in my OpenNebula setups so I can’t help you with that but as you mentioned that you want to use Gluster with OpenNebula 5.2, these recent conversations in the forum will provide you info about Gluster and OpenNebula 5:
I have took a look to that notes but there is no explanation about how to configure gluster as system dataster (it does for image datastore).
I will have to wait anybody in this forum with experience in glusterfs as system datastore.
Nevertheles, I’d like to ask if this configuration is suitable. In my farm, I’d like to have two system datastores:
1.- GlusterFS system datastore to run servers (sunstone, sql, and so on…) that can migrate from one host to other (persistent)
2.- Local FileSystem system datastore to run Windows 7 VDI (persistent or not persistent)
In this scenario, how can I instruct OpenNebula to, on vm creation, to use one system datastore or the other one?
I use OpenNebula with a GlusterFS datastore. Say you create your GlusterFS datastore, that one would be shared. The other one you would probably create as a SSH datastore, which means it will be copied to the local opennebula node when it’s created and then launched locally on that system.
When you create the “images” that your VMs will use as it’s hard drive, you can choose what datastore to use.
Example 1: I want to create a new server on my GlusterFS datastore.
Create a new image (the hard drive for the VM), when creating it you will choose the GlusterFS datastore.
This will create the file on that share. However, you need more than just a datastore to get this working. OpenNebula Front end needs to access the share using FUSE, so make sure it’s mounted to /var/lib/one/datastores/100 or whatever the ID of your Gluster datastore is.
Depending on if you can use GFAPI for native access with KVM, the VM will use the GlusterFS directly without using FUSE (which is slow) and then leave the FUSE mounted datastore directory for everything else.
If you don’t plan on using KVM with GFAPI you will need to simply create a shared datastore pointed to the FUSE Mounted gluster partition. If you are using CentOS/Redhat, GFAPI is already compiled and available for you to use.
To be honest, it’s hard to answer this without know your current level of experience with OpenNebula and what your setup is like. Maybe next week we can skype or something and I can answer your questions more fluidly and directly.
This means that if I’m using Non Persistent images all volatile data access (like windows pagefile) will be acceeded by mount point - FUSE access- (qcow2-shapshot or shared-copy). On the other hand, If I’m creating persistent images all data will be acceded by a link, and therefore again through the mountpoint (FUSE access).
I am not very familiar with gluster, but the image that you postt looks like not in sync with the current v5.2. I’ve take a quick look at the sources and the code in OpenNebula is in sort of “floating” state - there is support for libgfapi in the core(it can build XML configuration) but there are no drivers to manage gluster backed datastores.
IMO to use FUSE for as little as possible the best solution is to write a driver( DS_MAD and TM_MAD) to manage gluster backed image and system datastores. This way you could have libgfapi access to the perssitent, non-persistent and volatile disks on one side and the vm definition XML, the context iso and the checkpoint files on FUSE filesystem.
Here is the documentation regarding the storage drivers development http://docs.opennebula.org/5.2/integration/infrastructure_integration/sd.html#