<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:12pt"><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 12pt;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><br><div class="y_msg_container"><br><br clear="none"><div class="yqt0237477400" id="yqtfd00318"><br clear="none">----- Original Message -----<br clear="none">> From: "Paul Jansen" <<a shape="rect" ymailto="mailto:vlaero@yahoo.com.au" href="mailto:vlaero@yahoo.com.au">vlaero@yahoo.com.au</a>><br clear="none">> To: "users" <<a shape="rect" ymailto="mailto:users@ovirt.org" href="mailto:users@ovirt.org">users@ovirt.org</a>><br clear="none">> Sent: Wednesday, April 2, 2014 11:38:29 AM<br clear="none">> Subject: [Users] node spin including qemu-kvm-rhev?<br clear="none">>
<br clear="none">> I understand that there are ongoing discussions with the Centos people<br clear="none">> regarding a suitable home for recompiled qemu-kvm packages.<br clear="none">> Given that the ovirt node is our own spin, is there any reason why that<br clear="none">> couldn't include the recompiled qemu-kvm packages that will then allow us to<br clear="none">> use live snapshots and do live migrations? Itamar recently mentioned that we<br clear="none">> already build these via a jenkins task.<br clear="none">> <br clear="none">> Nodes built on top of a Centos install will still be an issue but I think its<br clear="none">> reasonable that the ovirt-node iso could include these custom packages.<br clear="none">> This way we don't have to potentially wait until 3.4.1 or 3.5 to get the live<br clear="none">> snapshot/migration features. The caveat would be that these features would<br clear="none">> only be
supported if the nodes were all ovirt node iso based.<br clear="none">> <br clear="none">> What are people's thoughts?</div><br clear="none">> <br clear="none">> <br clear="none"><br clear="none">Sounds reasonable as long as you understand mix and match will become an issue.<br clear="none">The questions is how do we differentiate between the nodes to make sure no one<br clear="none">mixes them by mistake?<div class="yqt0237477400" id="yqtfd35489"><br clear="none"></div><br><br>My mail client might mangle the bottom-posting here, so we'll see how it goes.<br>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?<br>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.<br>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.<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 further worked out with the Centos people about how the updated qemu-kvm packages will be hosted and made available.<br>In the meantime, people that want to 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 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?<br></div> </div> </div> </div></body></html>