=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 =
--708812334-715765816-1397014905=:84118 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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--