Details
-
Suggestion
-
Resolution: Won't Do
-
P3: Somewhat important
-
None
-
None
-
None
Description
By exporting VM images directly as iSCSI targets from the Compellent, we would gain many advantages:
- performance; currently we have a bunch of layers and network roundtrips before reaching the compellent (local SSD -> NFS CACHE -> NFS export on on1 -> Compellent).
- performance; QCOW2 is famous for being slower than RAW images because of the live block allocation and expansion.
- performance; Using a block device, instead of a Network File System
- performance; Using directly all the caching and speed that an enterprise EMC system offers
- live migration; having a target exported from the compellent, it's trivial to unmount it from one VM and mount it from another
Really, the only disadvantage of this plan is the difficulty of creating the images on the Compellent just by using the OpenNebula API. But I'm sure we can plan something out.
Documentation and relevant links
From libvirt storage management manual:
A second example is an iSCSI pool. A storage administrator provisions an iSCSI target to present a set of LUNs to the host running the VMs. When libvirt is configured to manage that iSCSI target as a pool, libvirt will ensure that the host logs into the iSCSI target and libvirt can then report the available LUNs as storage volumes. The volumes' paths can be queried and used in VM's XML definitions as in the NFS example. In this case, the LUNs are defined on the iSCSI server, and libvirt cannot create and delete volumes.
Opennebula seems to support the libvirt iSCSI datastore.