Re: [Users] node spin including qemu-kvm-rhev?

----- Original Message ----- > From: "Paul Jansen" <vlaero(a)yahoo.com.au&gt; > To: "Itamar Heim" <iheim(a)redhat.com&gt;, "Fabian Deutsch" <fdeutsch(a)redhat.com&gt; > Cc: "users" <users(a)ovirt.org&gt; > 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?