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

[Doron Fediuck]

----- Original Message -----
> From: "Paul Jansen" <vlaero at yahoo.com.au>
> To: "Itamar Heim" <iheim at redhat.com>, "Fabian Deutsch" <fdeutsch at redhat.com>
> Cc: "users" <users at 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?