8:16 a.m.
--_4c583f28-f8af-4a5f-8f0b-d6d40c47136a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Users] Host missing cpuFlags
From: mburns(a)redhat.com
To: iheim(a)redhat.com
CC: cybertimber2000(a)hotmail.com=3B users(a)ovirt.org=3B vdsm-devel(a)lists.fe=
dorahosted.org
Date: Fri=2C 4 May 2012 07:52:30 -0400
=20
On Fri=2C 2012-05-04 at 14:34 +0300=2C Itamar Heim wrote:
> On 05/04/2012 02:26 PM=2C Nicholas Kesick wrote:
> >
> >
> > > Date: Fri=2C 4 May 2012 08:14:14 +0300
> > > From: iheim(a)redhat.com
> > > To: cybertimber2000(a)hotmail.com
> > > CC: users(a)ovirt.org
> > > Subject: Re: [Users] Host missing cpuFlags
> > >
> > > On 05/04/2012 06:49 AM=2C Nicholas Kesick wrote:
> > > > I managed to get a host successfully added into oVirt Manager (F=
edora16
> > > > minimum install=2C then used the wiki RPM
install method)=2C but=
the last
> > > > event reports "Host <hostname> moved
to Non-operational state as=
host
> > > > does not meet the cluster's minimum CPU
level. Missing CPU featu=
res:
> > > > CpuFlags"
> > > >
> > > > Can anyone shine some light on the problem? The CPU does support
> > > > virtualization... and as far as I can tell from cat /proc/cpuinf=
o does
> > > > does have cpu flags.
> > > > flags : fpu vme de pse tsc msr *pae* mce cx8 apic sep mtrr pge m=
ca cmov
> > > > pat pse36 clflush dts acpi mmx fxsr sse sse2 ss
ht tm pbe syscal=
l nx lm
> > > > constant_tsc pebs bts nopl pni dtes64 monitor
ds_cpl *vmx* est c=
id cx16
> > > > xtpr pdcm lahf_lm tpr_shadow
> > >
> > > what is the cpu level of the cluster?
> > > what cluster compatibility level?
> > > what does vdsClient -s 0 getVdsCaps shows for cpu flags?
> > I didn't even know there was a setting for that until now. This proba=
bly
> > explains it.
> > CPU Level of cluster: Intel Conroe Family
> > Cluster Compatibility Level: 3.0 (?)
> > Output of vdsClient -S - getVdsCaps:
> > vdsClient -s 0 getVdsCaps
> > HBAInventory =3D {'iSCSI': [{'InitiatorName':
> > 'iqn.1994-05.com.redhat:238a26703858'}]=2C 'FC': []}
> > ISCSIInitiatorName =3D iqn.1994-05.com.redhat:238a26703858
> > bondings =3D {'bond4': {'hwaddr':
'00:00:00:00:00:00'=2C 'cfg': {}=2C
> > 'netmask': ''=2C 'addr': ''=2C
'slaves': []}=2C 'bond0': {'hwaddr':
> > '00:00:00:00:00:00'=2C 'cfg': {}=2C 'netmask':
''=2C 'addr': ''=2C 's=
laves':
> > []}=2C 'bond1': {'hwaddr':
'00:00:00:00:00:00'=2C 'cfg': {}=2C 'netma=
sk':
''=2C
> > 'addr': ''=2C 'slaves': []}=2C
'bond2': {'hwaddr': '00:00:00:00:00:00=
'=2C
> > 'cfg': {}=2C 'netmask': ''=2C
'addr': ''=2C 'slaves': []}=2C 'bond3':=
{'hwaddr':
> > '00:00:00:00:00:00'=2C 'cfg': {}=2C
'netmask': ''=2C 'addr': ''=2C 's=
laves':
[]}}
> > clusterLevels =3D ['3.0']
> > cpuCores =3D 2
> > cpuFlags =3D
> > fpu=2Cvme=2Cde=2Cpse=2Ctsc=2Cmsr=2Cpae=2Cmce=2Ccx8=2Capic=2Csep=2Cmtr=
r=2Cpge=2Cmca=2Ccmov=2Cpat=2Cpse36=2Cclflush=2Cdts=2Cacpi=2Cmmx=2Cfxsr=2Css=
e=2Csse2=2Css=2Cht=2Ctm=2Cpbe=2Csyscall=2Cnx=2Clm=2Cconstant_tsc=2Cpebs=2Cb=
ts=2Cnopl=2Cpni=2Cdtes64=2Cmonitor=2Cds_cpl=2Cvmx=2Cest=2Ccid=2Ccx16=2Cxtpr=
=2Cpdcm=2Clahf_lm=2Ctpr_shadow=2Cmodel_486=2Cmodel_pentium=2Cmodel_pentium2=
=2Cmodel_pentium3=2Cmodel_pentiumpro=2Cmodel_qemu32=2Cmodel_coreduo=2Cmodel=
_Opteron_G1
>=20
> either libvirt isn't reporting this=2C or there is a vdsm bug filtering=
it=20
> erroneously.
> cc-ing vdsm-devel
=20
I may be completely off here=2C but isn't this the NX bit problem? You
need to have the NX bit set in BIOS for the cpu_family flag to be set
correctly. =20
=20
Mike
=20
Mike=2C
I see NX in the cpuFlags list: ...syscall=2Cnx=2Clm=2C... is that you are r=
effering to?
Though I think it boils down to the fact that what I'm running it on is a P=
entium D=2C which is the NetBurst architecture. NetBurst is below Conroe=2C=
so it would fail to meet the cluster compatibility level of Conroe.
- Nick
=
--_4c583f28-f8af-4a5f-8f0b-d6d40c47136a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>
<br><br><div><div
id=3D"SkyDrivePlaceholder"></div>>=3B Subject: Re: [Use=
rs] Host missing cpuFlags<br>>=3B From: mburns(a)redhat.com<br>&gt=3B
To: i=
heim(a)redhat.com<br>&gt=3B CC: cybertimber2000(a)hotmail.com=3B users(a)ovirt.or=
g=3B vdsm-devel(a)lists.fedorahosted.org<br>&gt=3B Date: Fri=2C 4 May 2012 07=
:52:30 -0400<br>>=3B <br>>=3B On Fri=2C 2012-05-04 at 14:34
+0300=2C It=
amar Heim wrote:<br>>=3B >=3B On 05/04/2012 02:26 PM=2C Nicholas
Kesick=
wrote:<br>>=3B >=3B >=3B<br>>=3B >=3B
>=3B<br>>=3B >=3B &g=
t=3B >=3B Date: Fri=2C 4 May 2012 08:14:14 +0300<br>>=3B >=3B
>=3B=
>=3B From: iheim(a)redhat.com<br>&gt=3B >=3B >=3B >=3B
To: cyberti=
mber2000(a)hotmail.com<br>&gt=3B >=3B >=3B >=3B CC:
users(a)ovirt.org<br=
>=3B >=3B >=3B >=3B Subject: Re: [Users] Host
missing cpuFlags<br=
>=3B >=3B >=3B >=3B<br>>=3B >=3B >=3B
>=3B On 05/04/2012=
06:49 AM=2C Nicholas Kesick wrote:<br>>=3B
>=3B >=3B >=3B >=3B =
I managed to get a host successfully added into oVirt Manager (Fedora16<br>=
>=3B >=3B >=3B >=3B >=3B minimum install=2C then used the
wiki R=
PM install method)=2C but the last<br>>=3B >=3B >=3B >=3B
>=3B e=
vent reports "Host <=3Bhostname>=3B moved to Non-operational state as h=
ost<br>>=3B >=3B >=3B >=3B >=3B does not meet the
cluster's mini=
mum CPU level. Missing CPU features:<br>>=3B >=3B >=3B >=3B
>=3B=
CpuFlags"<br>>=3B >=3B >=3B >=3B
>=3B<br>>=3B >=3B >=3B =
>=3B >=3B Can anyone shine some light on the problem? The CPU does supp=
ort<br>>=3B >=3B >=3B >=3B >=3B virtualization... and
as far as =
I can tell from cat /proc/cpuinfo does<br>>=3B >=3B >=3B
>=3B >=
=3B does have cpu flags.<br>>=3B >=3B >=3B >=3B >=3B
flags : fpu=
vme de pse tsc msr *pae* mce cx8 apic sep mtrr pge mca cmov<br>>=3B >=
=3B >=3B >=3B >=3B pat pse36 clflush dts acpi mmx fxsr sse sse2 ss h=
t tm pbe syscall nx lm<br>>=3B >=3B >=3B >=3B >=3B
constant_tsc =
pebs bts nopl pni dtes64 monitor ds_cpl *vmx* est cid cx16<br>>=3B
>=3B=
>=3B >=3B >=3B xtpr pdcm lahf_lm tpr_shadow<br>>=3B
>=3B >=3B=
>=3B<br>>=3B >=3B >=3B >=3B what is the cpu level
of the clust=
er?<br>>=3B >=3B >=3B >=3B what cluster compatibility
level?<br>&g=
t=3B >=3B >=3B >=3B what does vdsClient -s 0 getVdsCaps shows for cp=
u flags?<br>>=3B >=3B >=3B I didn't even know there was a
setting for=
that until now. This probably<br>>=3B >=3B >=3B explains
it.<br>>=
=3B >=3B >=3B CPU Level of cluster: Intel Conroe Family<br>>=3B
>=
=3B >=3B Cluster Compatibility Level: 3.0 (?)<br>>=3B >=3B
>=3B Out=
put of vdsClient -S - getVdsCaps:<br>>=3B >=3B >=3B vdsClient -s 0
ge=
tVdsCaps<br>>=3B >=3B >=3B HBAInventory =3D {'iSCSI':
[{'InitiatorNam=
e':<br>>=3B >=3B >=3B
'iqn.1994-05.com.redhat:238a26703858'}]=2C 'FC'=
: []}<br>>=3B >=3B >=3B ISCSIInitiatorName =3D
iqn.1994-05.com.redhat=
:238a26703858<br>>=3B >=3B >=3B bondings =3D {'bond4':
{'hwaddr': '00=
:00:00:00:00:00'=2C 'cfg': {}=2C<br>>=3B >=3B >=3B
'netmask': ''=2C '=
addr': ''=2C 'slaves': []}=2C 'bond0':
{'hwaddr':<br>>=3B >=3B >=3B '=
00:00:00:00:00:00'=2C 'cfg': {}=2C 'netmask': ''=2C
'addr': ''=2C 'slaves':=
<br>>=3B >=3B >=3B []}=2C 'bond1': {'hwaddr':
'00:00:00:00:00:00'=2C =
'cfg': {}=2C 'netmask': ''=2C<br>>=3B >=3B
>=3B 'addr': ''=2C 'slaves=
': []}=2C 'bond2': {'hwaddr':
'00:00:00:00:00:00'=2C<br>>=3B >=3B >=
=3B 'cfg': {}=2C 'netmask': ''=2C 'addr': ''=2C
'slaves': []}=2C 'bond3': {=
'hwaddr':<br>>=3B >=3B >=3B '00:00:00:00:00:00'=2C
'cfg': {}=2C 'netm=
ask': ''=2C 'addr': ''=2C 'slaves':
[]}}<br>>=3B >=3B >=3B clusterLev=
els =3D ['3.0']<br>>=3B >=3B >=3B cpuCores =3D
2<br>>=3B >=3B >=
=3B cpuFlags =3D<br>>=3B >=3B >=3B
fpu=2Cvme=2Cde=2Cpse=2Ctsc=2Cmsr=
=2Cpae=2Cmce=2Ccx8=2Capic=2Csep=2Cmtrr=2Cpge=2Cmca=2Ccmov=2Cpat=2Cpse36=2Cc=
lflush=2Cdts=2Cacpi=2Cmmx=2Cfxsr=2Csse=2Csse2=2Css=2Cht=2Ctm=2Cpbe=2Csyscal=
l=2Cnx=2Clm=2Cconstant_tsc=2Cpebs=2Cbts=2Cnopl=2Cpni=2Cdtes64=2Cmonitor=2Cd=
s_cpl=2Cvmx=2Cest=2Ccid=2Ccx16=2Cxtpr=2Cpdcm=2Clahf_lm=2Ctpr_shadow=2Cmodel=
_486=2Cmodel_pentium=2Cmodel_pentium2=2Cmodel_pentium3=2Cmodel_pentiumpro=
=2Cmodel_qemu32=2Cmodel_coreduo=2Cmodel_Opteron_G1<br>>=3B >=3B
<br>>=
=3B >=3B either libvirt isn't reporting this=2C or there is a vdsm bug fi=
ltering it <br>>=3B >=3B erroneously.<br>>=3B >=3B
cc-ing vdsm-deve=
l<br>>=3B <br>>=3B I may be completely off here=2C but isn't
this the N=
X bit problem? You<br>>=3B need to have the NX bit set in BIOS for the c=
pu_family flag to be set<br>>=3B correctly. <br>>=3B
<br>>=3B Mike<b=
r>>=3B <br><br>Mike=2C<br>I see NX in the cpuFlags list:
...syscall=2Cnx=
=2Clm=2C... is that you are reffering to?<br><br>Though I think it boils do=
wn to the fact that what I'm running it on is a Pentium D=2C which is the N=
etBurst architecture. NetBurst is below Conroe=2C so it would fail to meet =
the cluster compatibility level of Conroe.<br><br>-
Nick<br><br></div> =
</div></body>
</html>=
--_4c583f28-f8af-4a5f-8f0b-d6d40c47136a_--