<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:12pt">><br clear="none"><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;"><div class="y_msg_container"><div class="yqt9860674902" id="yqtfd27637">><br clear="none">> ----- Original Message -----<br clear="none">>> From: "Paul Jansen"<br clear="none">>> To: "Itamar Heim" "Fabian Deutsch"<br clear="none">>> Cc: "users"<br clear="none">>> Sent: Monday, April 7, 2014 3:25:19 PM<br clear="none">>> Subject: Re: [Users] node spin including qemu-kvm-rhev?<br clear="none">>><br clear="none">>> On 04/07/2014 11:46 AM, Fabian Deutsch wrote:<br clear="none">>><br clear="none">>>> Hey Paul,<br
clear="none">>>><br clear="none">>>> Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen:<br clear="none">>>>> I'm going to try top posting this time to see if it ends up looking a<br clear="none">>>>> bit better on the list.<br clear="none">>>><br clear="none">>>> you could try sending text-only emails :)<br clear="none">>>><br clear="none">>>>> By the 'ovirt hypervisor packages' I meant installing the OS first of<br clear="none">>>>> all and then making it into an ovirt 'node' by installing the required<br clear="none">>>>> packages, rather than installing from a clean slate with the ovirt<br clear="none">>>>> node iso. Sorry if that was a bit unclear.<br clear="none">>>><br clear="none">>>> Okay - thanks for the explanation.<br clear="none">>>> In general I would discourage from installing the
ovirt-node package ona<br clear="none">>>> normal host.<br clear="none">>>> If you still want to try it be aware that the ovirt-node pkg might mess<br clear="none">>>> with your system.<br clear="none">>><br clear="none">>><br clear="none">>> I'm pretty sure we are on the same page here. I just checked the ovirt<br clear="none">>> 'quickstart' page and it calls the various hypervisor nodes 'hosts'.<br clear="none">>> ie: Fedora host, EL, host, ovirt node host.<br clear="none">>> If the ovirt node included the qemu-kvm-rhev package - or an updated qemu-kvm<br clear="none">>> - it would mean that both ovirt node hosts and fedora hosts could both<br clear="none">>> support live storage migration. It would only be EL hosts that do not<br clear="none">>> support that feature at this stage. We could have a caveat in the<br clear="none">>> documentation for this perhaps.<br
clear="none">>> Fabian, were you think thinking that if not all 'hosts' supported live<br clear="none">>> migration that the cluster could disable that feature? Based on capabilities<br clear="none">>> that the hosts would expose to the ovirt server? This would be another way<br clear="none">>> of avoiding the confusion.<br clear="none">>><br clear="none">>> Thanks guys for the great work you are doing with ovirt.<br clear="none">>><br clear="none">><br clear="none">> Paul,<br clear="none">> this is something that vdsm needs to report to the engine, so the engine will<br clear="none">> know what is / isn't supported. It's a bigger request as today we're mostly<br clear="none">> based on cluster compatibility level.<br clear="none">><br clear="none">> Additionally it is possible to mix .el hosts with nodes with old (non -rhev) nodes.<br clear="none">> Each of these cases will break
live-storage migration.<br clear="none">><br clear="none">> How do you suggest to mitigate it?</div><br clear="none">><br clear="none">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?<br>We could 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 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.<br>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.<br></div> </div> </div> </div></body></html>