[Users] node spin including qemu-kvm-rhev?
---847950152-1364082376-1396427909=:14395 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I understand that there are ongoing discussions with the Centos people rega= rding a suitable home for recompiled qemu-kvm packages.=0AGiven that the ov= irt node is our own spin, is there any reason why that couldn't include the= recompiled qemu-kvm packages that will then allow us to use live snapshots= and do live migrations?=A0 Itamar recently mentioned that we already build= these via a jenkins task.=0A=0ANodes built on top of a Centos install will= still be an issue but I think its reasonable that the ovirt-node iso could= include these custom packages.=0AThis way we don't have to potentially wai= t until 3.4.1 or 3.5 to get the live snapshot/migration features.=A0 The ca= veat would be that these features would only be supported if the nodes were= all ovirt node iso based.=0A=0AWhat are people's thoughts?=0A ---847950152-1364082376-1396427909=:14395 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"><div>I understand that there are ongoing discussions with the= Centos people regarding a suitable home for recompiled qemu-kvm packages.<= /div><div><span>Given that the ovirt node is our own spin, is there any rea= son why that couldn't include the recompiled qemu-kvm packages that will th= en allow us to use live snapshots and do live migrations? Itamar rece= ntly mentioned that we already build these via a jenkins task.</span></div>= <div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaN= eue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif; background-col= or: transparent; font-style: normal;"><span><br></span></div><div style=3D"= 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>Nodes built on top of a Centos ins= tall will still be an issue but I think its reasonable that the ovirt-node = iso could include these custom packages.</span></div><div style=3D"color: r= gb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Hel= vetica,Arial,Lucida Grande,Sans-Serif; background-color: transparent; font-= style: normal;"><span>This way we don't have to potentially wait until 3.4.= 1 or 3.5 to get the live snapshot/migration features. The caveat woul= d be that these features would only be supported if the nodes were all ovir= t node iso based.</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;"><br><sp= an></span></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;"><sp= an>What are people's thoughts?</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;"><span><br></span></div></div></body></html> ---847950152-1364082376-1396427909=:14395--
----- Original Message -----
From: "Paul Jansen" <vlaero@yahoo.com.au> To: "users" <users@ovirt.org> Sent: Wednesday, April 2, 2014 11:38:29 AM Subject: [Users] node spin including qemu-kvm-rhev?
I understand that there are ongoing discussions with the Centos people regarding a suitable home for recompiled qemu-kvm packages. Given that the ovirt node is our own spin, is there any reason why that couldn't include the recompiled qemu-kvm packages that will then allow us to use live snapshots and do live migrations? Itamar recently mentioned that we already build these via a jenkins task.
Nodes built on top of a Centos install will still be an issue but I think its reasonable that the ovirt-node iso could include these custom packages. This way we don't have to potentially wait until 3.4.1 or 3.5 to get the live snapshot/migration features. The caveat would be that these features would only be supported if the nodes were all ovirt node iso based.
What are people's thoughts?
Sounds reasonable as long as you understand mix and match will become an issue. The questions is how do we differentiate between the nodes to make sure no one mixes them by mistake?
=0A> What are people's thoughts?=0A> =0A> =0A=0ASounds reasonable as long= as you understand mix and match will become an issue.=0AThe questions is h= ow do we differentiate between the nodes to make sure no one=0Amixes them b= y mistake?=0A=0A=0AMy mail client might mangle the bottom-posting here, so = we'll see how it goes.=0AI saw a post from Fabian that he had re-enabled je= nkins builds of the node image based on Fedora 19/20 (but not yet including=
---1212189890-1090543080-1396836923=:91015 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0A=0A----- Original Message -----=0A> From: "Paul Jansen" <vla= ero@yahoo.com.au>=0A> To: "users" <users@ovirt.org>=0A> Sent: Wednesday, Ap= ril 2, 2014 11:38:29 AM=0A> Subject: [Users] node spin including qemu-kvm-r= hev?=0A> =0A> I understand that there are ongoing discussions with the Cent= os people=0A> regarding a suitable home for recompiled qemu-kvm packages.= =0A> Given that the ovirt node is our own spin, is there any reason why tha= t=0A> couldn't include the recompiled qemu-kvm packages that will then allo= w us to=0A> use live snapshots and do live migrations? Itamar recently ment= ioned that we=0A> already build these via a jenkins task.=0A> =0A> Nodes bu= ilt on top of a Centos install will still be an issue but I think its=0A> r= easonable that the ovirt-node iso could include these custom packages.=0A> = This way we don't have to potentially wait until 3.4.1 or 3.5 to get the li= ve=0A> snapshot/migration features. The caveat would be that these features= would=0A> only be supported if the nodes were all ovirt node iso based.=0A= the VDSM plugin).=A0 Presumably the main goal of this is to ensure that th= ings in node land are OK for an upcoming spin based on EL7?=0AIf ovirt does= go back to having Fedora and EL based node images in the short term it wou= ld mean that live migration will work on the Fedora images.=0AIf it was als= o decided to allow the EL based node image to include the recompiled qemu-k= vm-rhev package the Ovirt release notes could then say that when using an o= virt node image live migration is supported, as is when a fedora install ha= s the ovirt hypervisor packages installed.=0AIt would only be that an EL ba= sed system - built up to then also include the ovirt hypervisor packages - = that live migration would not be supported - at this stage.=0AThis can chan= ge when the details are further worked out with the Centos people about how= the updated qemu-kvm packages will be hosted and made available.=0AIn the = meantime, people that want to set things up so that live migration is there= can do so.=0A=0AOnce live migration is in place I think it would be intere= sting to try and find out from people interested (or already testing ovirt)= that have VMware backgrounds/experience what they think is the the largest= outstanding issue feature wise when comparing ovirt to Vcenter.=A0 What wo= uld stop them from migrating from vcenter to ovirt?=0A ---1212189890-1090543080-1396836923=:91015 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"><div style=3D"font-family: HelveticaNeue, Helvetica Neue, Hel= vetica, Arial, Lucida Grande, Sans-Serif; font-size: 12pt;"><div style=3D"f= ont-family: times new roman, new york, times, serif; font-size: 12pt;"><br>= <div class=3D"y_msg_container"><br><br clear=3D"none"><div class=3D"yqt0237= 477400" id=3D"yqtfd00318"><br clear=3D"none">----- Original Message -----<b= r clear=3D"none">> From: "Paul Jansen" <<a shape=3D"rect" ymailto=3D"= mailto:vlaero@yahoo.com.au" href=3D"mailto:vlaero@yahoo.com.au">vlaero@yaho= o.com.au</a>><br clear=3D"none">> To: "users" <<a shape=3D"rect" y= mailto=3D"mailto:users@ovirt.org" href=3D"mailto:users@ovirt.org">users@ovi= rt.org</a>><br clear=3D"none">> Sent: Wednesday, April 2, 2014 11:38:= 29 AM<br clear=3D"none">> Subject: [Users] node spin including qemu-kvm-= rhev?<br clear=3D"none">> <br clear=3D"none">> I understand that there are ongoing discussions wi= th the Centos people<br clear=3D"none">> regarding a suitable home for r= ecompiled qemu-kvm packages.<br clear=3D"none">> Given that the ovirt no= de is our own spin, is there any reason why that<br clear=3D"none">> cou= ldn't include the recompiled qemu-kvm packages that will then allow us to<b= r clear=3D"none">> use live snapshots and do live migrations? Itamar rec= ently mentioned that we<br clear=3D"none">> already build these via a je= nkins task.<br clear=3D"none">> <br clear=3D"none">> Nodes built on t= op of a Centos install will still be an issue but I think its<br clear=3D"n= one">> reasonable that the ovirt-node iso could include these custom pac= kages.<br clear=3D"none">> This way we don't have to potentially wait un= til 3.4.1 or 3.5 to get the live<br clear=3D"none">> snapshot/migration = features. The caveat would be that these features would<br clear=3D"none">&= gt; only be supported if the nodes were all ovirt node iso based.<br clear=3D"none">&g= t; <br clear=3D"none">> What are people's thoughts?</div><br clear=3D"no= ne">> <br clear=3D"none">> <br clear=3D"none"><br clear=3D"none">Soun= ds reasonable as long as you understand mix and match will become an issue.= <br clear=3D"none">The questions is how do we differentiate between the nod= es to make sure no one<br clear=3D"none">mixes them by mistake?<div class= =3D"yqt0237477400" id=3D"yqtfd35489"><br clear=3D"none"></div><br><br>My ma= il client might mangle the bottom-posting here, so we'll see how it goes.<b= r>I saw a post from Fabian that he had re-enabled jenkins builds of the nod= e image based on Fedora 19/20 (but not yet including the VDSM plugin). = ; Presumably the main goal of this is to ensure that things in node land ar= e OK for an upcoming spin based on EL7?<br>If ovirt does go back to having = Fedora and EL based node images in the short term it would mean that live m= igration will work on the Fedora images.<br>If it was also decided to allow the EL based= node image to include the recompiled qemu-kvm-rhev package the Ovirt relea= se notes could then say that when using an ovirt node image live migration = is supported, as is when a fedora install has the ovirt hypervisor packages= installed.<br>It would only be that an EL based system - built up to then = also include the ovirt hypervisor packages - that live migration would not = be supported - at this stage.<br>This can change when the details are furth= er worked out with the Centos people about how the updated qemu-kvm package= s will be hosted and made available.<br>In the meantime, people that want t= o set things up so that live migration is there can do so.<br><br>Once live= migration is in place I think it would be interesting to try and find out = from people interested (or already testing ovirt) that have VMware backgrou= nds/experience what they think is the the largest outstanding issue feature wise when comparing ovirt to Vcenter. What would stop them f= rom migrating from vcenter to ovirt?<br></div> </div> </div> </div></body>= </html> ---1212189890-1090543080-1396836923=:91015--
Am Sonntag, den 06.04.2014, 19:15 -0700 schrieb Paul Jansen:
My mail client might mangle the bottom-posting here, so we'll see how it goes. I saw a post from Fabian that he had re-enabled jenkins builds of the node image based on Fedora 19/20 (but not yet including the VDSM plugin). Presumably the main goal of this is to ensure that things in node land are OK for an upcoming spin based on EL7?
EL7 is one point, but there were users also asking for Fedora based Nodes and we use Fedora for development, to have stable Nodes (at some point later) based on CentOS.
If ovirt does go back to having Fedora and EL based node images in the short term it would mean that live migration will work on the Fedora images.
The Fedora based images are at least for now available from Jenkins.
If it was also decided to allow the EL based node image to include the recompiled qemu-kvm-rhev package the Ovirt release notes could then say that when using an ovirt node image live migration is supported, as is when a fedora install has the ovirt hypervisor packages installed.
What is this ovirt hypervisor package you mention? - fabian
It would only be that an EL based system - built up to then also include the ovirt hypervisor packages - that live migration would not be supported - at this stage. This can change when the details are further worked out with the Centos people about how the updated qemu-kvm packages will be hosted and made available. In the meantime, people that want to set things up so that live migration is there can do so.
Once live migration is in place I think it would be interesting to try and find out from people interested (or already testing ovirt) that have VMware backgrounds/experience what they think is the the largest outstanding issue feature wise when comparing ovirt to Vcenter. What would stop them from migrating from vcenter to ovirt?
--708812334-390794442-1396859291=:39119 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm going to try top posting this time to see if it ends up looking a bit b= etter on the list.=0A=0ABy the 'ovirt hypervisor packages' I meant installi= ng the OS first of all and then making it into an ovirt 'node' by installin= g the required packages, rather than installing from a clean slate with the= ovirt node iso.=A0 Sorry if that was a bit unclear.=0A=0A=0A=0A___________= _____________________=0A From: Fabian Deutsch =0ATo: Paul Jansen =0ACc: Dor= on Fediuck; users=0ASent: Monday, 7 April 2014 5:20 PM=0ASubject: Re: [User= s] node spin including qemu-kvm-rhev?=0A =0A=0AAm Sonntag, den 06.04.2014, = 19:15 -0700 schrieb Paul Jansen:=0A> My mail client might mangle the bottom= -posting here, so we'll see how=0A> it goes.=0A> I saw a post from Fabian t= hat he had re-enabled jenkins builds of the=0A> node image based on Fedora = 19/20 (but not yet including the VDSM=0A> plugin).=A0 Presumably the main g= oal of this is to ensure that things in=0A> node land are OK for an upcomin= g spin based on EL7?=0A=0AEL7 is one point, but there were users also askin= g for Fedora based=0ANodes and we use Fedora for development, to have stabl= e Nodes (at some=0Apoint later) based on CentOS.=0A=0A> If ovirt does go ba= ck to having Fedora and EL based node images in the=0A> short term it would= mean that live migration will work on the Fedora=0A> images.=0A=0AThe Fedo= ra based images are at least for now available from Jenkins.=0A=0A> If it w= as also decided to allow the EL based node image to include the=0A> recompi= led qemu-kvm-rhev package the Ovirt release notes could then=0A> say that w= hen using an ovirt node image live migration is supported,=0A> as is when a= fedora install has the ovirt hypervisor packages=0A> installed.=0A=0AWhat = is this ovirt hypervisor package you mention?=0A=0A- fabian=0A=0A=0A> It wo= uld only be that an EL based system - built up to then also=0A> include the= ovirt hypervisor packages - that live migration would not=0A> be supported= - at this stage.=0A> This can change when the details are further worked o= ut with the=0A> Centos people about how the updated qemu-kvm packages will = be hosted=0A> and made available.=0A> In the meantime, people that want to = set things up so that live=0A> migration is there can do so.=0A> =0A> Once = live migration is in place I think it would be interesting to try=0A> and f= ind out from people interested (or already testing ovirt) that=0A> have VMw= are backgrounds/experience what they think is the the largest=0A> outstandi= ng issue feature wise when comparing ovirt to Vcenter.=A0 What=0A> would st= op them from migrating from vcenter to ovirt? --708812334-390794442-1396859291=:39119 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">I'm going to try top posting this time to see if it ends up l= ooking a bit better on the list.<br><br>By the 'ovirt hypervisor packages' = I meant installing the OS first of all and then making it into an ovirt 'no= de' by installing the required packages, rather than installing from a clea= n slate with the ovirt node iso. Sorry if that was a bit unclear.<br>= <br><div style=3D"font-family: HelveticaNeue, Helvetica Neue, Helvetica, Ar= ial, Lucida Grande, Sans-Serif; font-size: 12pt;"> <div style=3D"font-famil= y: times new roman, new york, times, serif; font-size: 12pt;"> <div dir=3D"= ltr"> <hr size=3D"1"> <font face=3D"Arial" size=3D"2"> <b><span style=3D"f= ont-weight:bold;">From:</span></b> Fabian Deutsch <br> <b><span style=3D"fo= nt-weight: bold;">To:</span></b> Paul Jansen <br><b><span style=3D"font-wei= ght: bold;">Cc:</span></b> Doron Fediuck; users<br> <b><span style=3D"font-weig= ht: bold;">Sent:</span></b> Monday, 7 April 2014 5:20 PM<br> <b><span style= =3D"font-weight: bold;">Subject:</span></b> Re: [Users] node spin including= qemu-kvm-rhev?<br> </font> </div> <div class=3D"y_msg_container"><br>Am So= nntag, den 06.04.2014, 19:15 -0700 schrieb Paul Jansen:<br clear=3D"none">&= gt; My mail client might mangle the bottom-posting here, so we'll see how<b= r clear=3D"none">> it goes.<br clear=3D"none">> I saw a post from Fab= ian that he had re-enabled jenkins builds of the<br clear=3D"none">> nod= e image based on Fedora 19/20 (but not yet including the VDSM<br clear=3D"n= one">> plugin). Presumably the main goal of this is to ensure that= things in<br clear=3D"none">> node land are OK for an upcoming spin bas= ed on EL7?<br clear=3D"none"><br clear=3D"none">EL7 is one point, but there= were users also asking for Fedora based<br clear=3D"none">Nodes and we use= Fedora for development, to have stable Nodes (at some<br clear=3D"none">point later) = based on CentOS.<br clear=3D"none"><br clear=3D"none">> If ovirt does go= back to having Fedora and EL based node images in the<br clear=3D"none">&g= t; short term it would mean that live migration will work on the Fedora<br = clear=3D"none">> images.<br clear=3D"none"><br clear=3D"none">The Fedora= based images are at least for now available from Jenkins.<br clear=3D"none= "><br clear=3D"none">> If it was also decided to allow the EL based node= image to include the<br clear=3D"none">> recompiled qemu-kvm-rhev packa= ge the Ovirt release notes could then<br clear=3D"none">> say that when = using an ovirt node image live migration is supported,<br clear=3D"none">&g= t; as is when a fedora install has the ovirt hypervisor packages<br clear= =3D"none">> installed.<br clear=3D"none"><br clear=3D"none">What is this= ovirt hypervisor package you mention?<br clear=3D"none"><br clear=3D"none"=
- fabian<div class=3D"yqt5664411254" id=3D"yqtfd44699"><br clear=3D"none"><br clear=3D"= none">> It would only be that an EL based system - built up to then also= <br clear=3D"none">> include the ovirt hypervisor packages - that live m= igration would not<br clear=3D"none">> be supported - at this stage.<br = clear=3D"none">> This can change when the details are further worked out= with the<br clear=3D"none">> Centos people about how the updated qemu-k= vm packages will be hosted<br clear=3D"none">> and made available.<br cl= ear=3D"none">> In the meantime, people that want to set things up so tha= t live<br clear=3D"none">> migration is there can do so.<br clear=3D"non= e">> <br clear=3D"none">> Once live migration is in place I think it = would be interesting to try<br clear=3D"none">> and find out from people= interested (or already testing ovirt) that<br clear=3D"none">> have VMw= are backgrounds/experience what they think is the the largest<br clear=3D"n= one">> outstanding issue feature wise when comparing ovirt to Vcenter. What<br clear=3D= "none">> would stop them from migrating from vcenter to ovirt?<br clear= =3D"none"><br clear=3D"none"><br clear=3D"none"></div><br><br></div> </div>= </div> </div></body></html> --708812334-390794442-1396859291=:39119--
Hey Paul, Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen:
I'm going to try top posting this time to see if it ends up looking a bit better on the list.
you could try sending text-only emails :)
By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear.
Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system. Greetings fabian
______________________________________________________________________ From: Fabian Deutsch To: Paul Jansen Cc: Doron Fediuck; users Sent: Monday, 7 April 2014 5:20 PM Subject: Re: [Users] node spin including qemu-kvm-rhev?
My mail client might mangle the bottom-posting here, so we'll see how it goes. I saw a post from Fabian that he had re-enabled jenkins builds of
Am Sonntag, den 06.04.2014, 19:15 -0700 schrieb Paul Jansen: the
node image based on Fedora 19/20 (but not yet including the VDSM plugin). Presumably the main goal of this is to ensure that things in node land are OK for an upcoming spin based on EL7?
EL7 is one point, but there were users also asking for Fedora based Nodes and we use Fedora for development, to have stable Nodes (at some point later) based on CentOS.
If ovirt does go back to having Fedora and EL based node images in the short term it would mean that live migration will work on the Fedora images.
The Fedora based images are at least for now available from Jenkins.
If it was also decided to allow the EL based node image to include the recompiled qemu-kvm-rhev package the Ovirt release notes could then say that when using an ovirt node image live migration is supported, as is when a fedora install has the ovirt hypervisor packages installed.
What is this ovirt hypervisor package you mention?
- fabian
It would only be that an EL based system - built up to then also include the ovirt hypervisor packages - that live migration would not be supported - at this stage. This can change when the details are further worked out with the Centos people about how the updated qemu-kvm packages will be hosted and made available. In the meantime, people that want to set things up so that live migration is there can do so.
Once live migration is in place I think it would be interesting to try and find out from people interested (or already testing ovirt) that have VMware backgrounds/experience what they think is the the largest outstanding issue feature wise when comparing ovirt to Vcenter. What would stop them from migrating from vcenter to ovirt?
On 04/07/2014 11:46 AM, Fabian Deutsch wrote:
Hey Paul,
Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen:
I'm going to try top posting this time to see if it ends up looking a bit better on the list.
you could try sending text-only emails :)
By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear.
Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system.
just to make sure there is no confusion, ovirt supports two types of nodes: - plain fedora/rhel/centos - engine will deploy vdsm and friends on it when added - ovirt-node - engine will only register it, it already comes with all needed packages.
--1060583355-253711514-1396873519=:49680 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On 04/07/2014 11:46 AM, Fabian Deutsch wrote:=0A=0A> Hey Paul,=0A>=0A> Am M= ontag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen:=0A>> I'm going to t= ry top posting this time to see if it ends up looking 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 installing the OS first of=0A>> all an= d then making it into an ovirt 'node' by installing the required=0A>> packa= ges, rather than installing from a clean slate with the ovirt=0A>> node iso= .=A0 Sorry if that was a bit unclear.=0A>=0A> Okay - thanks for the explana= tion.=0A> In general I would discourage from installing the ovirt-node pack= age 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=0AI'm pretty sure we are= on the same page here.=A0 I just checked the ovirt 'quickstart' page and i= t calls the various hypervisor nodes 'hosts'.=0Aie: Fedora host, EL, host, = ovirt node host.=0AIf the ovirt node included the qemu-kvm-rhev package - o= r an updated qemu-kvm - it would mean that both ovirt node hosts and fedora= hosts could both support live storage migration.=A0 It would only be EL ho= sts that do not support that feature at this stage.=A0 We could have a cave= at in the documentation for this perhaps.=0AFabian, were you think thinking= that if not all 'hosts' supported live migration that the cluster could di= sable that feature? Based on capabilities that the hosts would expose to th= e ovirt server?=A0 This would be another way of avoiding the confusion.=0A= =0AThanks guys for the great work you are doing with ovirt.=0A --1060583355-253711514-1396873519=:49680 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"><div style=3D"font-family: HelveticaNeue, Helvetica Neue, Hel= vetica, Arial, Lucida Grande, Sans-Serif; font-size: 12pt;"><div style=3D"f= ont-family: times new roman, new york, times, serif; font-size: 12pt;">On 0= 4/07/2014 11:46 AM, Fabian Deutsch wrote:<div class=3D"y_msg_container"><di= v class=3D"yqt3432433946" id=3D"yqtfd62072"><br clear=3D"none">> Hey Pau= l,<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 t= ry top posting this time to see if it ends up looking a<br clear=3D"none">&= gt;> bit better on the list.<br clear=3D"none">><br clear=3D"none">&g= t; you could try sending text-only emails :)<br clear=3D"none">><br clea= r=3D"none">>> By the 'ovirt hypervisor packages' I meant installing t= he OS first of<br clear=3D"none">>> all and then making it into an ovirt 'node' by ins= talling the required<br clear=3D"none">>> packages, rather than insta= lling from a clean slate with the ovirt<br clear=3D"none">>> node iso= . Sorry if that was a bit unclear.<br clear=3D"none">><br clear=3D= "none">> Okay - thanks for the explanation.<br clear=3D"none">> In ge= neral I would discourage from installing the ovirt-node package ona<br clea= r=3D"none">> normal host.<br clear=3D"none">> If you still want to tr= y it be aware that the ovirt-node pkg might mess<br clear=3D"none">> wit= h your system.</div><br clear=3D"none"><br clear=3D"none">I'm pretty sure w= e are on the same page here. I just checked the ovirt 'quickstart' pa= ge and it calls the various hypervisor nodes 'hosts'.<br>ie: Fedora host, E= L, host, ovirt node host.<br>If the ovirt node included the qemu-kvm-rhev p= ackage - or an updated qemu-kvm - it would mean that both ovirt node hosts = and fedora hosts could both support live storage migration. It would only be EL= hosts that do not support that feature at this stage. We could have = a caveat in the documentation for this perhaps.<br>Fabian, were you think t= hinking that if not all 'hosts' supported live migration that the cluster c= ould disable that feature? Based on capabilities that the hosts would expos= e to the ovirt server? This would be another way of avoiding the conf= usion.<br><br>Thanks guys for the great work you are doing with ovirt.<br><= /div> </div> </div> </div></body></html> --1060583355-253711514-1396873519=:49680--
----- Original Message -----
From: "Paul Jansen" <vlaero@yahoo.com.au> To: "Itamar Heim" <iheim@redhat.com>, "Fabian Deutsch" <fdeutsch@redhat.com> Cc: "users" <users@ovirt.org> Sent: Monday, April 7, 2014 3:25:19 PM Subject: Re: [Users] node spin including qemu-kvm-rhev?
On 04/07/2014 11:46 AM, Fabian Deutsch wrote:
Hey Paul,
Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen:
I'm going to try top posting this time to see if it ends up looking a bit better on the list.
you could try sending text-only emails :)
By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear.
Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system.
I'm pretty sure we are on the same page here. I just checked the ovirt 'quickstart' page and it calls the various hypervisor nodes 'hosts'. ie: Fedora host, EL, host, ovirt node host. If the ovirt node included the qemu-kvm-rhev package - or an updated qemu-kvm - it would mean that both ovirt node hosts and fedora hosts could both support live storage migration. It would only be EL hosts that do not support that feature at this stage. We could have a caveat in the documentation for this perhaps. Fabian, were you think thinking that if not all 'hosts' supported live migration that the cluster could disable that feature? Based on capabilities that the hosts would expose to the ovirt server? This would be another way of avoiding the confusion.
Thanks guys for the great work you are doing with ovirt.
Paul, this is something that vdsm needs to report to the engine, so the engine will know what is / isn't supported. It's a bigger request as today we're mostly based on cluster compatibility level. Additionally it is possible to mix .el hosts with nodes with old (non -rhev) nodes. Each of these cases will break live-storage migration. How do you suggest to mitigate it?
On 04/08/2014 06:58 PM, Doron Fediuck wrote:
----- Original Message -----
From: "Paul Jansen" <vlaero@yahoo.com.au> To: "Itamar Heim" <iheim@redhat.com>, "Fabian Deutsch" <fdeutsch@redhat.com> Cc: "users" <users@ovirt.org> Sent: Monday, April 7, 2014 3:25:19 PM Subject: Re: [Users] node spin including qemu-kvm-rhev?
On 04/07/2014 11:46 AM, Fabian Deutsch wrote:
Hey Paul,
Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen:
I'm going to try top posting this time to see if it ends up looking a bit better on the list.
you could try sending text-only emails :)
By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear.
Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system.
I'm pretty sure we are on the same page here. I just checked the ovirt 'quickstart' page and it calls the various hypervisor nodes 'hosts'. ie: Fedora host, EL, host, ovirt node host. If the ovirt node included the qemu-kvm-rhev package - or an updated qemu-kvm - it would mean that both ovirt node hosts and fedora hosts could both support live storage migration. It would only be EL hosts that do not support that feature at this stage. We could have a caveat in the documentation for this perhaps. Fabian, were you think thinking that if not all 'hosts' supported live migration that the cluster could disable that feature? Based on capabilities that the hosts would expose to the ovirt server? This would be another way of avoiding the confusion.
Thanks guys for the great work you are doing with ovirt.
Paul, this is something that vdsm needs to report to the engine, so the engine will know what is / isn't supported. It's a bigger request as today we're mostly based on cluster compatibility level.
Additionally it is possible to mix .el hosts with nodes with old (non -rhev) nodes. Each of these cases will break live-storage migration.
How do you suggest to mitigate it?
seems like another case of feature level negotiatio.
=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--
On 04/09/2014 06:41 AM, Paul Jansen wrote:
----- Original Message -----
From: "Paul Jansen" To: "Itamar Heim" "Fabian Deutsch" Cc: "users" Sent: Monday, April 7, 2014 3:25:19 PM Subject: Re: [Users] node spin including qemu-kvm-rhev?
On 04/07/2014 11:46 AM, Fabian Deutsch wrote:
Hey Paul,
Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen:
I'm going to try top posting this time to see if it ends up looking a bit better on the list.
you could try sending text-only emails :)
By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear.
Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node
package ona
normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system.
I'm pretty sure we are on the same page here. I just checked the ovirt 'quickstart' page and it calls the various hypervisor nodes 'hosts'. ie: Fedora host, EL, host, ovirt node host. If the ovirt node included the qemu-kvm-rhev package - or an updated qemu-kvm - it would mean that both ovirt node hosts and fedora hosts could both support live storage migration. It would only be EL hosts that do not support that feature at this stage. We could have a caveat in the documentation for this perhaps. Fabian, were you think thinking that if not all 'hosts' supported live migration that the cluster could disable that feature? Based on capabilities that the hosts would expose to the ovirt server? This would be another way of avoiding the confusion.
Thanks guys for the great work you are doing with ovirt.
Paul, this is something that vdsm needs to report to the engine, so the engine will know what is / isn't supported. It's a bigger request as today we're mostly based on cluster compatibility level.
Additionally it is possible to mix .el hosts with nodes with old (non -rhev) nodes. Each of these cases will break live-storage migration.
How do you suggest to mitigate it?
Well, when you choose to migrate a VM under Vmware's Vcenter you can choose to migrate either the host or the datastore. For whichever one you choose there is a validation step to check the you are able to perform the migration (ie: capabilities of the host). I can see in ovirt that we are showing the KVM version on hosts. This matches the package version of the qemu-kvm package (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-kvm-rhev) support the storage migration feature, and if a version is found that doesn't match the required heuristics we just indicate the the validation process for the migration has failed? We could provide some small output indicating why it has failed. Does this sound like a reasonable approach?
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)? If the hosting of an updated qemu-kvm (or qemu-kvm-rhev) is not sorted 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. We may see an EL7.0 before that timeframe. Ovirt can obviously jump on new EL releases to use as hosts in a new ovirt version but it seems this option is still some time away.
Paul - just to clarify, you are mentioning "versions" all the time, but qemu-kvm doesn't have these features regardless of version. you need the qemu-kvm-rhev package, which we hope to get into the CentOS cloud or virt SIG, and for now is available via jenkins.ovirt.org based on the centos srpm.
Am Sonntag, den 06.04.2014, 11:57 -0400 schrieb Doron Fediuck:
----- Original Message -----
From: "Paul Jansen" <vlaero@yahoo.com.au> To: "users" <users@ovirt.org> Sent: Wednesday, April 2, 2014 11:38:29 AM Subject: [Users] node spin including qemu-kvm-rhev?
I understand that there are ongoing discussions with the Centos people regarding a suitable home for recompiled qemu-kvm packages. Given that the ovirt node is our own spin, is there any reason why that couldn't include the recompiled qemu-kvm packages that will then allow us to use live snapshots and do live migrations? Itamar recently mentioned that we already build these via a jenkins task.
Nodes built on top of a Centos install will still be an issue but I think its reasonable that the ovirt-node iso could include these custom packages. This way we don't have to potentially wait until 3.4.1 or 3.5 to get the live snapshot/migration features. The caveat would be that these features would only be supported if the nodes were all ovirt node iso based.
What are people's thoughts?
Sounds reasonable as long as you understand mix and match will become an issue. The questions is how do we differentiate between the nodes to make sure no one mixes them by mistake?
Hey, yeah - that is also my concern. oVirt node has a mechanism (in master) to expose that features are present or not, but I don't know if vdsm has the capability to pass this on to Engine, and if Engine has the logic to detect incompatabilities based on the underlying qemu-kvm-rhev version. Greetings fabian
participants (4)
-
Doron Fediuck -
Fabian Deutsch -
Itamar Heim -
Paul Jansen