4:38 a.m.
---847950152-1364082376-1396427909=:14395
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
I understand that there are ongoing discussions with the Centos people rega=
rding a suitable home for recompiled qemu-kvm packages.=0AGiven that the ov=
irt node is our own spin, is there any reason why that couldn't include the=
recompiled qemu-kvm packages that will then allow us to use live snapshots=
and do live migrations?=A0 Itamar recently mentioned that we already build=
these via a jenkins task.=0A=0ANodes built on top of a Centos install will=
still be an issue but I think its reasonable that the ovirt-node iso could=
include these custom packages.=0AThis way we don't have to potentially wai=
t until 3.4.1 or 3.5 to get the live snapshot/migration features.=A0 The ca=
veat would be that these features would only be supported if the nodes were=
all ovirt node iso based.=0A=0AWhat are people's thoughts?=0A
---847950152-1364082376-1396427909=:14395
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>I understand that there are ongoing discussions with
the=
Centos people regarding a suitable home for recompiled qemu-kvm packages.<=
/div><div><span>Given that the ovirt node is our own spin, is there any
rea=
son why that couldn't include the recompiled qemu-kvm packages that will th=
en allow us to use live snapshots and do live migrations? Itamar rece=
ntly mentioned that we already build these via a jenkins task.</span></div>=
<div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaN=
eue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif; background-col=
or: transparent; font-style:
normal;"><span><br></span></div><div style=3D"=
color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica =
Neue,Helvetica,Arial,Lucida Grande,Sans-Serif; background-color:
transparent; font-style: normal;"><span>Nodes built on top of a Centos
ins=
tall will still be an issue but I think its reasonable that the ovirt-node =
iso could include these custom packages.</span></div><div
style=3D"color: r=
gb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Hel=
vetica,Arial,Lucida Grande,Sans-Serif; background-color: transparent; font-=
style: normal;"><span>This way we don't have to potentially wait until
3.4.=
1 or 3.5 to get the live snapshot/migration features. The caveat woul=
d be that these features would only be supported if the nodes were all ovir=
t node iso based.</span></div><div style=3D"color: rgb(0, 0, 0);
font-size:=
16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gra=
nde,Sans-Serif; background-color: transparent; font-style:
normal;"><br><sp=
an></span></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px;
font-fa=
mily: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida
Grande,Sans-Serif; background-color: transparent; font-style: normal;"><sp=
an>What are people's thoughts?</span></div><div style=3D"color:
rgb(0, 0, 0=
); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Ari=
al,Lucida Grande,Sans-Serif; background-color: transparent; font-style: nor=
mal;"><span><br></span></div></div></body></html>
---847950152-1364082376-1396427909=:14395--
11:57 a.m.
----- Original Message -----
From: "Paul Jansen" <vlaero(a)yahoo.com.au>
To: "users" <users(a)ovirt.org>
Sent: Wednesday, April 2, 2014 11:38:29 AM
Subject: [Users] node spin including qemu-kvm-rhev?
I understand that there are ongoing discussions with the Centos people
regarding a suitable home for recompiled qemu-kvm packages.
Given that the ovirt node is our own spin, is there any reason why that
couldn't include the recompiled qemu-kvm packages that will then allow us to
use live snapshots and do live migrations? Itamar recently mentioned that we
already build these via a jenkins task.
Nodes built on top of a Centos install will still be an issue but I think its
reasonable that the ovirt-node iso could include these custom packages.
This way we don't have to potentially wait until 3.4.1 or 3.5 to get the live
snapshot/migration features. The caveat would be that these features would
only be supported if the nodes were all ovirt node iso based.
What are people's thoughts?
Sounds reasonable as long as you understand mix and match will become an issue.
The questions is how do we differentiate between the nodes to make sure no one
mixes them by mistake?
10:15 p.m.
---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(a)yahoo.com.au>=0A> To: "users" <users(a)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=
=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=
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--
3:50 a.m.
Am Sonntag, den 06.04.2014, 19:15 -0700 schrieb Paul Jansen:
My mail client might mangle the bottom-posting here, so we'll see
how
it goes.
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?
EL7 is one point, but there were users also asking for Fedora based
Nodes and we use Fedora for development, to have stable Nodes (at some
point later) based on CentOS.
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.
The Fedora based images are at least for now available from Jenkins.
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.
What is this ovirt hypervisor package you mention?
- fabian
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.
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.
In the meantime, people that want to set things up so that live
migration is there can do so.
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?
4:28 a.m.
--708812334-390794442-1396859291=:39119
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
I'm going to try top posting this time to see if it ends up looking a bit b=
etter on the list.=0A=0ABy the 'ovirt hypervisor packages' I meant installi=
ng the OS first of all and then making it into an ovirt 'node' by installin=
g the required packages, rather than installing from a clean slate with the=
ovirt node iso.=A0 Sorry if that was a bit unclear.=0A=0A=0A=0A___________=
_____________________=0A From: Fabian Deutsch =0ATo: Paul Jansen =0ACc: Dor=
on Fediuck; users=0ASent: Monday, 7 April 2014 5:20 PM=0ASubject: Re: [User=
s] node spin including qemu-kvm-rhev?=0A =0A=0AAm Sonntag, den 06.04.2014, =
19:15 -0700 schrieb Paul Jansen:=0A> My mail client might mangle the bottom=
-posting here, so we'll see how=0A> it goes.=0A> I saw a post from Fabian t=
hat he had re-enabled jenkins builds of the=0A> node image based on Fedora =
19/20 (but not yet including the VDSM=0A> plugin).=A0 Presumably the main g=
oal of this is to ensure that things in=0A> node land are OK for an upcomin=
g spin based on EL7?=0A=0AEL7 is one point, but there were users also askin=
g for Fedora based=0ANodes and we use Fedora for development, to have stabl=
e Nodes (at some=0Apoint later) based on CentOS.=0A=0A> If ovirt does go ba=
ck to having Fedora and EL based node images in the=0A> short term it would=
mean that live migration will work on the Fedora=0A> images.=0A=0AThe Fedo=
ra based images are at least for now available from Jenkins.=0A=0A> If it w=
as also decided to allow the EL based node image to include the=0A> recompi=
led qemu-kvm-rhev package the Ovirt release notes could then=0A> say that w=
hen using an ovirt node image live migration is supported,=0A> as is when a=
fedora install has the ovirt hypervisor packages=0A> installed.=0A=0AWhat =
is this ovirt hypervisor package you mention?=0A=0A- fabian=0A=0A=0A> It wo=
uld only be that an EL based system - built up to then also=0A> include the=
ovirt hypervisor packages - that live migration would not=0A> be supported=
- at this stage.=0A> This can change when the details are further worked o=
ut with the=0A> Centos people about how the updated qemu-kvm packages will =
be hosted=0A> and made available.=0A> In the meantime, people that want to =
set things up so that live=0A> migration is there can do so.=0A> =0A> Once =
live migration is in place I think it would be interesting to try=0A> and f=
ind out from people interested (or already testing ovirt) that=0A> have VMw=
are backgrounds/experience what they think is the the largest=0A> outstandi=
ng issue feature wise when comparing ovirt to Vcenter.=A0 What=0A> would st=
op them from migrating from vcenter to ovirt?
--708812334-390794442-1396859291=:39119
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">I'm going to try top posting this time to see if it ends up l=
ooking a bit better on the list.<br><br>By the 'ovirt hypervisor
packages' =
I meant installing the OS first of all and then making it into an ovirt 'no=
de' by installing the required packages, rather than installing from a clea=
n slate with the ovirt node iso. Sorry if that was a bit unclear.<br>=
<br><div style=3D"font-family: HelveticaNeue, Helvetica Neue, Helvetica,
Ar=
ial, Lucida Grande, Sans-Serif; font-size: 12pt;"> <div
style=3D"font-famil=
y: times new roman, new york, times, serif; font-size: 12pt;"> <div
dir=3D"=
ltr"> <hr size=3D"1"> <font face=3D"Arial"
size=3D"2"> <b><span style=3D"f=
ont-weight:bold;">From:</span></b> Fabian Deutsch <br>
<b><span style=3D"fo=
nt-weight: bold;">To:</span></b> Paul Jansen
<br><b><span style=3D"font-wei=
ght:
bold;">Cc:</span></b> Doron Fediuck; users<br>
<b><span style=3D"font-weig=
ht: bold;">Sent:</span></b> Monday, 7 April 2014 5:20 PM<br>
<b><span style=
=3D"font-weight: bold;">Subject:</span></b> Re: [Users] node spin
including=
qemu-kvm-rhev?<br> </font> </div> <div
class=3D"y_msg_container"><br>Am So=
nntag, den 06.04.2014, 19:15 -0700 schrieb Paul Jansen:<br
clear=3D"none">&=
gt; My mail client might mangle the bottom-posting here, so we'll see how<b=
r clear=3D"none">> it goes.<br clear=3D"none">>
I saw a post from Fab=
ian that he had re-enabled jenkins builds of the<br
clear=3D"none">> nod=
e image based on Fedora 19/20 (but not yet including the VDSM<br clear=3D"n=
one">> plugin). Presumably the main goal of this is to ensure
that=
things in<br clear=3D"none">> node land are OK for an upcoming
spin bas=
ed on EL7?<br clear=3D"none"><br clear=3D"none">EL7 is one
point, but there=
were users also asking for Fedora based<br clear=3D"none">Nodes and we
use=
Fedora for
development, to have stable Nodes (at some<br clear=3D"none">point later)
=
based on CentOS.<br clear=3D"none"><br
clear=3D"none">> If ovirt does go=
back to having Fedora and EL based node images in the<br
clear=3D"none">&g=
t; short term it would mean that live migration will work on the Fedora<br =
clear=3D"none">> images.<br clear=3D"none"><br
clear=3D"none">The Fedora=
based images are at least for now available from Jenkins.<br clear=3D"none=
"><br clear=3D"none">> If it was also decided to allow the
EL based node=
image to include the<br clear=3D"none">> recompiled qemu-kvm-rhev
packa=
ge the Ovirt release notes could then<br clear=3D"none">> say that
when =
using an ovirt node image live migration is supported,<br
clear=3D"none">&g=
t; as is when a fedora install has the ovirt hypervisor packages<br clear=
=3D"none">> installed.<br clear=3D"none"><br
clear=3D"none">What is this=
ovirt hypervisor package you mention?<br clear=3D"none"><br
clear=3D"none"=
- fabian<div
class=3D"yqt5664411254"
id=3D"yqtfd44699"><br clear=3D"none"><br clear=3D"=
none">> It would only be that an EL based system - built up to then also=
<br clear=3D"none">> include the ovirt hypervisor packages - that
live m=
igration would not<br clear=3D"none">> be supported - at this
stage.<br =
clear=3D"none">> This can change when the details are further worked
out=
with the<br clear=3D"none">> Centos people about how the updated
qemu-k=
vm packages will be hosted<br clear=3D"none">> and made
available.<br cl=
ear=3D"none">> In the meantime, people that want to set things up so
tha=
t live<br clear=3D"none">> migration is there can do so.<br
clear=3D"non=
e">> <br clear=3D"none">> Once live migration is in
place I think it =
would be interesting to try<br clear=3D"none">> and find out from
people=
interested (or already testing ovirt) that<br clear=3D"none">>
have VMw=
are backgrounds/experience what they think is the the largest<br clear=3D"n=
one">> outstanding
issue feature wise when comparing ovirt to Vcenter. What<br clear=3D=
"none">> would stop them from migrating from vcenter to ovirt?<br
clear=
=3D"none"><br clear=3D"none"><br
clear=3D"none"></div><br><br></div> </div>=
</div> </div></body></html>
--708812334-390794442-1396859291=:39119--
4:46 a.m.
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.
Greetings
fabian
______________________________________________________________________
From: Fabian Deutsch
To: Paul Jansen
Cc: Doron Fediuck; users
Sent: Monday, 7 April 2014 5:20 PM
Subject: Re: [Users] node spin including qemu-kvm-rhev?
Am Sonntag, den 06.04.2014, 19:15 -0700 schrieb Paul Jansen:
> My mail client might mangle the bottom-posting here, so we'll see
how
> it goes.
> 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?
EL7 is one point, but there were users also asking for Fedora based
Nodes and we use Fedora for development, to have stable Nodes (at some
point later) based on CentOS.
> 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.
The Fedora based images are at least for now available from Jenkins.
> 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.
What is this ovirt hypervisor package you mention?
- fabian
> 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.
> 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.
> In the meantime, people that want to set things up so that live
> migration is there can do so.
>
> 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?
5:14 a.m.
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.
just to make sure there is no confusion, ovirt supports two types of nodes:
- plain fedora/rhel/centos - engine will deploy vdsm and friends on it
when added
- ovirt-node - engine will only register it, it already comes with all
needed packages.
8:25 a.m.
--1060583355-253711514-1396873519=:49680
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
On 04/07/2014 11:46 AM, Fabian Deutsch wrote:=0A=0A> Hey Paul,=0A>=0A> Am M=
ontag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen:=0A>> I'm going to t=
ry top posting this time to see if it ends up looking a=0A>> bit better on =
the list.=0A>=0A> you could try sending text-only emails :)=0A>=0A>> By
the=
'ovirt hypervisor packages' I meant installing the OS first of=0A>> all
an=
d then making it into an ovirt 'node' by installing the required=0A>>
packa=
ges, rather than installing from a clean slate with the ovirt=0A>> node iso=
.=A0 Sorry if that was a bit unclear.=0A>=0A> Okay - thanks for the explana=
tion.=0A> In general I would discourage from installing the ovirt-node pack=
age ona=0A> normal host.=0A> If you still want to try it be aware that the =
ovirt-node pkg might mess=0A> with your system.=0A=0AI'm pretty sure we are=
on the same page here.=A0 I just checked the ovirt 'quickstart' page and i=
t calls the various hypervisor nodes 'hosts'.=0Aie: Fedora host, EL, host, =
ovirt node host.=0AIf the ovirt node included the qemu-kvm-rhev package - o=
r an updated qemu-kvm - it would mean that both ovirt node hosts and fedora=
hosts could both support live storage migration.=A0 It would only be EL ho=
sts that do not support that feature at this stage.=A0 We could have a cave=
at in the documentation for this perhaps.=0AFabian, were you think thinking=
that if not all 'hosts' supported live migration that the cluster could di=
sable that feature? Based on capabilities that the hosts would expose to th=
e ovirt server?=A0 This would be another way of avoiding the confusion.=0A=
=0AThanks guys for the great work you are doing with ovirt.=0A
--1060583355-253711514-1396873519=:49680
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;">On 0=
4/07/2014 11:46 AM, Fabian Deutsch wrote:<div
class=3D"y_msg_container"><di=
v class=3D"yqt3432433946" id=3D"yqtfd62072"><br
clear=3D"none">> Hey Pau=
l,<br clear=3D"none">><br clear=3D"none">>
Am Montag, den 07.04.2014,=
01:28 -0700 schrieb Paul Jansen:<br clear=3D"none">>>
I'm going to t=
ry top posting this time to see if it ends up looking a<br
clear=3D"none">&=
gt;> bit better on the list.<br clear=3D"none">><br
clear=3D"none">&g=
t; you could try sending text-only emails :)<br
clear=3D"none">><br clea=
r=3D"none">>> By the 'ovirt hypervisor packages' I
meant installing t=
he OS first of<br
clear=3D"none">>> all and then making it into an ovirt
'node' by ins=
talling the required<br clear=3D"none">>> packages, rather
than insta=
lling from a clean slate with the ovirt<br clear=3D"none">>>
node iso=
. Sorry if that was a bit unclear.<br
clear=3D"none">><br clear=3D=
"none">> Okay - thanks for the explanation.<br
clear=3D"none">> In ge=
neral I would discourage from installing the ovirt-node package ona<br clea=
r=3D"none">> normal host.<br clear=3D"none">>
If you still want to tr=
y it be aware that the ovirt-node pkg might mess<br
clear=3D"none">> wit=
h your system.</div><br clear=3D"none"><br
clear=3D"none">I'm pretty sure w=
e are on the same page here. I just checked the ovirt 'quickstart' pa=
ge and it calls the various hypervisor nodes 'hosts'.<br>ie: Fedora host,
E=
L, host, ovirt node host.<br>If the ovirt node included the qemu-kvm-rhev p=
ackage - 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.<br>Fabian, were you think t=
hinking that if not all 'hosts' supported live migration that the cluster c=
ould disable that feature? Based on capabilities that the hosts would expos=
e to the ovirt server? This would be another way of avoiding the conf=
usion.<br><br>Thanks guys for the great work you are doing with
ovirt.<br><=
/div> </div> </div> </div></body></html>
--1060583355-253711514-1396873519=:49680--
11:58 a.m.
----- Original Message -----
From: "Paul Jansen" <vlaero(a)yahoo.com.au>
To: "Itamar Heim" <iheim(a)redhat.com>, "Fabian Deutsch"
<fdeutsch(a)redhat.com>
Cc: "users" <users(a)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?
1:59 p.m.
On 04/08/2014 06:58 PM, Doron Fediuck wrote:
----- Original Message -----
> From: "Paul Jansen" <vlaero(a)yahoo.com.au>
> To: "Itamar Heim" <iheim(a)redhat.com>, "Fabian Deutsch"
<fdeutsch(a)redhat.com>
> Cc: "users" <users(a)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?
seems like another case of feature level negotiatio.
11:41 p.m.
--708812334-715765816-1397014905=:84118
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
=0A=0A>=0A> ----- Original Message -----=0A>> From:
"Paul Jansen"=0A>> To:=
"Itamar Heim" "Fabian
Deutsch"=0A>> Cc: "users"=0A>> Sent: Monday, April 7=
, 2014 3:25:19 PM=0A>> Subject: Re: [Users] node spin including qemu-kvm-rh=
ev?=0A>>=0A>> On 04/07/2014 11:46 AM, Fabian Deutsch
wrote:=0A>>=0A>>> Hey =
Paul,=0A>>>=0A>>> Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul
Janse=
n:=0A>>>> I'm going to try top posting this time to see if it ends up
looki=
ng a=0A>>>> bit better on the list.=0A>>>=0A>>> you could
try sending text-=
only emails :)=0A>>>=0A>>>> By the 'ovirt hypervisor
packages' I meant inst=
alling the OS first of=0A>>>> all and then making it into an ovirt
'node' b=
y installing the required=0A>>>> packages, rather than installing from a cl=
ean slate with the ovirt=0A>>>> node iso. Sorry if that was a bit unclear.=
=0A>>>=0A>>> Okay - thanks for the explanation.=0A>>> In
general I would di=
scourage from installing the ovirt-node package ona=0A>>> normal
host.=0A>>=
If you still want to try it be aware that the ovirt-node pkg might
mess=
=0A>>> with your system.=0A>>=0A>>=0A>> I'm
pretty sure we are on the same =
page here. I just checked the ovirt=0A>> 'quickstart' page and it calls
the=
various hypervisor nodes 'hosts'.=0A>> ie: Fedora host, EL, host, ovirt
no=
de host.=0A>> If the ovirt node included the qemu-kvm-rhev package - or an =
updated qemu-kvm=0A>> - it would mean that both ovirt node hosts and fedora=
hosts could both=0A>> support live storage migration. It would only be EL =
hosts that do not=0A>> support that feature at this stage. We could have a =
caveat in the=0A>> documentation for this perhaps.=0A>> Fabian, were you th=
ink thinking that if not all 'hosts' supported live=0A>> migration that
the=
cluster could disable that feature? Based on capabilities=0A>> that the ho=
sts would expose to the ovirt server? This would be another way=0A>> of avo=
iding the confusion.=0A>>=0A>> Thanks guys for the great work you are doing=
with ovirt.=0A>>=0A>=0A> Paul,=0A> this is something that vdsm needs to
re=
port to the engine, so the engine will=0A> know what is / isn't supported. =
It's a bigger request as today we're mostly=0A> based on cluster compatibil=
ity level.=0A>=0A> Additionally it is possible to mix .el hosts with nodes =
with old (non -rhev) nodes.=0A> Each of these cases will break live-storage=
migration.=0A>=0A> How do you suggest to mitigate it?=0A>=0AWell, when you=
choose to migrate a VM under Vmware's Vcenter you can choose to migrate ei=
ther the host or the datastore.=A0 For whichever one you choose there is a =
validation step to check the you are able to perform the migration (ie: cap=
abilities of the host).=A0 I can see in ovirt that we are showing the KVM v=
ersion on hosts.=A0 This matches the package version of the qemu-kvm packag=
e (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-kv=
m-rhev) support the storage migration feature, and if a version is found th=
at doesn't match the required heuristics we just indicate the the validatio=
n process for the migration has failed?=0AWe could provide some small outpu=
t indicating why it has failed.=0ADoes this sound like a reasonable approac=
h?=0A=0AIs 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)?=0AIf the hosting of an updated qemu-kvm (or qemu-kvm-rhev) is not sor=
ted 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.=A0 We may see =
an EL7.0 before that timeframe.=0AOvirt can obviously jump on new EL releas=
es to use as hosts in a new ovirt version but it seems this option is still=
some time away.=0A
--708812334-715765816-1397014905=:84118
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">><br clear=3D"none"><div
style=3D"font-family: HelveticaNe=
ue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size:=
12pt;"><div style=3D"font-family: times new roman, new york, times,
serif;=
font-size: 12pt;"><div class=3D"y_msg_container"><div
class=3D"yqt98606749=
02" id=3D"yqtfd27637">><br
clear=3D"none">> ----- Original Message --=
---<br clear=3D"none">>> From: "Paul Jansen"<br
clear=3D"none">>&g=
t; To: "Itamar Heim" "Fabian Deutsch"<br
clear=3D"none">>> Cc: "users=
"<br clear=3D"none">>> Sent: Monday, April 7, 2014
3:25:19 PM<br clea=
r=3D"none">>> Subject: Re: [Users] node spin including
qemu-kvm-rhev?=
<br clear=3D"none">>><br
clear=3D"none">>> On 04/07/2014 11:46 =
AM, Fabian Deutsch wrote:<br clear=3D"none">>><br
clear=3D"none">>=
>> Hey Paul,<br
clear=3D"none">>>><br
clear=3D"none">>>> Am Montag, den =
07.04.2014, 01:28 -0700 schrieb Paul Jansen:<br
clear=3D"none">>>>=
> I'm going to try top posting this time to see if it ends up looking a<=
br clear=3D"none">>>>> bit better on the
list.<br clear=3D"none=
">>>><br
clear=3D"none">>>> you could try sending text-on=
ly emails :)<br clear=3D"none">>>><br
clear=3D"none">>>>&=
gt; By the 'ovirt hypervisor packages' I meant installing the OS first of<b=
r clear=3D"none">>>>> all and then making it into
an ovirt 'nod=
e' by installing the required<br
clear=3D"none">>>>> packages, =
rather than installing from a clean slate with the ovirt<br
clear=3D"none">=
>>>> node iso. Sorry if that was a bit unclear.<br
clear=3D"non=
e">>>><br
clear=3D"none">>>> Okay - thanks for the explan=
ation.<br clear=3D"none">>>> In general I would
discourage from in=
stalling the
ovirt-node package ona<br clear=3D"none">>>> normal
host.<br clea=
r=3D"none">>>> If you still want to try it be aware that
the ovirt=
-node pkg might mess<br clear=3D"none">>>> with your
system.<br cl=
ear=3D"none">>><br
clear=3D"none">>><br
clear=3D"none">>>=
I'm pretty sure we are on the same page here. I just checked the ovirt<br =
clear=3D"none">>> 'quickstart' page and it calls the
various hypervis=
or nodes 'hosts'.<br clear=3D"none">>> ie: Fedora
host, EL, host, ovi=
rt node host.<br clear=3D"none">>> If the ovirt node
included the qem=
u-kvm-rhev package - or an updated qemu-kvm<br
clear=3D"none">>> - it=
would mean that both ovirt node hosts and fedora hosts could both<br clear=
=3D"none">>> support live storage migration. It would only be
EL host=
s that do not<br clear=3D"none">>> support that feature at
this stage=
. We could have a caveat in the<br clear=3D"none">>>
documentation fo=
r this perhaps.<br
clear=3D"none">>> Fabian, were you think thinking that if not
all 'h=
osts' supported live<br clear=3D"none">>> migration that
the cluster =
could disable that feature? Based on capabilities<br
clear=3D"none">>>=
; that the hosts would expose to the ovirt server? This would be another wa=
y<br clear=3D"none">>> of avoiding the confusion.<br
clear=3D"none">&=
gt;><br clear=3D"none">>> Thanks guys for the great
work you are d=
oing with ovirt.<br clear=3D"none">>><br
clear=3D"none">><br clear=
=3D"none">> Paul,<br clear=3D"none">> this is
something that vdsm nee=
ds to report to the engine, so the engine will<br clear=3D"none">>
know =
what is / isn't supported. It's a bigger request as today we're mostly<br
c=
lear=3D"none">> based on cluster compatibility level.<br
clear=3D"none">=
><br clear=3D"none">> Additionally it is possible to mix .el
hosts wi=
th nodes with old (non -rhev) nodes.<br clear=3D"none">> Each of
these c=
ases will break
live-storage migration.<br clear=3D"none">><br
clear=3D"none">> How =
do you suggest to mitigate it?</div><br
clear=3D"none">><br clear=3D"non=
e">Well, when you choose to migrate a VM under Vmware's Vcenter you can cho=
ose to migrate either the host or the datastore. For whichever one yo=
u choose there is a validation step to check the you are able to perform th=
e migration (ie: capabilities of the host). I can see in ovirt that w=
e are showing the KVM version on hosts. This matches the package vers=
ion of the qemu-kvm package (or the qemu-kvm-rhev package if installed?). C=
ould we have some sort of a cutoff point where we know which versions of KV=
M (ie: qemu-kvm or qemu-kvm-rhev) support the storage migration feature, an=
d 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 cou=
ld 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 qem=
u-kvm (or qemu-kvm-rhev) is not sorted out in the short term, I did some qu=
ick calculations last night and it seems based on previous EL point release=
s (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>Ov=
irt can obviously jump on new EL releases to use as hosts in a new ovirt ve=
rsion but it seems this option is still some time away.<br></div> </div>
</=
div> </div></body></html>
--708812334-715765816-1397014905=:84118--
1:27 a.m.
On 04/09/2014 06:41 AM, Paul Jansen wrote:
>
>
> ----- Original Message -----
>> From: "Paul Jansen"
>> To: "Itamar Heim" "Fabian Deutsch"
>> Cc: "users"
>> 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?
>
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?
We could provide some small output indicating why it has failed.
Does this sound like a reasonable approach?
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)?
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.
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.
Paul - just to clarify, you are mentioning "versions" all the time, but
qemu-kvm doesn't have these features regardless of version. you need the
qemu-kvm-rhev package, which we hope to get into the CentOS cloud or
virt SIG, and for now is available via jenkins.ovirt.org based on the
centos srpm.
3:45 a.m.
Am Sonntag, den 06.04.2014, 11:57 -0400 schrieb Doron Fediuck:
----- Original Message -----
> From: "Paul Jansen" <vlaero(a)yahoo.com.au>
> To: "users" <users(a)ovirt.org>
> Sent: Wednesday, April 2, 2014 11:38:29 AM
> Subject: [Users] node spin including qemu-kvm-rhev?
>
> I understand that there are ongoing discussions with the Centos people
> regarding a suitable home for recompiled qemu-kvm packages.
> Given that the ovirt node is our own spin, is there any reason why that
> couldn't include the recompiled qemu-kvm packages that will then allow us to
> use live snapshots and do live migrations? Itamar recently mentioned that we
> already build these via a jenkins task.
>
> Nodes built on top of a Centos install will still be an issue but I think its
> reasonable that the ovirt-node iso could include these custom packages.
> This way we don't have to potentially wait until 3.4.1 or 3.5 to get the live
> snapshot/migration features. The caveat would be that these features would
> only be supported if the nodes were all ovirt node iso based.
>
> What are people's thoughts?
>
>
Sounds reasonable as long as you understand mix and match will become an issue.
The questions is how do we differentiate between the nodes to make sure no one
mixes them by mistake?
Hey,
yeah - that is also my concern.
oVirt node has a mechanism (in master) to expose that features are
present or not, but I don't know if vdsm has the capability to pass this
on to Engine, and if Engine has the logic to detect incompatabilities
based on the underlying qemu-kvm-rhev version.
Greetings
fabian
3681
days inactive
3688
days old
12 comments
4 participants
participants (4)
-
Doron Fediuck -
Fabian Deutsch -
Itamar Heim -
Paul Jansen