---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=
<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
=
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--