<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:12pt"><div>My vote is for storage load balancing/scheduler.</div><div>Vmware's Vcenter has the concept of a 'storage cluster'. It's essentially a logical storage device.</div><div>When you configure hosts/vms to use this device vcenter then works out which of the actual storage devices underneath this logical device is will send the storage requests to.</div><div>This works out as a basic form of load balacing by alternating where the storage for new vms are created.</div><div>This isn't particularly amazing, but what it does allow - with the highest end vcenter licensing anyway - is what Vmware calls 'storage distributed resource scheduling'.</div><div>Much like we already have the ability to have a scheduler that moves the execution of vms around on hosts based on load, this does the
same thing for the storage component of VM.</div><div>Imagine having two configured storage locations under a 'storage cluster' and then having the ability to put one of the storage locations into 'maintenance mode'. The storage scheduler would then 'live storage migrate' all the storage for vms over to the other storage location. This would then allow the first storage location to be taken down for maintenance.</div><div>This approach also allows storage to scale over time as more is added. The 'storage scheduler' can take inputs such as latency etc into account and manage the load across the 'storage cluster' to balance things out and make smart decisions so that the avaialble storage is utilized as best as it can be (ie: not overloading one storage location while the other location is mainly idle).<br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida
Grande,sans-serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span>I've done a bit a searching to see where Ovirt might be up to in this regard and what I've found seems to indicate that we are not anywhere near this capability just yet.</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span>An important prerequisite is having the hosts able to actually do a live storage migration. EL7 based hosts under ovirt 3.5 have this, as have Fedora 19 and 20 hosts.</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida
Grande,sans-serif; background-color: transparent; font-style: normal;"><span>If the decision is made to use qemu-kvm-rhev on EL6 hosts - as has been talked about recently - then the host requirement for supporting live storage migration will be met. This then allows the idea of a storage scheduler to be futher considered.</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span>I think this is an important step in reaching feature parity with Vmware's vcenter product, and removes a key reason ovirt/rhev can't be considered in some instances.</span></div><div style="color: rgb(0, 0, 0); font-size:
16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div></div></body></html>