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