6:41 a.m.
--708812334-715765816-1397014905=:84118
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
=0A=0A>=0A> ----- Original Message -----=0A>> From:
"Paul Jansen"=0A>> To:=
"Itamar Heim" "Fabian
Deutsch"=0A>> Cc: "users"=0A>> Sent: Monday, April 7=
, 2014 3:25:19 PM=0A>> Subject: Re: [Users] node spin including qemu-kvm-rh=
ev?=0A>>=0A>> On 04/07/2014 11:46 AM, Fabian Deutsch
wrote:=0A>>=0A>>> Hey =
Paul,=0A>>>=0A>>> Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul
Janse=
n:=0A>>>> I'm going to try top posting this time to see if it ends up
looki=
ng a=0A>>>> bit better on the list.=0A>>>=0A>>> you could
try sending text-=
only emails :)=0A>>>=0A>>>> By the 'ovirt hypervisor
packages' I meant inst=
alling the OS first of=0A>>>> all and then making it into an ovirt
'node' b=
y installing the required=0A>>>> packages, rather than installing from a cl=
ean slate with the ovirt=0A>>>> node iso. Sorry if that was a bit unclear.=
=0A>>>=0A>>> Okay - thanks for the explanation.=0A>>> In
general I would di=
scourage from installing the ovirt-node package ona=0A>>> normal
host.=0A>>=
If you still want to try it be aware that the ovirt-node pkg might
mess=
=0A>>> with your system.=0A>>=0A>>=0A>> I'm
pretty sure we are on the same =
page here. I just checked the ovirt=0A>> 'quickstart' page and it calls
the=
various hypervisor nodes 'hosts'.=0A>> ie: Fedora host, EL, host, ovirt
no=
de host.=0A>> If the ovirt node included the qemu-kvm-rhev package - or an =
updated qemu-kvm=0A>> - it would mean that both ovirt node hosts and fedora=
hosts could both=0A>> support live storage migration. It would only be EL =
hosts that do not=0A>> support that feature at this stage. We could have a =
caveat in the=0A>> documentation for this perhaps.=0A>> Fabian, were you th=
ink thinking that if not all 'hosts' supported live=0A>> migration that
the=
cluster could disable that feature? Based on capabilities=0A>> that the ho=
sts would expose to the ovirt server? This would be another way=0A>> of avo=
iding the confusion.=0A>>=0A>> Thanks guys for the great work you are doing=
with ovirt.=0A>>=0A>=0A> Paul,=0A> this is something that vdsm needs to
re=
port to the engine, so the engine will=0A> know what is / isn't supported. =
It's a bigger request as today we're mostly=0A> based on cluster compatibil=
ity level.=0A>=0A> Additionally it is possible to mix .el hosts with nodes =
with old (non -rhev) nodes.=0A> Each of these cases will break live-storage=
migration.=0A>=0A> How do you suggest to mitigate it?=0A>=0AWell, when you=
choose to migrate a VM under Vmware's Vcenter you can choose to migrate ei=
ther the host or the datastore.=A0 For whichever one you choose there is a =
validation step to check the you are able to perform the migration (ie: cap=
abilities of the host).=A0 I can see in ovirt that we are showing the KVM v=
ersion on hosts.=A0 This matches the package version of the qemu-kvm packag=
e (or the qemu-kvm-rhev package if installed?). Could we have some sort of =
a cutoff point where we know which versions of KVM (ie: qemu-kvm or qemu-kv=
m-rhev) support the storage migration feature, and if a version is found th=
at doesn't match the required heuristics we just indicate the the validatio=
n process for the migration has failed?=0AWe could provide some small outpu=
t indicating why it has failed.=0ADoes this sound like a reasonable approac=
h?=0A=0AIs there any news on discussions with the CentOS people as to where=
a qemu-kvm-rhev package could be hosted (that we could then take advantage=
of)?=0AIf the hosting of an updated qemu-kvm (or qemu-kvm-rhev) is not sor=
ted out in the short term, I did some quick calculations last night and it =
seems based on previous EL point releases (this is hardly scientific I know=
) we are not likely to see an EL 6.6 for another few months.=A0 We may see =
an EL7.0 before that timeframe.=0AOvirt can obviously jump on new EL releas=
es to use as hosts in a new ovirt version but it seems this option is still=
some time away.=0A
--708812334-715765816-1397014905=:84118
Content-Type: text/html; charset=iso-8859-1
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">><br clear=3D"none"><div
style=3D"font-family: HelveticaNe=
ue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size:=
12pt;"><div style=3D"font-family: times new roman, new york, times,
serif;=
font-size: 12pt;"><div class=3D"y_msg_container"><div
class=3D"yqt98606749=
02" id=3D"yqtfd27637">><br
clear=3D"none">> ----- Original Message --=
---<br clear=3D"none">>> From: "Paul Jansen"<br
clear=3D"none">>&g=
t; To: "Itamar Heim" "Fabian Deutsch"<br
clear=3D"none">>> Cc: "users=
"<br clear=3D"none">>> Sent: Monday, April 7, 2014
3:25:19 PM<br clea=
r=3D"none">>> Subject: Re: [Users] node spin including
qemu-kvm-rhev?=
<br clear=3D"none">>><br
clear=3D"none">>> On 04/07/2014 11:46 =
AM, Fabian Deutsch wrote:<br clear=3D"none">>><br
clear=3D"none">>=
>> Hey Paul,<br
clear=3D"none">>>><br
clear=3D"none">>>> Am Montag, den =
07.04.2014, 01:28 -0700 schrieb Paul Jansen:<br
clear=3D"none">>>>=
> I'm going to try top posting this time to see if it ends up looking a<=
br clear=3D"none">>>>> bit better on the
list.<br clear=3D"none=
">>>><br
clear=3D"none">>>> you could try sending text-on=
ly emails :)<br clear=3D"none">>>><br
clear=3D"none">>>>&=
gt; By the 'ovirt hypervisor packages' I meant installing the OS first of<b=
r clear=3D"none">>>>> all and then making it into
an ovirt 'nod=
e' by installing the required<br
clear=3D"none">>>>> packages, =
rather than installing from a clean slate with the ovirt<br
clear=3D"none">=
>>>> node iso. Sorry if that was a bit unclear.<br
clear=3D"non=
e">>>><br
clear=3D"none">>>> Okay - thanks for the explan=
ation.<br clear=3D"none">>>> In general I would
discourage from in=
stalling the
ovirt-node package ona<br clear=3D"none">>>> normal
host.<br clea=
r=3D"none">>>> If you still want to try it be aware that
the ovirt=
-node pkg might mess<br clear=3D"none">>>> with your
system.<br cl=
ear=3D"none">>><br
clear=3D"none">>><br
clear=3D"none">>>=
I'm pretty sure we are on the same page here. I just checked the ovirt<br =
clear=3D"none">>> 'quickstart' page and it calls the
various hypervis=
or nodes 'hosts'.<br clear=3D"none">>> ie: Fedora
host, EL, host, ovi=
rt node host.<br clear=3D"none">>> If the ovirt node
included the qem=
u-kvm-rhev package - or an updated qemu-kvm<br
clear=3D"none">>> - it=
would mean that both ovirt node hosts and fedora hosts could both<br clear=
=3D"none">>> support live storage migration. It would only be
EL host=
s that do not<br clear=3D"none">>> support that feature at
this stage=
. We could have a caveat in the<br clear=3D"none">>>
documentation fo=
r this perhaps.<br
clear=3D"none">>> Fabian, were you think thinking that if not
all 'h=
osts' supported live<br clear=3D"none">>> migration that
the cluster =
could disable that feature? Based on capabilities<br
clear=3D"none">>>=
; that the hosts would expose to the ovirt server? This would be another wa=
y<br clear=3D"none">>> of avoiding the confusion.<br
clear=3D"none">&=
gt;><br clear=3D"none">>> Thanks guys for the great
work you are d=
oing with ovirt.<br clear=3D"none">>><br
clear=3D"none">><br clear=
=3D"none">> Paul,<br clear=3D"none">> this is
something that vdsm nee=
ds to report to the engine, so the engine will<br clear=3D"none">>
know =
what is / isn't supported. It's a bigger request as today we're mostly<br
c=
lear=3D"none">> based on cluster compatibility level.<br
clear=3D"none">=
><br clear=3D"none">> Additionally it is possible to mix .el
hosts wi=
th nodes with old (non -rhev) nodes.<br clear=3D"none">> Each of
these c=
ases will break
live-storage migration.<br clear=3D"none">><br
clear=3D"none">> How =
do you suggest to mitigate it?</div><br
clear=3D"none">><br clear=3D"non=
e">Well, when you choose to migrate a VM under Vmware's Vcenter you can cho=
ose to migrate either the host or the datastore. For whichever one yo=
u choose there is a validation step to check the you are able to perform th=
e migration (ie: capabilities of the host). I can see in ovirt that w=
e are showing the KVM version on hosts. This matches the package vers=
ion of the qemu-kvm package (or the qemu-kvm-rhev package if installed?). C=
ould we have some sort of a cutoff point where we know which versions of KV=
M (ie: qemu-kvm or qemu-kvm-rhev) support the storage migration feature, an=
d if a version is found that doesn't match the required heuristics we just =
indicate the the validation process for the migration has failed?<br>We cou=
ld provide some small output indicating why it has failed.<br>Does this
sound like a reasonable approach?<br><br>Is there any news on discussions =
with the CentOS people as to where a qemu-kvm-rhev package could be hosted =
(that we could then take advantage of)?<br>If the hosting of an updated qem=
u-kvm (or qemu-kvm-rhev) is not sorted out in the short term, I did some qu=
ick calculations last night and it seems based on previous EL point release=
s (this is hardly scientific I know) we are not likely to see an EL 6.6 for=
another few months. We may see an EL7.0 before that timeframe.<br>Ov=
irt can obviously jump on new EL releases to use as hosts in a new ovirt ve=
rsion but it seems this option is still some time away.<br></div> </div>
</=
div> </div></body></html>
--708812334-715765816-1397014905=:84118--