<span></span></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; fon= t-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-s= erif; 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=3D"color: rgb(0, 0, 0); font-size: 16px; f= ont-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans= -serif; background-color: transparent; font-style: normal;"><span>An import= ant prerequisite is having the hosts able to actually do a live storage mig= ration.  EL7 based hosts under ovirt 3.5 have this, as have Fedora 19 = and 20 hosts.</span></div><div style=3D"color: rgb(0, 0, 0); font-size: 16p= x; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><sp= an>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 stora= ge migration will be met.  This then allows the idea of a storage sche= duler to be futher considered.</span></div><div style=3D"color: rgb(0, 0, 0= ); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Ari= al,Lucida Grande,sans-serif; background-color: transparent; font-style: nor= mal;"><br><span></span></div><div style=3D"color: rgb(0, 0, 0); font-size: = 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gran= de,sans-serif; background-color: transparent; font-style: normal;"><span>I =

---1212189890-1261065207-1410659964=:78009 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My vote is for storage load balancing/scheduler.=0AVmware's Vcenter has the= concept of a 'storage cluster'. It's essentially a logical storage devic= e.=0AWhen 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.=0AThis works out as a basic form of load bal= acing by alternating where the storage for new vms are created.=0AThis isn'= t particularly amazing, but what it does allow - with the highest end vcent= er licensing anyway - is what Vmware calls 'storage distributed resource sc= heduling'.=0AMuch 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 sa= me thing for the storage component of VM.=0AImagine having two configured s= torage locations under a 'storage cluster' and then having the ability to p= ut one of the storage locations into 'maintenance mode'. The storage sched= uler would then 'live storage migrate' all the storage for vms over to the = other storage location. This would then allow the first storage location t= o be taken down for maintenance.=0AThis approach also allows storage to sca= le over time as more is added. The 'storage scheduler' can take inputs suc= h as latency etc into account and manage the load across the 'storage clust= er' to balance things out and make smart decisions so that the avaialble st= orage is utilized as best as it can be (ie: not overloading one storage loc= ation while the other location is mainly idle).=0A=0A=0AI've done a bit a s= earching to see where Ovirt might be up to in this regard and what I've fou= nd seems to indicate that we are not anywhere near this capability just yet= .=0AAn important prerequisite is having the hosts able to actually do a liv= e storage migration. EL7 based hosts under ovirt 3.5 have this, as have Fe= dora 19 and 20 hosts.=0AIf 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 o= f a storage scheduler to be futher considered.=0A=0AI think this is an impo= rtant step in reaching feature parity with Vmware's vcenter product, and re= moves a key reason ovirt/rhev can't be considered in some instances.=0A ---1212189890-1261065207-1410659964=:78009 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;fo= nt-size:12pt"><div>My vote is for storage load balancing/scheduler.</div><d= iv>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 d= evices 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 w= here 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 a= nyway - is what Vmware calls 'storage distributed resource scheduling'.</di= v><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 c= onfigured storage locations under a 'storage cluster' and then having the a= bility to put one of the storage locations into 'maintenance mode'.  T= he storage scheduler would then 'live storage migrate' all the storage for = vms over to the other storage location.  This would then allow the fir= st storage location to be taken down for maintenance.</div><div>This approa= ch also allows storage to scale over time as more is added.  The 'stor= age 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 (i= e: not overloading one storage location while the other location is mainly = idle).<br></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-fa= mily: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><br= think this is an important step in reaching feature parity with Vmware's vc= enter product, and removes a key reason ovirt/rhev can't be considered in s= ome instances.</span></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gra= nde,sans-serif; background-color: transparent; font-style: normal;"><span><= br></span></div></div></body></html> ---1212189890-1261065207-1410659964=:78009--