12:53 p.m.
This is a multipart message in MIME format.
------=_NextPart_000_0063_01CD4A1B.EA938040
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hi,
Every time i reboot my servers, my network interfaces change order and i
have to apply network configuration again.
Anyway to make the order of the nics persistent? I added a udev rule but
when I reboot it disappears.
Best regards,
Ricardo Esteves.
------=_NextPart_000_0063_01CD4A1B.EA938040
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DPT
link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Hi,<o:p></o:p></span></p><p
=
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p
=
class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Every time
=
i reboot my servers, my network interfaces change order and i have to =
apply network configuration again.<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p
=
class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Anyway to =
make the order of the nics persistent? I added a udev rule but when I =
reboot it disappears. <o:p></o:p></span></p><p
class=3DMsoNormal><span =
lang=3DEN-US
style=3D'color:#1F497D'><o:p> </o:p></span></p><p
=
class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Best =
regards,<o:p></o:p></span></p><p class=3DMsoNormal><span
lang=3DEN-US =
style=3D'color:#1F497D'>Ricardo =
Esteves.<o:p></o:p></span></p></div></body></html>
------=_NextPart_000_0063_01CD4A1B.EA938040--
12:56 p.m.
--=-VJZIZdWD9t/RYIM//6bF
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi,
Am Donnerstag, den 14.06.2012, 10:53 +0100 schrieb Ricardo Esteves:
Every time i reboot my servers, my network interfaces change order
and
i have to apply network configuration again.
Where does this happen? On oVirt Node or somewhere else?
Anyway to make the order of the nics persistent? I added a udev rule
but when I reboot it disappears.=20
If it's Node then the appropriate file has to be persisted to survive a
reboot. (persist MYFILE)
Greetings
- fabian
Best regards,
=20
Ricardo Esteves.
=20
=20
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--=-VJZIZdWD9t/RYIM//6bF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP2bVWAAoJEC9+uOgSHVGUXNkP/2Da+kvLdtemG3Dim5qW8k+x
ET+b+/e7y9Yrvu6Y4x5h5DKyWBRSW5UqslxW8iFFqgakqZyKnlZNORjac+hQXpmz
926H5nbmEFy68JfFrAffrNbwKfyVND3XhcH8KMwFfBe58PGguWJZXXj0nq9kAI+b
QtttV62hC3CWGsKp5dilvgs12zn2lSK28USXoRGuKsXBO5OazW9TMOvoDADGvzST
qs+BlcDXtAV8CGM30UZ6I1Pbc4X09PVmYZ9xA9q/HzfWgYdw91vm8TvlWdAxYTOb
N3/7kV/TMMxRIYHBkSI0LysyzmpMsiERvatvqwJ0qsz6//uVsJym+4vbB0VT8F+R
nNf5I6MgucblSnwvwZEVFu1+yMwOf9hzxHCv1c/KH+JLj0cTFYmQd6H3eVoXvCtN
s1enbzUmhQkWn8FNbFuuKjj3Ev/18bGuojNxNZht6OKiDzA2UWmoeGhOJ8u/3FUf
tW0ZHhRy7galXk2225UDlSt9k1fVxwJlE4khJc+R0xnoc8lHWN1W1lPXx67g+Z8Z
0Annk0K9HBggJ9IVnISft6Bf/GDK9AnukFyTHB3QO4M977DmA0hxcp7RulqVyY30
ahBWjr7l7O3j57cXAGCxS6NBlW6X4Ls/+MLC8zohUEgINKDolXwSXy+Wjpvaq4Yj
k0cAUWLyP3LgENWGLXwq
=82h4
-----END PGP SIGNATURE-----
--=-VJZIZdWD9t/RYIM//6bF--
1:29 p.m.
--=-eFNoBhoJs2NJ3i64qAhY
Content-Type: multipart/alternative; boundary="=-qa/a7JVPKHEqeV0ZHmlV"
--=-qa/a7JVPKHEqeV0ZHmlV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
This happens on the oVirt node.
I've added the file /etc/udev/rules.d/70-persistent-net.rules with the
next lines:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="d4:85:64:48:42:c0", ATTR{type}=="1",
KERNEL=="eth*",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="d4:85:64:48:42:c4", ATTR{type}=="1",
KERNEL=="eth*",
NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="1c:c1:de:7b:71:30", ATTR{type}=="1",
KERNEL=="eth*",
NAME="eth2"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="1c:c1:de:7b:71:32", ATTR{type}=="1",
KERNEL=="eth*",
NAME="eth3"
Made it persistent using the command persist, after the reboot now the
file is still there but the order of the nics still changes :(
-----Original Message-----
From: Fabian Deutsch <fabiand(a)redhat.com>
To: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>
Cc: users(a)ovirt.org
Subject: Re: [Users] Network interfaces order
Date: Thu, 14 Jun 2012 11:56:38 +0200
Hi,
Am Donnerstag, den 14.06.2012, 10:53 +0100 schrieb Ricardo Esteves:
Every time i reboot my servers, my network interfaces change order
and
i have to apply network configuration again.
Where does this happen? On oVirt Node or somewhere else?
Anyway to make the order of the nics persistent? I added a udev rule
but when I reboot it disappears.
If it's Node then the appropriate file has to be persisted to survive a
reboot. (persist MYFILE)
Greetings
- fabian
Best regards,
Ricardo Esteves.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--=-qa/a7JVPKHEqeV0ZHmlV
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.2.3">
</HEAD>
<BODY>
<BR>
This happens on the oVirt node.<BR>
<BR>
I've added the file /etc/udev/rules.d/70-persistent-net.rules with the next
lines:<BR>
<BR>
SUBSYSTEM=="net", ACTION=="add",
DRIVERS=="?*", ATTR{address}=="d4:85:64:48:42:c0",
ATTR{type}=="1", KERNEL=="eth*",
NAME="eth0"<BR>
<BR>
SUBSYSTEM=="net", ACTION=="add",
DRIVERS=="?*", ATTR{address}=="d4:85:64:48:42:c4",
ATTR{type}=="1", KERNEL=="eth*",
NAME="eth1"<BR>
<BR>
SUBSYSTEM=="net", ACTION=="add",
DRIVERS=="?*", ATTR{address}=="1c:c1:de:7b:71:30",
ATTR{type}=="1", KERNEL=="eth*",
NAME="eth2"<BR>
<BR>
SUBSYSTEM=="net", ACTION=="add",
DRIVERS=="?*", ATTR{address}=="1c:c1:de:7b:71:32",
ATTR{type}=="1", KERNEL=="eth*",
NAME="eth3"<BR>
<BR>
<BR>
<BR>
Made it persistent using the command persist, after the reboot now the file is still there
but the order of the nics still changes <IMG
SRC="cid:1339669776.2148.29.camel@tuborg.vi.pt" ALIGN="middle"
ALT=":(" BORDER="0"><BR>
<BR>
-----Original Message-----<BR>
<B>From</B>: Fabian Deutsch <<A
HREF="mailto:Fabian%20Deutsch%20%3cfabiand@redhat.com%3e">fabiand@redhat.com</A>><BR>
<B>To</B>: Ricardo Esteves <<A
HREF="mailto:Ricardo%20Esteves%20%3cricardo.m.esteves@gmail.com%3e">ricardo.m.esteves@gmail.com</A>><BR>
<B>Cc</B>: <A
HREF="mailto:users@ovirt.org">users@ovirt.org</A><BR>
<B>Subject</B>: Re: [Users] Network interfaces order<BR>
<B>Date</B>: Thu, 14 Jun 2012 11:56:38 +0200<BR>
<BR>
<PRE>
Hi,
Am Donnerstag, den 14.06.2012, 10:53 +0100 schrieb Ricardo Esteves:
> Every time i reboot my servers, my network interfaces change order and
> i have to apply network configuration again.
Where does this happen? On oVirt Node or somewhere else?
> Anyway to make the order of the nics persistent? I added a udev rule
> but when I reboot it disappears.
If it's Node then the appropriate file has to be persisted to survive a
reboot. (persist MYFILE)
Greetings
- fabian
> Best regards,
>
> Ricardo Esteves.
>
>
> _______________________________________________
> Users mailing list
> <A HREF="mailto:Users@ovirt.org">Users@ovirt.org</A>
> <A
HREF="http://lists.ovirt.org/mailman/listinfo/users">http://...
</PRE>
</BODY>
</HTML>
--=-qa/a7JVPKHEqeV0ZHmlV--
--=-eFNoBhoJs2NJ3i64qAhY
Content-ID: <1339669776.2148.29.camel(a)tuborg.vi.pt>
Content-Disposition: attachment; filename="face-sad.png"
Content-Type: image/png; name="face-sad.png"
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAAlwSFlz
AAAN1wAADdcBQiibeAAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAAAXdEVY
dEF1dGhvcgBMYXBvIENhbGFtYW5kcmVp35EaKgAAACl0RVh0RGVzY3JpcHRpb24AQmFzZWQgb2Yg
SmFrdWIgU3RlaW5lciBkZXNpZ26ghAVzAAADRklEQVQ4jWWTW0jddQCAv9//di7q0aamnmlemGGz
uVXeKG0eKYgxCIoKetyopCAadHmMBT0ExWpQEYHIahELIgcrJJpK5shbO2woaOnyuOTojnk85/zP
//7rLYR9zx/f2yeklOxn+J2+uCrUF0OqHEARjwAQyHnbFxO+9L859cHUP/t9sT9w4e3+U5HSsvMP
dveGqurrtJKqapCSwp0ttlOb3vVr03Yhn3/9pXPTw3cFLr716I/19z+U6Bx8MizsBYSxBYYHSLB1
cGvx9aNMjV2xbi0lx4c+nT0BoACMvNk3dPDQkUT38eNhkZtmJ5ciq7go1ZWI6koolywkf4atURIn
nw43HGof+OjlziEANb77y31GOHJ58MQLEffPi2i1TYz8cAPfUGlqqwNNRwBfDt9AU8M01pRwsLlH
T/4xOzh26fOvFddzTx871hMK1sfx7iRZX/yN989NsZ7aBRkgpAQZkN4u8tp7V8mtz0Bqgsd6+0O+
751WfM9JVNY0qM7G7+C5nB9ZwPFU2ptCCGsPrCzks7Q1lpAphBi9PIlze4aaeIPqe05Cc6TaUVpR
QyGzihbTee6JZuoON9NRmyVIpxAIZL7A84NxcmYjA01zeJk1yrvjOJ7Sobme0KxsmsCyCcKCIxWb
PPy4jtguEuRDAMiiQ4XrcqbXxt328QsOrmXi+FLTikXz5q3l6z31WjlBMU9gOLjpDfJCZyXtkTMD
2uMalYaPn7cIii5o9/DX4gy2bd3ULJ/JpZXlruqSqGKYGUwpuDJrsRvEiFXVUFUe5af5TbzcDidb
A0o9GydaSnJpKbA8JsWZZw+3C5TZp1rcSJu/hhJRIGyghnX2nICiA9VRAZ6PNG0CK2DZeICv5s2i
48ou9dri1vbohU+MvzPFrgP6rh6THkjYMSX/5jx82ydvBhiui1+wWS0qfLeomHvF4MNvJ1YvCSkl
ZxMJLRVan4uqdmt/ZTraUhYQUyWqIgCJ58OeL1jLq4zdPmDuOvpKRtvoHB+X3v8vvNLZqRdimbNS
yjeayvbC8bAtaiM2AJumQcoMydVsqRUgPq6y7n33i7k5964bAZ7pbzmq4L4qEH1+IFoBVEWuSORU
gP7Z97+uJvf7/wFM+ac9EJMtXAAAAABJRU5ErkJggg==
--=-eFNoBhoJs2NJ3i64qAhY--
2:39 p.m.
--=-HyXeG6oEzzdL5KmQHhnL
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hey,
Am Donnerstag, den 14.06.2012, 11:29 +0100 schrieb Ricardo Esteves:
=20
Made it persistent using the command persist, after the reboot now the
file is still there but the order of the nics still changes :(
The problem is deep in the boot process.=20
But we've already got a bug entry for that problem:
https://bugzilla.redhat.com/show_bug.cgi?id=3D824595
Greetings
fabian
--=-HyXeG6oEzzdL5KmQHhnL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP2c1nAAoJEC9+uOgSHVGUTNMQAIMoKlbzmKoDQdvafvra+j19
w35bhomPNUQ5MFb17Ib7OBoaAtL3pApb0LERbw4jLrMM5VyOZTFNx+p+ke3yjxu8
6XrmrSbkH/iGptXiq+Iq1ycJLUy5pqKqAAkaNhvCAiSSDaiXUhCUD05hFyJpX5bO
CNsJZeB2yF+KSJBLxRLVdlF+tA9vBk7rs6Nl3t0VrfMf23ZLpe72yLe9iGLhUe1Y
7nCkrs9lzF3TvgT7w0Wh1lvP+AfQ0Ux06+bvjR1DcjcNO2mv40ArLDe3m27xBO9f
dug6HR0TUliIFPV1KCgFL/jBCn5zQFkLHrtb7rqLgUiHYYviBi8s9mGNL1J9dvr5
Err49iO7wjrF/H6Fw1g5HwtNSoTU4a4EkUKER8iqGR3mdTy6BvCZPvnaRp0xOuLn
DqHQu6nD6TglxKvbqmzgoKhwTDOu1hvzPJ+uEyc4OYphCYQP7/XtC1MyqRmJwmTp
8wTHUzN4LuUz2cehB572qfn7Et+Lyi2LJ5mgFoh0gghYBz8K3boEtkzLG6/dudnf
rFw4oobHCtFjWqd0fw/Hjy6RtCKb7qbz3Xg3kaifNm7+6gyZrj3+BAUn2scL1Q60
hoJ2cvZaJq3V4pWSTuH24Ob7Ka/F5QtEtU+MLaWAxr8ogTDACpqqmYVfKPnKF8sh
1MqXdhRFM4+jdRgZQABp
=oRvw
-----END PGP SIGNATURE-----
--=-HyXeG6oEzzdL5KmQHhnL--
5:12 p.m.
New subject: [Users] Delete Network
Hi,
I have configured 3 networks with VLANs in one of my nics (attached picture),
can someone explain me how to delete the VI and VI_WIFI network?
Best regards,
Ricardo Esteves.
5:44 p.m.
New subject: [Users] Delete Network
------=_Part_355_17101555.1342708967071
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi Ricardo,
In order to detach a network with vlan tag from the interface, you should check the
checkbox
next to the network name under the vlan column of the network you wish to detach and to
click on the "detach" button.
Any reason why not to use cluster 3.1 with the advanced UI of the Setup Networks ?
Regards,
Meni
----- Original Message -----
From: "Ricardo Esteves" <ricardo.m.esteves(a)gmail.com>
To: users(a)ovirt.org
Sent: Thursday, July 19, 2012 5:12:38 PM
Subject: [Users] Delete Network
Hi,
I have configured 3 networks with VLANs in one of my nics (attached picture),
can someone explain me how to delete the VI and VI_WIFI network?
Best regards,
Ricardo Esteves.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
------=_Part_355_17101555.1342708967071
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><style type=3D'text/css'>p { margin: 0;
}</style></head><body><=
div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo=
r: #000000'>Hi <span style=3D"font-family:
monospace;"></span>Ricardo,=
<br><br>In order to detach a network with vlan tag from the interface, you =
should check the checkbox<br>next to the network name under the vlan column=
of the network you wish to detach and to<br>click on the "detach"
button.<=
br><br>Any reason why not to use cluster 3.1 with the advanced UI of the Se=
tup Networks ? <br><br>Regards,<br>Meni<br><br><hr
id=3D"zwchr"><div style=
=3D"color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-deco=
ration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b=
From: </b>"Ricardo Esteves"
&lt;ricardo.m.esteves(a)gmail.com&gt;<br><b>To: =
</b>users(a)ovirt.org<br><b>Sent: </b>Thursday, July 19, 2012
5:12:38 PM<br><=
b>Subject: </b>[Users] Delete Network<br><br>
=20
=20
<pre>Hi,
I have configured 3 networks with VLANs in one of my nics (attached picture=
),=20
can someone explain me how to delete the VI and VI_WIFI network?
Best regards,
Ricardo Esteves.
</pre>
<br>_______________________________________________<br>Users mailing
list<b=
r>Users@ovirt.org<br>http://lists.ovirt.org/mailman/listinfo/users<br></div=
<br></div></body></html>
------=_Part_355_17101555.1342708967071--
6:39 p.m.
New subject: [Users] Delete Network
Hi,
Ok, i tried that, but for some reason the detach is allways grey.
I had 3.0 because i still had a host with 3.0, but is they are all 3.1
so i'm goint to change the cluster to 3.1.
Best regards,
Ricardo Esteves.
-----Original Message-----
From: Meni Yakvoe <myakove(a)redhat.com>
To: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>
Cc: users(a)ovirt.org
Subject: Re: [Users] Delete Network
Date: Thu, 19 Jul 2012 10:44:26 -0400 (EDT)
Hi Ricardo,
In order to detach a network with vlan tag from the interface, you
should check the checkbox
next to the network name under the vlan column of the network you wish
to detach and to
click on the "detach" button.
Any reason why not to use cluster 3.1 with the advanced UI of the Setup
Networks ?
Regards,
Meni
________________________________________________________________________
From: "Ricardo Esteves" <ricardo.m.esteves(a)gmail.com>
To: users(a)ovirt.org
Sent: Thursday, July 19, 2012 5:12:38 PM
Subject: [Users] Delete Network
Hi,
I have configured 3 networks with VLANs in one of my nics (attached picture),
can someone explain me how to delete the VI and VI_WIFI network?
Best regards,
Ricardo Esteves.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
7:30 p.m.
New subject: [Users] Increase storage domain
Hi,
I've increased the LUN i use as iSCSI storage domain on my storage, but
oVirt still sees the LUN with the old size.
How do i refresh the LUN size and how to increase the filesystem of the
storage domain?
Best regards,
Ricardo Esteves.
8:23 a.m.
New subject: [Users] Increase storage domain
Hi!
Interesting question, I would also be interested in that. LVM would be aware of the
expansion, I suppose...Did you run a pvs command for LVM to list the size? It would be
nice if LVM automatically would change the LV size...anyone knows how this works...?
Filesystem size is another thing. Filesystem's doesn't exist on the storage
domain, it is only block storage. Your filesystems only exists on your VM's. I suppose
you need to run a filesystem tool to expand that, depending on your filesystem
-----users-bounces(a)ovirt.org skrev: -----
Till: users(a)ovirt.org
Från: Ricardo Esteves
Sänt av: users-bounces(a)ovirt.org
Datum: 2012.07.30 18:33
Ärende: [Users] Increase storage domain
Hi,
I've increased the LUN i use as iSCSI storage domain on my storage, but oVirt still
sees the LUN with the old size.
How do i refresh the LUN size and how to increase the filesystem of the storage domain?
Best regards,
Ricardo Esteves.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
9:30 a.m.
New subject: [Users] Increase storage domain
----- Original Message -----
Hi!
Interesting question, I would also be interested in that. LVM would
be aware of the expansion, I suppose...Did you run a pvs command for
LVM to list the size? It would be nice if LVM automatically would
change the LV size...anyone knows how this works...?
1. You should put all hosts except the spm in maintenance.
2. pvresize the LUN on the spm host
3. if other hosts can still 'see' the LUN then you'd need to repeat [2] on
those to refresh the device map on all of them (or disconnect the iSCSI session and let
oVirt reconnect)
Filesystem size is another thing. Filesystem's doesn't exist on the
storage domain, it is only block storage. Your filesystems only
exists on your VM's. I suppose you need to run a filesystem tool to
expand that, depending on your filesystem
There is no filesystem so problem solved :)
-----users-bounces(a)ovirt.org skrev: -----
Till: users(a)ovirt.org
Från: Ricardo Esteves
Sänt av: users-bounces(a)ovirt.org
Datum: 2012.07.30 18:33
Ärende: [Users] Increase storage domain
Hi,
I've increased the LUN i use as iSCSI storage domain on my storage,
but oVirt still sees the LUN with the old size.
How do i refresh the LUN size and how to increase the filesystem of
the storage domain?
Best regards,
Ricardo Esteves.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
6:09 p.m.
New subject: [Users] Increase storage domain
Hi,
pvresize doesn't work, still same size.
How do i disconnect the iscsi session?
Between disconnecting and ovirt connect again, will i loose connection
to my VMs?
Best regards,
Ricardo Esteves.
-----Original Message-----
From: Ayal Baron <abaron(a)redhat.com>
To: Johan Kragsterman <johan.kragsterman(a)capvert.se>
Cc: users(a)ovirt.org, Ricardo Esteves <ricardo.m.esteves(a)gmail.com>
Subject: Re: [Users] Increase storage domain
Date: Tue, 31 Jul 2012 02:30:51 -0400 (EDT)
----- Original Message -----
Hi!
Interesting question, I would also be interested in that. LVM would
be aware of the expansion, I suppose...Did you run a pvs command for
LVM to list the size? It would be nice if LVM automatically would
change the LV size...anyone knows how this works...?
1. You should put all hosts except the spm in maintenance.
2. pvresize the LUN on the spm host
3. if other hosts can still 'see' the LUN then you'd need to repeat [2] on
those to refresh the device map on all of them (or disconnect the iSCSI session and let
oVirt reconnect)
Filesystem size is another thing. Filesystem's doesn't exist on the
storage domain, it is only block storage. Your filesystems only
exists on your VM's. I suppose you need to run a filesystem tool to
expand that, depending on your filesystem
There is no filesystem so problem solved :)
-----users-bounces(a)ovirt.org skrev: -----
Till: users(a)ovirt.org
Från: Ricardo Esteves
Sänt av: users-bounces(a)ovirt.org
Datum: 2012.07.30 18:33
Ärende: [Users] Increase storage domain
Hi,
I've increased the LUN i use as iSCSI storage domain on my storage,
but oVirt still sees the LUN with the old size.
How do i refresh the LUN size and how to increase the filesystem of
the storage domain?
Best regards,
Ricardo Esteves.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
12:56 a.m.
New subject: [Users] Increase storage domain
----- Original Message -----
Hi,
pvresize doesn't work, still same size.
How do i disconnect the iscsi session?
Between disconnecting and ovirt connect again, will i loose
connection to my VMs?
Of course you would. Your VMs would automatically pause.
I doubt this is what you want.
What you can do prior to running pvresize is run:
iscsiadm -m session -R
Hope this helps.
Best regards,
Ricardo Esteves.
-----Original Message-----
From : Ayal Baron < abaron(a)redhat.com >
To : Johan Kragsterman < johan.kragsterman(a)capvert.se >
Cc : users(a)ovirt.org , Ricardo Esteves < ricardo.m.esteves(a)gmail.com
>
Subject : Re: [Users] Increase storage domain
Date : Tue, 31 Jul 2012 02:30:51 -0400 (EDT)
----- Original Message -----
> Hi!
>
> Interesting question, I would also be interested in that. LVM would
> be aware of the expansion, I suppose...Did you run a pvs command
> for
> LVM to list the size? It would be nice if LVM automatically would
> change the LV size...anyone knows how this works...?
1. You should put all hosts except the spm in maintenance.
2. pvresize the LUN on the spm host
3. if other hosts can still 'see' the LUN then you'd need to repeat
[2] on those to refresh the device map on all of them (or disconnect
the iSCSI session and let oVirt reconnect)
>
> Filesystem size is another thing. Filesystem's doesn't exist on the
> storage domain, it is only block storage. Your filesystems only
> exists on your VM's. I suppose you need to run a filesystem tool to
> expand that, depending on your filesystem
There is no filesystem so problem solved :)
>
> -----users-bounces(a)ovirt.org skrev: -----
> Till: users(a)ovirt.org > Från: Ricardo Esteves
> Sänt av: users-bounces(a)ovirt.org > Datum: 2012.07.30 18:33
> Ärende: [Users] Increase storage domain
>
> Hi,
>
> I've increased the LUN i use as iSCSI storage domain on my
> storage,
> but oVirt still sees the LUN with the old size.
>
> How do i refresh the LUN size and how to increase the filesystem
> of
> the storage domain?
>
> Best regards,
> Ricardo Esteves.
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >
6:47 p.m.
New subject: [Users] Increase storage domain
On Sat, Aug 11, 2012 at 5:56 PM, Ayal Baron <abaron(a)redhat.com> wrote:
----- Original Message -----
> Hi,
>
> pvresize doesn't work, still same size.
>
> How do i disconnect the iscsi session?
>
> Between disconnecting and ovirt connect again, will i loose
> connection to my VMs?
Of course you would. Your VMs would automatically pause.
I doubt this is what you want.
What you can do prior to running pvresize is run:
iscsiadm -m session -R
Hope this helps.
Did anyone have any success with this? I was unable to get pvdisplay to
show the new size until I rebooted the hosts and ran pvresize. I started
with a 1TiB volume on our Equallogics SAN and set it to 5TiB. I put my
non-SPM host into maintenance and ran pvresize on the SPM. I did not
expect this to work because of previous experience and this thread.
pvresize said it resized, but pvdisplay showed 1023GiB instead of 1TB, so
it shrunk it a tiny bit?
Next, I tried `iscsiadm -m session -R` and then pvresize which said it
resized 0 PVs and pvdisplay confirms no change. I did a `iscsiadm -m node
-T <iqn> -u` then `iscsiadm -m node -T <iqn> -l` followed by pvdisplay.
pvdisplay spewed an IO error message for the PV and each LV and I noticed
that the device had changed from /dev/mapper/<UUID> to /dev/sdf, which
explains why it thought the PV and all the other LVs were missing. I
should have deactivated the LVs/VG/PV first I supposed, and then
reactivated them afterwords.
Anyway, this gave me pause, but I'm still pre-production, so I went ahead
and did a pvresize, which did nothing,and pvdisplay gave the same output,
including errors, as before. So, I rebooted the host, activated the host,
ran pvresize on the host, and all is as desired.
I then rebooted my other host and all was well when it came up. I can deal
with rebooting each host if necessary, but it is certainly not ideal. Has
anyone worked out the correct steps make this happen without rebooting the
hosts and minimal VM interruption? I might try it a couple more times if
not.
The bigger question is, how do I get the engine to see the new size? It is
still seeing 1TB. Stopping and starting (why no restart on
/etc/init.d/ovirt-engine?) did not cause a refresh. Oop! There it went,
just as I was typing this, I saw it change in the window behind this one.
So, was it just a cache time out, or did I need to restart the engine as
well?
An ideal setup would be for the engine to detect the change and run the
necessary commands on each host. If auto detection is not reasonable, an
option in the GUI to tell the engine the LUN has changed would be nearly as
good.
Alternately, would it just be better to create a new LUN on the iSCSI
target and add it to the storage domain? Is that even doable? Certainly
it is as simple as adding a new PV to the VG in LVM, but does the
engine/GUI support it? It seems a bit more messy than growing an existing
domain from an iSCSI target point of view, but are there any technical down
sides?
Eventually, I think I'll look into filing a feature request, so I would
appreciate if some one could point me in the right direction, but let's
hash out what makes sense here before doing that.
1:12 a.m.
New subject: [Users] Increase storage domain
----- Original Message -----
On Sat, Aug 11, 2012 at 5:56 PM, Ayal Baron < abaron(a)redhat.com >
wrote:
----- Original Message -----
> Hi,
>
> pvresize doesn't work, still same size.
>
> How do i disconnect the iscsi session?
>
> Between disconnecting and ovirt connect again, will i loose
> connection to my VMs?
Of course you would. Your VMs would automatically pause.
I doubt this is what you want.
What you can do prior to running pvresize is run:
iscsiadm -m session -R
Hope this helps.
Did anyone have any success with this? I was unable to get pvdisplay
to show the new size until I rebooted the hosts and ran pvresize. I
started with a 1TiB volume on our Equallogics SAN and set it to
5TiB. I put my non-SPM host into maintenance and ran pvresize on the
SPM. I did not expect this to work because of previous experience
and this thread. pvresize said it resized, but pvdisplay showed
1023GiB instead of 1TB, so it shrunk it a tiny bit?
Next, I tried `iscsiadm -m session -R` and then pvresize which said
it resized 0 PVs and pvdisplay confirms no change. I did a `iscsiadm
-m node -T <iqn> -u` then `iscsiadm -m node -T <iqn> -l` followed by
pvdisplay. pvdisplay spewed an IO error message for the PV and each
LV and I noticed that the device had changed from /dev/mapper/<UUID>
to /dev/sdf, which explains why it thought the PV and all the other
LVs were missing. I should have deactivated the LVs/VG/PV first I
supposed, and then reactivated them afterwords.
Anyway, this gave me pause, but I'm still pre-production, so I went
ahead and did a pvresize, which did nothing,and pvdisplay gave the
same output, including errors, as before. So, I rebooted the host,
activated the host, ran pvresize on the host, and all is as desired.
I then rebooted my other host and all was well when it came up. I can
deal with rebooting each host if necessary, but it is certainly not
ideal. Has anyone worked out the correct steps make this happen
without rebooting the hosts and minimal VM interruption? I might try
it a couple more times if not.
Sounds really over-complicated for what you're trying to do.
After increasing the size of the LUN in the storage side try running the following command
on the SPM:
vdsClient -s 0 getDeviceList
(-s is only if ssl is enabled, otherwise just remove it)
After that run pvresize (for LVM to update its metadata).
That should be it on the SPM side.
Then if indeed it succeeds, wait a little while for engine to catch up (it periodically
runs getStoragePoolInfo and updates its info about free space, you can find this in
vdsm.log)
regardless, see below for the preferred method.
The bigger question is, how do I get the engine to see the new size?
It is still seeing 1TB. Stopping and starting (why no restart on
/etc/init.d/ovirt-engine?) did not cause a refresh. Oop! There it
went, just as I was typing this, I saw it change in the window
behind this one. So, was it just a cache time out, or did I need to
restart the engine as well?
An ideal setup would be for the engine to detect the change and run
the necessary commands on each host. If auto detection is not
reasonable, an option in the GUI to tell the engine the LUN has
changed would be nearly as good.
Alternately, would it just be better to create a new LUN on the iSCSI
target and add it to the storage domain? Is that even doable?
This flow is fully supported and is currently the easiest way of doing this (supported
from the GUI and from the CLI).
Simply extend a domain with a new LUN
Certainly it is as simple as adding a new PV to the VG in LVM, but
does the engine/GUI support it? It seems a bit more messy than
growing an existing domain from an iSCSI target point of view, but
are there any technical down sides?
The target has nothing to do with it, you can have multiple LUNs behind the same target.
Eventually, I think I'll look into filing a feature request, so I
would appreciate if some one could point me in the right direction,
but let's hash out what makes sense here before doing that.
5:26 p.m.
New subject: [Users] Increase storage domain
On Wed, Sep 26, 2012 at 6:12 PM, Ayal Baron <abaron(a)redhat.com> wrote:
Sounds really over-complicated for what you're trying to do.
Agreed! That's why I asked. =) To be clear, all that was necessary to end
up where I wanted was to reboot the hosts, which is not terribly
complicated, but time consuming and should not be necessary. I tired all
those other steps based on recommendations in this thread to avoid the
reboot.
After increasing the size of the LUN in the storage side try running
the
following command on the SPM:
vdsClient -s 0 getDeviceList
(-s is only if ssl is enabled, otherwise just remove it)
After that run pvresize (for LVM to update its metadata).
That should be it on the SPM side.
This did not make any difference. I increased the LUN to 14.1 on the
Equallogics box and then ran these commands (you may want to skip past this
to the text below since I am leaning heavily toward the add a LUN method):
[root@cloudhost04 ~]# pvdisplay
--- Physical volume ---
PV Name /dev/mapper/364ed2a35d83f5d68b705e54229020027
VG Name 64c4a870-98dc-40fc-b21e-092156febcdc
PV Size 14.00 TiB / not usable 129.00 MiB
Allocatable yes
PE Size 128.00 MiB
Total PE 114686
Free PE 111983
Allocated PE 2703
PV UUID h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO
[root@cloudhost04 ~]# vdsClient -s 0 getDeviceList
[{'GUID': '364ed2a35d83f5d68b705e54229020027',
'capacity': '15393163837440',
'devtype': 'iSCSI',
'fwrev': '5.2',
'logicalblocksize': '512',
'partitioned': False,
'pathlist': [{'connection': '10.10.5.18',
'initiatorname': 'default',
'iqn':
'iqn.2001-05.com.equallogic:4-52aed6-685d3fd83-2700022942e505b7-cloud2',
'port': '3260',
'portal': '1'}],
'pathstatus': [{'lun': '0',
'physdev': 'sdd',
'state': 'active',
'type': 'iSCSI'}],
'physicalblocksize': '512',
'productID': '100E-00',
'pvUUID': 'h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO',
'serial': '',
'vendorID': 'EQLOGIC',
'vgUUID': 'XtdGHH-5WwC-oWRa-bv0V-me7t-T6ti-M9WKd2'}]
[root@cloudhost04 ~]# pvdisplay
--- Physical volume ---
PV Name /dev/mapper/364ed2a35d83f5d68b705e54229020027
VG Name 64c4a870-98dc-40fc-b21e-092156febcdc
PV Size 14.00 TiB / not usable 129.00 MiB
Allocatable yes
PE Size 128.00 MiB
Total PE 114686
Free PE 111983
Allocated PE 2703
PV UUID h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO
[root@cloudhost04 ~]# pvresize /dev/mapper/364ed2a35d83f5d68b705e54229020027
Physical volume "/dev/mapper/364ed2a35d83f5d68b705e54229020027" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
[root@cloudhost04 ~]# pvdisplay
--- Physical volume ---
PV Name /dev/mapper/364ed2a35d83f5d68b705e54229020027
VG Name 64c4a870-98dc-40fc-b21e-092156febcdc
PV Size 14.00 TiB / not usable 129.00 MiB
Allocatable yes
PE Size 128.00 MiB
Total PE 114686
Free PE 111983
Allocated PE 2703
PV UUID h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO
So, not change.
Then if indeed it succeeds, wait a little while for engine to catch
up (it
periodically runs getStoragePoolInfo and updates its info about free space,
you can find this in vdsm.log)
regardless, see below for the preferred method.
Thanks for the confirmation. Any idea what the interval is?
Alternately, would it just be better to create a new LUN on the
iSCSI
> target and add it to the storage domain? Is that even doable?
This flow is fully supported and is currently the easiest way of doing
this (supported from the GUI and from the CLI). Simply extend a domain with
a new LUN
Great! I'll give that a shot.
> Certainly it is as simple as adding a new PV to the VG in LVM, but
> does the engine/GUI support it? It seems a bit more messy than
> growing an existing domain from an iSCSI target point of view, but
> are there any technical down sides?
The target has nothing to do with it, you can have multiple LUNs behind
the same target.
The target serves the LUNs and it was the additional LUNs that I
was referring to as being messier when a single LUN could do the job. Not
a big problem, just name the LUNs the same the same patters (cloud<#> in my
case), but when all other things are equal, less LUNs is less to think
about.
However, as I read this email, it occurred that some other things might not
be equal. Specifically, using multiple LUNs could provide a means of
shrinking the storage domain in the future. LVM provides a simple means to
remove a PV from a VG, but does the engine support this in the CLI or GUI?
That is, if the a storage domain has multiple LUNs in it, can those be
removed at a later date?
6:08 p.m.
New subject: [Users] Increase storage domain
----- Original Message -----
On Wed, Sep 26, 2012 at 6:12 PM, Ayal Baron < abaron(a)redhat.com >
wrote:
Sounds really over-complicated for what you're trying to do.
Agreed! That's why I asked. =) To be clear, all that was necessary to
end up where I wanted was to reboot the hosts, which is not terribly
complicated, but time consuming and should not be necessary. I tired
all those other steps based on recommendations in this thread to
avoid the reboot.
After increasing the size of the LUN in the storage side try running
the following command on the SPM:
vdsClient -s 0 getDeviceList
(-s is only if ssl is enabled, otherwise just remove it)
After that run pvresize (for LVM to update its metadata).
That should be it on the SPM side.
This did not make any difference. I increased the LUN to 14.1 on the
Equallogics box and then ran these commands (you may want to skip
past this to the text below since I am leaning heavily toward the
add a LUN method):
[root@cloudhost04 ~]# pvdisplay
--- Physical volume ---
PV Name /dev/mapper/364ed2a35d83f5d68b705e54229020027
VG Name 64c4a870-98dc-40fc-b21e-092156febcdc
PV Size 14.00 TiB / not usable 129.00 MiB
Allocatable yes
PE Size 128.00 MiB
Total PE 114686
Free PE 111983
Allocated PE 2703
PV UUID h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO
[root@cloudhost04 ~]# vdsClient -s 0 getDeviceList
[{'GUID': '364ed2a35d83f5d68b705e54229020027',
'capacity': '15393163837440',
'devtype': 'iSCSI',
'fwrev': '5.2',
'logicalblocksize': '512',
'partitioned': False,
'pathlist': [{'connection': '10.10.5.18',
'initiatorname': 'default',
'iqn':
'iqn.2001-05.com.equallogic:4-52aed6-685d3fd83-2700022942e505b7-cloud2',
'port': '3260',
'portal': '1'}],
'pathstatus': [{'lun': '0',
'physdev': 'sdd',
'state': 'active',
'type': 'iSCSI'}],
'physicalblocksize': '512',
'productID': '100E-00',
'pvUUID': 'h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO',
'serial': '',
'vendorID': 'EQLOGIC',
'vgUUID': 'XtdGHH-5WwC-oWRa-bv0V-me7t-T6ti-M9WKd2'}]
[root@cloudhost04 ~]# pvdisplay
--- Physical volume ---
PV Name /dev/mapper/364ed2a35d83f5d68b705e54229020027
VG Name 64c4a870-98dc-40fc-b21e-092156febcdc
PV Size 14.00 TiB / not usable 129.00 MiB
Allocatable yes
PE Size 128.00 MiB
Total PE 114686
Free PE 111983
Allocated PE 2703
PV UUID h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO
[root@cloudhost04 ~]# pvresize
/dev/mapper/364ed2a35d83f5d68b705e54229020027
Physical volume "/dev/mapper/364ed2a35d83f5d68b705e54229020027"
changed
1 physical volume(s) resized / 0 physical volume(s) not resized
[root@cloudhost04 ~]# pvdisplay
--- Physical volume ---
PV Name /dev/mapper/364ed2a35d83f5d68b705e54229020027
VG Name 64c4a870-98dc-40fc-b21e-092156febcdc
PV Size 14.00 TiB / not usable 129.00 MiB
Allocatable yes
PE Size 128.00 MiB
Total PE 114686
Free PE 111983
Allocated PE 2703
PV UUID h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO
So, not change.
This looks like an LVM issue. Have you tried deactivating the VG before pvresize?
Then if indeed it succeeds, wait a little while for engine to catch
up (it periodically runs getStoragePoolInfo and updates its info
about free space, you can find this in vdsm.log)
regardless, see below for the preferred method.
Thanks for the confirmation. Any idea what the interval is?
> Alternately, would it just be better to create a new LUN on the
> iSCSI
> target and add it to the storage domain? Is that even doable?
This flow is fully supported and is currently the easiest way of
doing this (supported from the GUI and from the CLI). Simply extend
a domain with a new LUN
Great! I'll give that a shot.
> Certainly it is as simple as adding a new PV to the VG in LVM, but
> does the engine/GUI support it? It seems a bit more messy than
> growing an existing domain from an iSCSI target point of view, but
> are there any technical down sides?
The target has nothing to do with it, you can have multiple LUNs
behind the same target.
The target serves the LUNs and it was the additional LUNs that I was
referring to as being messier when a single LUN could do the job.
Not a big problem, just name the LUNs the same the same patters
(cloud<#> in my case), but when all other things are equal, less
LUNs is less to think about.
However, as I read this email, it occurred that some other things
might not be equal. Specifically, using multiple LUNs could provide
a means of shrinking the storage domain in the future. LVM provides
a simple means to remove a PV from a VG, but does the engine support
this in the CLI or GUI? That is, if the a storage domain has
multiple LUNs in it, can those be removed at a later date?
Not yet.
7:27 p.m.
New subject: [Users] Increase storage domain
On Thu, Sep 27, 2012 at 11:08 AM, Ayal Baron <abaron(a)redhat.com> wrote:
> Alan Johnson < alan(a)datdec.com > meant to write:
> So, no change.
This looks like an LVM issue. Have you tried deactivating the VG before
pvresize?
I have not, but I don't think I'll bother playing with that any more since
there is a more accepted way of growing that has no significant down side
and leaves open the potential for more functionality. Good to know that I
should not have to make the change.
I should mention that the host is running is a minimal install of CentOS
6.3, updated, and then tweaked by oVirt. Perhaps there is some other
package that enables this functionality?
> However, as I read this email, it occurred that some other
things
> might not be equal. Specifically, using multiple LUNs could provide
> a means of shrinking the storage domain in the future. LVM provides
> a simple means to remove a PV from a VG, but does the engine support
> this in the CLI or GUI? That is, if the a storage domain has
> multiple LUNs in it, can those be removed at a later date?
Not yet.
Does this mean it is in the works? If not, where could I put in such
feature request?
Certainly, I have no pressing need of this, but it seems like a fairly
simple thing to implement since I have done it so easily in the past with a
just a couple of commands outside of an oVirt environment. I believe the
primary purpose of the LVM functionality was to enable removal of dying PVs
before they take out an entire VG. No reason it would not work just as
well to remove a healthy PV. It can take a long time to move all the
extents off the PV requested, but there is command to show the progress, so
it would also be easy to wrap that in to the GUI.
10:47 p.m.
New subject: [Users] Increase storage domain
----- Original Message -----
On Thu, Sep 27, 2012 at 11:08 AM, Ayal Baron < abaron(a)redhat.com
>
wrote:
> Alan Johnson < alan(a)datdec.com > meant to write:
> So, no change.
This looks like an LVM issue. Have you tried deactivating the VG
before pvresize?
I have not, but I don't think I'll bother playing with that any more
since there is a more accepted way of growing that has no
significant down side and leaves open the potential for more
functionality. Good to know that I should not have to make the
change.
I should mention that the host is running is a minimal install of
CentOS 6.3, updated, and then tweaked by oVirt. Perhaps there is
some other package that enables this functionality?
no there isn't. LVM should work fine.
> However, as I read this email, it occurred that some other things
> might not be equal. Specifically, using multiple LUNs could provide
> a means of shrinking the storage domain in the future. LVM provides
> a simple means to remove a PV from a VG, but does the engine
> support
> this in the CLI or GUI? That is, if the a storage domain has
> multiple LUNs in it, can those be removed at a later date?
Not yet.
Does this mean it is in the works? If not, where could I put in such
feature request?
Certainly, I have no pressing need of this, but it seems like a
fairly simple thing to implement since I have done it so easily in
the past with a just a couple of commands outside of an oVirt
environment. I believe the primary purpose of the LVM functionality
was to enable removal of dying PVs before they take out an entire
VG. No reason it would not work just as well to remove a healthy PV.
It can take a long time to move all the extents off the PV
requested, but there is command to show the progress, so it would
also be easy to wrap that in to the GUI.
What's simple in a single host environment is really not that simple when it comes to
clusters.
The tricky part is the coordination between the different hosts and doing it live or with
minimal impact.
10:55 p.m.
New subject: [Users] Increase storage domain
On Sat, Sep 29, 2012 at 3:47 PM, Ayal Baron <abaron(a)redhat.com> wrote:
> > However, as I read this email, it occurred that some other
things
> > might not be equal. Specifically, using multiple LUNs could provide
> > a means of shrinking the storage domain in the future. LVM provides
> > a simple means to remove a PV from a VG, but does the engine
> > support
> > this in the CLI or GUI? That is, if the a storage domain has
> > multiple LUNs in it, can those be removed at a later date?
>
> Not yet.
>
>
> Does this mean it is in the works? If not, where could I put in such
> feature request?
>
>
> Certainly, I have no pressing need of this, but it seems like a
> fairly simple thing to implement since I have done it so easily in
> the past with a just a couple of commands outside of an oVirt
> environment. I believe the primary purpose of the LVM functionality
> was to enable removal of dying PVs before they take out an entire
> VG. No reason it would not work just as well to remove a healthy PV.
> It can take a long time to move all the extents off the PV
> requested, but there is command to show the progress, so it would
> also be easy to wrap that in to the GUI.
What's simple in a single host environment is really not that simple when
it comes to clusters.
The tricky part is the coordination between the different hosts and doing
it live or with minimal impact.
Fair enough, but it seems that the cluster environment has been addressed
with the SPM mechanism for all things LVM. Certainly, initial coding the
feature would be fairly trivial, but I can imagine that testing in the
cluster environment might expose additional complexity.
12:35 a.m.
New subject: [Users] Increase storage domain
----- Original Message -----
On Sat, Sep 29, 2012 at 3:47 PM, Ayal Baron < abaron(a)redhat.com
>
wrote:
> > However, as I read this email, it occurred that some other things
> > might not be equal. Specifically, using multiple LUNs could
> > provide
> > a means of shrinking the storage domain in the future. LVM
> > provides
> > a simple means to remove a PV from a VG, but does the engine
> > support
> > this in the CLI or GUI? That is, if the a storage domain has
> > multiple LUNs in it, can those be removed at a later date?
>
> Not yet.
>
>
> Does this mean it is in the works? If not, where could I put in
> such
> feature request?
>
>
> Certainly, I have no pressing need of this, but it seems like a
> fairly simple thing to implement since I have done it so easily in
> the past with a just a couple of commands outside of an oVirt
> environment. I believe the primary purpose of the LVM functionality
> was to enable removal of dying PVs before they take out an entire
> VG. No reason it would not work just as well to remove a healthy
> PV.
> It can take a long time to move all the extents off the PV
> requested, but there is command to show the progress, so it would
> also be easy to wrap that in to the GUI.
What's simple in a single host environment is really not that simple
when it comes to clusters.
The tricky part is the coordination between the different hosts and
doing it live or with minimal impact.
Fair enough, but it seems that the cluster environment has been
addressed with the SPM mechanism for all things LVM. Certainly,
initial coding the feature would be fairly trivial, but I can
imagine that testing in the cluster environment might expose
additional complexity.
The actual data move is done by the SPM and is a simple pvmove command as you've
stated.
The simple way of doing this would be to put the domain in maintenance mode and then
pvmove on the SPM (currently you can't run such operations while domain is in
maintenance, but it just makes sense to do it) and then activate the domain.
This means however that you would not be able to run any VM that has disks on this VG,
even ones that reside entirely on other PVs.
If, however, we'd want to do it 'semi live' then it would become much more
complex.
First you need to realize that LVs are not neatly dispersed between PVs. You can have
extents from different PVs for the same LV (esp. after lvextend which happens
automatically in the system when there are snapshots).
So we'd need to map all the LVs which are affected and prevent running any VM that
uses these LVs.
Then we'd need to also guarantee there is enough space to move these extents to
(again, in addition to user creating new objects, there are automatic lvextend operations
going on so we'd need a way to reserve space on the VG for this operation).
Once we've done this we'd need to run the op and then we'd need to make sure
that all the hosts see things properly.
12:57 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Hi,
With the latest version of ovirt my host's CPU is not correctly identified,
my host's have an Intel Xeon E5530 (Nehalem family), but is being identified as Conrad
family.
My installed versions:
ovirt-engine-3.1.0-2.fc17.noarch
ovirt-node-iso-2.5.0-2.0.fc17.iso
Best regards,
Ricardo Esteves.
1:59 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
On 08/01/2012 12:57 PM, Ricardo Esteves wrote:
Hi,
With the latest version of ovirt my host's CPU is not correctly identified,
my host's have an Intel Xeon E5530 (Nehalem family), but is being identified as
Conrad family.
My installed versions:
ovirt-engine-3.1.0-2.fc17.noarch
ovirt-node-iso-2.5.0-2.0.fc17.iso
Best regards,
Ricardo Esteves.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
please share:
vdsClient -s 0 getVdsCaps | grep -i flags
2:28 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
[root@blade4 ~]# vdsClient -s 0 getVdsCaps | grep -i flags
Traceback (most recent call last):
File "/usr/share/vdsm/vdsClient.py", line 2275, in <module>
File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders
File "/usr/lib64/python2.7/httplib.py", line 814, in _send_output
File "/usr/lib64/python2.7/httplib.py", line 776, in send
File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
line 98, in connect
File "/usr/lib64/python2.7/ssl.py", line 381, in wrap_socket
File "/usr/lib64/python2.7/ssl.py", line 141, in __init__
SSLError: [Errno 0] _ssl.c:340: error:00000000:lib(0):func(0):reason(0)
-----Original Message-----
From: Itamar Heim <iheim(a)redhat.com>
To: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>
Cc: users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Wed, 01 Aug 2012 13:59:27 +0300
On 08/01/2012 12:57 PM, Ricardo Esteves wrote:
Hi,
With the latest version of ovirt my host's CPU is not correctly identified,
my host's have an Intel Xeon E5530 (Nehalem family), but is being identified as
Conrad family.
My installed versions:
ovirt-engine-3.1.0-2.fc17.noarch
ovirt-node-iso-2.5.0-2.0.fc17.iso
Best regards,
Ricardo Esteves.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
please share:
vdsClient -s 0 getVdsCaps | grep -i flags
3:43 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
On 08/01/2012 02:28 PM, Ricardo Esteves wrote:
[root@blade4 <mailto:root@blade4> ~]# vdsClient -s 0 getVdsCaps | grep
-i flags
Traceback (most recent call last):
File "/usr/share/vdsm/vdsClient.py", line 2275, in <module>
File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders
File "/usr/lib64/python2.7/httplib.py", line 814, in _send_output
File "/usr/lib64/python2.7/httplib.py", line 776, in send
File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
line 98, in connect
File "/usr/lib64/python2.7/ssl.py", line 381, in wrap_socket
File "/usr/lib64/python2.7/ssl.py", line 141, in __init__
SSLError: [Errno 0] _ssl.c:340: error:00000000:lib(0):func(0):reason(0)
did you somehow disable ssl?
is vdsm running?
what's its status in engine?
what does this return:
virsh capabilities | grep model
-----Original Message-----
*From*: Itamar Heim <iheim(a)redhat.com
<mailto:Itamar%20Heim%20%3ciheim@redhat.com%3e>>
*To*: Ricardo Esteves <ricardo.m.esteves(a)gmail.com
<mailto:Ricardo%20Esteves%20%3cricardo.m.esteves@gmail.com%3e>>
*Cc*: users(a)ovirt.org <mailto:users@ovirt.org>
*Subject*: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
*Date*: Wed, 01 Aug 2012 13:59:27 +0300
On 08/01/2012 12:57 PM, Ricardo Esteves wrote:
> Hi,
>
> With the latest version of ovirt my host's CPU is not correctly identified,
> my host's have an Intel Xeon E5530 (Nehalem family), but is being identified as
Conrad family.
>
> My installed versions:
>
> ovirt-engine-3.1.0-2.fc17.noarch
> ovirt-node-iso-2.5.0-2.0.fc17.iso
>
>
> Best regards,
> Ricardo Esteves.
>
>
>
> _______________________________________________
> Users mailing list
>Users(a)ovirt.org <mailto:Users@ovirt.org>
>http://lists.ovirt.org/mailman/listinfo/users
>
please share:
vdsClient -s 0 getVdsCaps | grep -i flags
6:52 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
I didn't disabled anything, but after installing the node when i
configure the option "oVirt Engine" it gives an error saying it can't
download the certificate, but i had this error with previous versions of
the node, and it detected ok the CPU family.
This is the output after a fresh install of the node:
[root@blade4 ~]# vdsClient -s 0 getVdsCaps | grep -i flags
Traceback (most recent call last):
File "/usr/share/vdsm/vdsClient.py", line 2275, in <module>
File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders
File "/usr/lib64/python2.7/httplib.py", line 814, in _send_output
File "/usr/lib64/python2.7/httplib.py", line 776, in send
File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
line 91, in connect
File "/usr/lib64/python2.7/socket.py", line 553, in create_connection
gaierror: [Errno -2] Name or service not known
[root@blade4 ~]# virsh capabilities
<capabilities>
<host>
<uuid>35303737-3830-435a-4a30-30333035455a</uuid>
<cpu>
<arch>x86_64</arch>
<model>Nehalem</model>
<vendor>Intel</vendor>
<topology sockets='1' cores='4' threads='2'/>
<feature name='rdtscp'/>
<feature name='dca'/>
<feature name='pdcm'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/>
<feature name='ds_cpl'/>
<feature name='monitor'/>
<feature name='dtes64'/>
<feature name='pbe'/>
<feature name='tm'/>
<feature name='ht'/>
<feature name='ss'/>
<feature name='acpi'/>
<feature name='ds'/>
<feature name='vme'/>
</cpu>
<power_management/>
<migration_features>
<live/>
<uri_transports>
<uri_transport>tcp</uri_transport>
</uri_transports>
</migration_features>
<topology>
<cells num='1'>
<cell id='0'>
<cpus num='8'>
<cpu id='0'/>
<cpu id='1'/>
<cpu id='2'/>
<cpu id='3'/>
<cpu id='4'/>
<cpu id='5'/>
<cpu id='6'/>
<cpu id='7'/>
</cpus>
</cell>
</cells>
</topology>
<secmodel>
<model>selinux</model>
<doi>0</doi>
</secmodel>
</host>
<guest>
<os_type>hvm</os_type>
<arch name='i686'>
<wordsize>32</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<pae/>
<nonpae/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
<guest>
<os_type>hvm</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
</capabilities>
When i add the host to oVirt i get this message:
Host blade4.vi.pt moved to Non-Operational state as host does not meet
the cluster's minimum CPU level. Missing CPU features : model_Nehalem
Best regards,
Ricardo Esteves.
-----Original Message-----
From: Itamar Heim <iheim(a)redhat.com>
To: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>
Cc: users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Wed, 01 Aug 2012 15:43:22 +0300
On 08/01/2012 02:28 PM, Ricardo Esteves wrote:
[root@blade4 <mailto:root@blade4> ~]# vdsClient -s 0 getVdsCaps | grep
-i flags
Traceback (most recent call last):
File "/usr/share/vdsm/vdsClient.py", line 2275, in <module>
File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders
File "/usr/lib64/python2.7/httplib.py", line 814, in _send_output
File "/usr/lib64/python2.7/httplib.py", line 776, in send
File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
line 98, in connect
File "/usr/lib64/python2.7/ssl.py", line 381, in wrap_socket
File "/usr/lib64/python2.7/ssl.py", line 141, in __init__
SSLError: [Errno 0] _ssl.c:340: error:00000000:lib(0):func(0):reason(0)
did you somehow disable ssl?
is vdsm running?
what's its status in engine?
what does this return:
virsh capabilities | grep model
-----Original Message-----
*From*: Itamar Heim <iheim(a)redhat.com
<mailto:Itamar%20Heim%20%3ciheim@redhat.com%3e>>
*To*: Ricardo Esteves <ricardo.m.esteves(a)gmail.com
<mailto:Ricardo%20Esteves%20%3cricardo.m.esteves@gmail.com%3e>>
*Cc*: users(a)ovirt.org <mailto:users@ovirt.org>
*Subject*: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
*Date*: Wed, 01 Aug 2012 13:59:27 +0300
On 08/01/2012 12:57 PM, Ricardo Esteves wrote:
> Hi,
>
> With the latest version of ovirt my host's CPU is not correctly identified,
> my host's have an Intel Xeon E5530 (Nehalem family), but is being identified as
Conrad family.
>
> My installed versions:
>
> ovirt-engine-3.1.0-2.fc17.noarch
> ovirt-node-iso-2.5.0-2.0.fc17.iso
>
>
> Best regards,
> Ricardo Esteves.
>
>
>
> _______________________________________________
> Users mailing list
>Users(a)ovirt.org <mailto:Users@ovirt.org>
>http://lists.ovirt.org/mailman/listinfo/users
>
please share:
vdsClient -s 0 getVdsCaps | grep -i flags
7:29 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
And now, after reboot of the node, i get this:
[root@blade4 ~]# virsh capabilities
Segmentation fault
-----Original Message-----
From: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>
To: Itamar Heim <iheim(a)redhat.com>
Cc: users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Wed, 01 Aug 2012 16:52:11 +0100
I didn't disabled anything, but after installing the node when i
configure the option "oVirt Engine" it gives an error saying it can't
download the certificate, but i had this error with previous versions of
the node, and it detected ok the CPU family.
This is the output after a fresh install of the node:
[root@blade4 ~]# vdsClient -s 0 getVdsCaps | grep -i flags
Traceback (most recent call last):
File "/usr/share/vdsm/vdsClient.py", line 2275, in <module>
File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders
File "/usr/lib64/python2.7/httplib.py", line 814, in _send_output
File "/usr/lib64/python2.7/httplib.py", line 776, in send
File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
line 91, in connect
File "/usr/lib64/python2.7/socket.py", line 553, in create_connection
gaierror: [Errno -2] Name or service not known
[root@blade4 ~]# virsh capabilities
<capabilities>
<host>
<uuid>35303737-3830-435a-4a30-30333035455a</uuid>
<cpu>
<arch>x86_64</arch>
<model>Nehalem</model>
<vendor>Intel</vendor>
<topology sockets='1' cores='4' threads='2'/>
<feature name='rdtscp'/>
<feature name='dca'/>
<feature name='pdcm'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/>
<feature name='ds_cpl'/>
<feature name='monitor'/>
<feature name='dtes64'/>
<feature name='pbe'/>
<feature name='tm'/>
<feature name='ht'/>
<feature name='ss'/>
<feature name='acpi'/>
<feature name='ds'/>
<feature name='vme'/>
</cpu>
<power_management/>
<migration_features>
<live/>
<uri_transports>
<uri_transport>tcp</uri_transport>
</uri_transports>
</migration_features>
<topology>
<cells num='1'>
<cell id='0'>
<cpus num='8'>
<cpu id='0'/>
<cpu id='1'/>
<cpu id='2'/>
<cpu id='3'/>
<cpu id='4'/>
<cpu id='5'/>
<cpu id='6'/>
<cpu id='7'/>
</cpus>
</cell>
</cells>
</topology>
<secmodel>
<model>selinux</model>
<doi>0</doi>
</secmodel>
</host>
<guest>
<os_type>hvm</os_type>
<arch name='i686'>
<wordsize>32</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<pae/>
<nonpae/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
<guest>
<os_type>hvm</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
</capabilities>
When i add the host to oVirt i get this message:
Host blade4.vi.pt moved to Non-Operational state as host does not meet
the cluster's minimum CPU level. Missing CPU features : model_Nehalem
Best regards,
Ricardo Esteves.
-----Original Message-----
From: Itamar Heim <iheim(a)redhat.com>
To: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>
Cc: users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Wed, 01 Aug 2012 15:43:22 +0300
On 08/01/2012 02:28 PM, Ricardo Esteves wrote:
[root@blade4 <mailto:root@blade4> ~]# vdsClient -s 0 getVdsCaps | grep
-i flags
Traceback (most recent call last):
File "/usr/share/vdsm/vdsClient.py", line 2275, in <module>
File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders
File "/usr/lib64/python2.7/httplib.py", line 814, in _send_output
File "/usr/lib64/python2.7/httplib.py", line 776, in send
File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
line 98, in connect
File "/usr/lib64/python2.7/ssl.py", line 381, in wrap_socket
File "/usr/lib64/python2.7/ssl.py", line 141, in __init__
SSLError: [Errno 0] _ssl.c:340: error:00000000:lib(0):func(0):reason(0)
did you somehow disable ssl?
is vdsm running?
what's its status in engine?
what does this return:
virsh capabilities | grep model
-----Original Message-----
*From*: Itamar Heim <iheim(a)redhat.com
<mailto:Itamar%20Heim%20%3ciheim@redhat.com%3e>>
*To*: Ricardo Esteves <ricardo.m.esteves(a)gmail.com
<mailto:Ricardo%20Esteves%20%3cricardo.m.esteves@gmail.com%3e>>
*Cc*: users(a)ovirt.org <mailto:users@ovirt.org>
*Subject*: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
*Date*: Wed, 01 Aug 2012 13:59:27 +0300
On 08/01/2012 12:57 PM, Ricardo Esteves wrote:
> Hi,
>
> With the latest version of ovirt my host's CPU is not correctly identified,
> my host's have an Intel Xeon E5530 (Nehalem family), but is being identified as
Conrad family.
>
> My installed versions:
>
> ovirt-engine-3.1.0-2.fc17.noarch
> ovirt-node-iso-2.5.0-2.0.fc17.iso
>
>
> Best regards,
> Ricardo Esteves.
>
>
>
> _______________________________________________
> Users mailing list
>Users(a)ovirt.org <mailto:Users@ovirt.org>
>http://lists.ovirt.org/mailman/listinfo/users
>
please share:
vdsClient -s 0 getVdsCaps | grep -i flags
11:47 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
On 02/08/2012, at 2:29 AM, Ricardo Esteves wrote:
And now, after reboot of the node, i get this:
[root@blade4 ~]# virsh capabilities
Segmentation fault
When that seg fault happens, does anything get printed to
/var/log/messages?
Kind of wondering if there's something else at play here,
which might show up there. Worth a look at. :)
Regards and best wishes,
Justin Clift
--
Aeolus Community Manager
http://www.aeolusproject.org
11:18 a.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
On Fri, Aug 03, 2012 at 06:47:44AM +1000, Justin Clift wrote:
On 02/08/2012, at 2:29 AM, Ricardo Esteves wrote:
> And now, after reboot of the node, i get this:
>
> [root@blade4 ~]# virsh capabilities
> Segmentation fault
When that seg fault happens, does anything get printed to
/var/log/messages?
Kind of wondering if there's something else at play here,
which might show up there. Worth a look at. :)
Regards and best wishes,
Justin Clift
Please note that vdsm hacks libvirt to use sasl authentication, which
may be related to this crash.
Does anything look better with `virsh -r`?
4:17 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Ok, i fixed the ssl problem, my ovirt manager machine iptables was
blocking the 8443 port.
I also reinstalled the lastest version of the node
(ovirt-node-iso-2.5.1-1.0.fc17.iso), but ovirt manager still doesn't
recognize the CPU.
The host status remains Non Operational :
Host localhost.localdomain moved to Non-Operational state as host does
not meet the cluster's minimum CPU level. Missing CPU features :
model_Nehalem
Here are the outputs of the commands vdsClient and virsh:
[root@blade4 ~]# vdsClient -s 0 getVdsCaps
HBAInventory = {'iSCSI': [{'InitiatorName':
'iqn.1994-05.com.redhat:blade4.vi.pt'}], 'FC': []}
ISCSIInitiatorName = iqn.1994-05.com.redhat:blade4.vi.pt
bondings = {'bond4': {'addr': '', 'cfg': {},
'mtu': '1500', 'netmask':
'', 'slaves': [], 'hwaddr': '00:00:00:00:00:00'},
'bond0': {'addr': '',
'cfg': {}, 'mtu': '1500', 'netmask': '',
'slaves': [], 'hwaddr':
'00:00:00:00:00:00'}, 'bond1': {'addr': '', 'cfg':
{}, 'mtu': '1500',
'netmask': '', 'slaves': [], 'hwaddr':
'00:00:00:00:00:00'}, 'bond2':
{'addr': '', 'cfg': {}, 'mtu': '1500',
'netmask': '', 'slaves': [],
'hwaddr': '00:00:00:00:00:00'}, 'bond3': {'addr':
'', 'cfg': {}, 'mtu':
'1500', 'netmask': '', 'slaves': [], 'hwaddr':
'00:00:00:00:00:00'}}
clusterLevels = ['3.0', '3.1']
cpuCores = 4
cpuFlags =
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,cx16,xtpr,pdcm,dca,sse4_1,sse4_2,popcnt,lahf_lm,ida,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_coreduo,model_Conroe
cpuModel = Intel(R) Xeon(R) CPU E5530 @ 2.40GHz
cpuSockets = 1
cpuSpeed = 1600.000
emulatedMachines = ['pc-0.15', 'pc-1.0', 'pc', 'pc-0.14',
'pc-0.13',
'pc-0.12', 'pc-0.11', 'pc-0.10', 'isapc',
'pc-0.15', 'pc-1.0', 'pc',
'pc-0.14', 'pc-0.13', 'pc-0.12', 'pc-0.11',
'pc-0.10', 'isapc']
guestOverhead = 65
hooks = {}
kvmEnabled = true
lastClient = 192.168.10.40
lastClientIface = ovirtmgmt
management_ip =
memSize = 17926
netConfigDirty = False
networks = {'ovirtmgmt': {'addr': '192.168.10.24',
'cfg':
{'IPV6FORWARDING': 'no', 'IPV6INIT': 'no',
'IPADDR': '192.168.10.24',
'ONBOOT': 'yes', 'IPV6_AUTOCONF': 'no', 'DELAY':
'0', 'NM_CONTROLLED':
'no', 'NETMASK': '255.255.255.0', 'BOOTPROTO':
'static', 'DEVICE':
'ovirtmgmt', 'PEERNTP': 'yes', 'TYPE': 'Bridge',
'GATEWAY':
'192.168.10.254'}, 'mtu': '1500', 'netmask':
'255.255.255.0', 'stp':
'off', 'bridged': True, 'gateway': '192.168.10.254',
'ports':
['em1.10']}}
nics = {'p1p1': {'hwaddr': 'd8:d3:85:67:e3:b8',
'netmask': '', 'speed':
0, 'addr': '', 'mtu': '1500'}, 'em1':
{'hwaddr': 'd8:d3:85:bf:e9:b0',
'netmask': '', 'speed': 1000, 'addr': '',
'mtu': '1500'}, 'rename3':
{'hwaddr': 'd8:d3:85:67:e3:ba', 'netmask': '',
'speed': 0, 'addr': '',
'mtu': '1500'}, 'em2': {'hwaddr':
'd8:d3:85:bf:e9:b4', 'netmask': '',
'speed': 0, 'addr': '', 'mtu': '1500'}}
operatingSystem = {'release': '1', 'version': '17',
'name': 'oVirt
Node'}
packages2 = {'kernel': {'release': '2.fc17.x86_64',
'buildtime':
1343659739.0, 'version': '3.5.0'}, 'spice-server':
{'release': '5.fc17',
'buildtime': '1336983054', 'version': '0.10.1'},
'vdsm': {'release':
'6.fc17', 'buildtime': '1343817997', 'version':
'4.10.0'}, 'qemu-kvm':
{'release': '18.fc17', 'buildtime': '1342650221',
'version': '1.0'},
'libvirt': {'release': '3.fc17', 'buildtime':
'1340891887', 'version':
'0.9.11.4'}, 'qemu-img': {'release': '18.fc17',
'buildtime':
'1342650221', 'version': '1.0'}}
reservedMem = 321
software_revision = 6
software_version = 4.10
supportedProtocols = ['2.2', '2.3']
supportedRHEVMs = ['3.0', '3.1']
uuid = 37373035-3038-5A43-4A30-30333035455A_d8:d3:85:67:e3:b8
version_name = Snow Man
vlans = {'em1.10': {'netmask': '', 'iface':
'em1', 'addr': '', 'mtu':
'1500'}}
vmTypes = ['kvm']
[root@blade4 ~]# virsh capabilities
<capabilities>
<host>
<uuid>35303737-3830-435a-4a30-30333035455a</uuid>
<cpu>
<arch>x86_64</arch>
<model>Nehalem</model>
<vendor>Intel</vendor>
<topology sockets='1' cores='4' threads='2'/>
<feature name='rdtscp'/>
<feature name='dca'/>
<feature name='pdcm'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/>
<feature name='ds_cpl'/>
<feature name='monitor'/>
<feature name='dtes64'/>
<feature name='pbe'/>
<feature name='tm'/>
<feature name='ht'/>
<feature name='ss'/>
<feature name='acpi'/>
<feature name='ds'/>
<feature name='vme'/>
</cpu>
<power_management/>
<migration_features>
<live/>
<uri_transports>
<uri_transport>tcp</uri_transport>
</uri_transports>
</migration_features>
<topology>
<cells num='1'>
<cell id='0'>
<cpus num='8'>
<cpu id='0'/>
<cpu id='1'/>
<cpu id='2'/>
<cpu id='3'/>
<cpu id='4'/>
<cpu id='5'/>
<cpu id='6'/>
<cpu id='7'/>
</cpus>
</cell>
</cells>
</topology>
<secmodel>
<model>selinux</model>
<doi>0</doi>
</secmodel>
</host>
<guest>
<os_type>hvm</os_type>
<arch name='i686'>
<wordsize>32</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<pae/>
<nonpae/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
<guest>
<os_type>hvm</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
</capabilities>
-
----Original Message-----
From: Dan Kenigsberg <danken(a)redhat.com>
To: Justin Clift <jclift(a)redhat.com>
Cc: Ricardo Esteves <maverick.pt(a)gmail.com>, users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Sun, 5 Aug 2012 11:18:25 +0300
On Fri, Aug 03, 2012 at 06:47:44AM +1000, Justin Clift wrote:
On 02/08/2012, at 2:29 AM, Ricardo Esteves wrote:
> And now, after reboot of the node, i get this:
>
> [root@blade4 ~]# virsh capabilities
> Segmentation fault
When that seg fault happens, does anything get printed to
/var/log/messages?
Kind of wondering if there's something else at play here,
which might show up there. Worth a look at. :)
Regards and best wishes,
Justin Clift
Please note that vdsm hacks libvirt to use sasl authentication, which
may be related to this crash.
Does anything look better with `virsh -r`?
4:55 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
--_9116751c-2c3c-47f8-bfc9-1a7743108df9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ricardo=2C
=0A=
=0A=
<host =0A=
<uuid>35303737-3830-435a-4a30-30333035455a</uuid =0A=
<cpu =0A=
<arch>x86_64</arch =0A=
<model>Nehalem</model =0A=
<vendor>Intel</vendor =0A=
<topology sockets=3D'1' cores=3D'4' threads=3D'2'/ =0A=
<feature name=3D'rdtscp'/ =0A=
<feature name=3D'dca'/ =0A=
<feature name=3D'pdcm'/ =0A=
<feature name=3D'xtpr'/ =0A=
<feature name=3D'tm2'/ =0A=
<feature name=3D'est'/ =0A=
<feature name=3D'vmx'/ =0A=
<feature name=3D'ds_cpl'/ =0A=
<feature name=3D'monitor'/ =0A=
<feature name=3D'dtes64'/ =0A=
<feature name=3D'pbe'/ =0A=
<feature name=3D'tm'/ =0A=
<feature name=3D'ht'/ =0A=
<feature name=3D'ss'/ =0A=
<feature name=3D'acpi'/ =0A=
<feature name=3D'ds'/ =0A=
<feature name=3D'vme'/ =0A=
</cpu =0A=
<power_management/ =0A=
<migration_features =0A=
<live/ =0A=
<uri_transports =0A=
<uri_transport>tcp</uri_transport =0A=
</uri_transports =0A=
</migration_features =0A=
<topology =0A=
<cells num=3D'1' =0A=
<cell id=3D'0' =0A=
<cpus num=3D'8' =0A=
<cpu id=3D'0'/ =0A=
<cpu id=3D'1'/ =0A=
<cpu id=3D'2'/ =0A=
<cpu id=3D'3'/ =0A=
<cpu id=3D'4'/ =0A=
<cpu id=3D'5'/ =0A=
<cpu id=3D'6'/ =0A=
<cpu id=3D'7'/ =0A=
</cpus =0A=
</cell =0A=
</cells =0A=
</topology =0A=
<secmodel =0A=
<model>selinux</model =0A=
<doi>0</doi =0A=
</secmodel =0A=
</host =0A=
=0A=
<guest =0A=
<os_type>hvm</os_type =0A=
<arch name=3D'i686' =0A=
<wordsize>32</wordsize =0A=
<emulator>/usr/bin/qemu-system-x86_64</emulator =0A=
<machine>pc-0.15</machine =0A=
<machine>pc-1.0</machine =0A=
<machine canonical=3D'pc-1.0'>pc</machine =0A=
<machine>pc-0.14</machine =0A=
<machine>pc-0.13</machine =0A=
<machine>pc-0.12</machine =0A=
<machine>pc-0.11</machine =0A=
<machine>pc-0.10</machine =0A=
<machine>isapc</machine =0A=
<domain type=3D'qemu' =0A=
</domain =0A=
<domain type=3D'kvm' =0A=
<emulator>/usr/bin/qemu-kvm</emulator =0A=
<machine>pc-0.15</machine =0A=
<machine>pc-1.0</machine =0A=
<machine canonical=3D'pc-1.0'>pc</machine =0A=
<machine>pc-0.14</machine =0A=
<machine>pc-0.13</machine =0A=
<machine>pc-0.12</machine =0A=
<machine>pc-0.11</machine =0A=
<machine>pc-0.10</machine =0A=
<machine>isapc</machine =0A=
</domain =0A=
</arch =0A=
<features =0A=
<cpuselection/ =0A=
<deviceboot/ =0A=
<pae/ =0A=
<nonpae/ =0A=
<acpi default=3D'on' toggle=3D'yes'/ =0A=
<apic default=3D'on' toggle=3D'no'/ =0A=
</features =0A=
</guest =0A=
=0A=
<guest =0A=
<os_type>hvm</os_type =0A=
<arch name=3D'x86_64' =0A=
<wordsize>64</wordsize =0A=
<emulator>/usr/bin/qemu-system-x86_64</emulator =0A=
<machine>pc-0.15</machine =0A=
<machine>pc-1.0</machine =0A=
<machine canonical=3D'pc-1.0'>pc</machine =0A=
<machine>pc-0.14</machine =0A=
<machine>pc-0.13</machine =0A=
<machine>pc-0.12</machine =0A=
<machine>pc-0.11</machine =0A=
<machine>pc-0.10</machine =0A=
<machine>isapc</machine =0A=
<domain type=3D'qemu' =0A=
</domain =0A=
<domain type=3D'kvm' =0A=
<emulator>/usr/bin/qemu-kvm</emulator =0A=
<machine>pc-0.15</machine =0A=
<machine>pc-1.0</machine =0A=
<machine canonical=3D'pc-1.0'>pc</machine =0A=
<machine>pc-0.14</machine =0A=
<machine>pc-0.13</machine =0A=
<machine>pc-0.12</machine =0A=
<machine>pc-0.11</machine =0A=
<machine>pc-0.10</machine =0A=
<machine>isapc</machine =0A=
</domain =0A=
</arch =0A=
<features =0A=
<cpuselection/ =0A=
<deviceboot/ =0A=
<acpi default=3D'on' toggle=3D'yes'/ =0A=
<apic default=3D'on' toggle=3D'no'/ =0A=
</features =0A=
</guest =0A=
=0A=
</capabilities =0A=
-
=0A=
----Original Message-----
=0A=
From: Dan Kenigsberg <danken(a)redhat.com =0A=
To: Justin Clift <jclift(a)redhat.com =0A=
Cc: Ricardo Esteves <maverick.pt(a)gmail.com>=2C users(a)ovirt.org
=0A=
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
=0A=
Date: Sun=2C 5 Aug 2012 11:18:25 +0300
=0A=
=0A=
On Fri=2C Aug 03=2C 2012 at 06:47:44AM +1000=2C Justin Clift wrote:=0A=
<head <style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head <body
class=3D'hmmessage'><div
dir=3D'ltr'>Ricardo=2C<br><br>From your getV=
dsCaps=2C I see that it reports as "model_coreduo=2Cmodel_Conroe". Changing=
your compatibility level for the data center to Conroe allow you to bring =
that host up.<br><br>- Nick<br><br><div><div
id=3D"SkyDrivePlaceholder"></d=
iv><hr id=3D"stopSpelling">From:
ricardo.m.esteves(a)gmail.com<br>To: iheim@r=
edhat.com<br>Date: Thu=2C 9 Aug 2012 14:17:44 +0100<br>CC:
users(a)ovirt.org<=
br>Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification<b=
r><br </html>=
--_9116751c-2c3c-47f8-bfc9-1a7743108df9_--
From your getVdsCaps=2C I see that it reports as
"model_coreduo=2Cmodel_Con=
roe". Changing your compatibility level for
the data center to Conroe allow=
you to bring that host up.
- Nick
From: ricardo.m.esteves(a)gmail.com
To: iheim(a)redhat.com
Date: Thu=2C 9 Aug 2012 14:17:44 +0100
CC: users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Ok=2C i fixed the ssl problem=2C my ovirt manager machine iptables was bloc=
king the 8443 port.
=0A=
=0A=
I also reinstalled the lastest version of the node (ovirt-node-iso-2.5.1-1.=
0.fc17.iso)=2C but ovirt manager still doesn't recognize the CPU.=20
=0A=
=0A=
The host status remains Non Operational :
=0A=
=0A=
Host localhost.localdomain moved to Non-Operational state as host does not =
meet the cluster's minimum CPU level. Missing CPU features : model_Nehalem
=0A=
=0A=
Here are the outputs of the commands vdsClient and virsh:
=0A=
=0A=
[root@blade4 ~]# vdsClient -s 0 getVdsCaps
=0A=
HBAInventory =3D {'iSCSI': [{'InitiatorName':
'iqn.1994-05.com.redhat:blad=
e4.vi.pt'}]=2C 'FC': []}
=0A=
ISCSIInitiatorName =3D iqn.1994-05.com.redhat:blade4.vi.pt
=0A=
bondings =3D {'bond4': {'addr': ''=2C 'cfg': {}=2C
'mtu': '1500'=2C 'netma=
sk': ''=2C 'slaves': []=2C 'hwaddr':
'00:00:00:00:00:00'}=2C 'bond0': {'add=
r': ''=2C 'cfg': {}=2C 'mtu': '1500'=2C
'netmask': ''=2C 'slaves': []=2C 'h=
waddr': '00:00:00:00:00:00'}=2C 'bond1': {'addr':
''=2C 'cfg': {}=2C 'mtu':=
'1500'=2C 'netmask': ''=2C 'slaves': []=2C
'hwaddr': '00:00:00:00:00:00'}=
=2C 'bond2': {'addr': ''=2C 'cfg': {}=2C 'mtu':
'1500'=2C 'netmask': ''=2C =
'slaves': []=2C 'hwaddr': '00:00:00:00:00:00'}=2C 'bond3':
{'addr': ''=2C '=
cfg': {}=2C 'mtu': '1500'=2C 'netmask': ''=2C
'slaves': []=2C 'hwaddr': '00=
:00:00:00:00:00'}}
=0A=
clusterLevels =3D ['3.0'=2C '3.1']
=0A=
cpuCores =3D 4
=0A=
cpuFlags =3D fpu=2Cvme=2Cde=2Cpse=2Ctsc=2Cmsr=2Cpae=2Cmce=2Ccx8=2Capic=2Cs=
ep=2Cmtrr=2Cpge=2Cmca=2Ccmov=2Cpat=2Cpse36=2Cclflush=2Cdts=2Cacpi=2Cmmx=2Cf=
xsr=2Csse=2Csse2=2Css=2Cht=2Ctm=2Cpbe=2Csyscall=2Cnx=2Crdtscp=2Clm=2Cconsta=
nt_tsc=2Carch_perfmon=2Cpebs=2Cbts=2Crep_good=2Cnopl=2Cxtopology=2Cnonstop_=
tsc=2Caperfmperf=2Cpni=2Cdtes64=2Cmonitor=2Cds_cpl=2Cvmx=2Cest=2Ctm2=2Cssse=
3=2Ccx16=2Cxtpr=2Cpdcm=2Cdca=2Csse4_1=2Csse4_2=2Cpopcnt=2Clahf_lm=2Cida=2Cd=
therm=2Ctpr_shadow=2Cvnmi=2Cflexpriority=2Cept=2Cvpid=2Cmodel_coreduo=2Cmod=
el_Conroe
=0A=
cpuModel =3D Intel(R) Xeon(R) CPU E5530 @ 2.40GHz
=0A=
cpuSockets =3D 1
=0A=
cpuSpeed =3D 1600.000
=0A=
emulatedMachines =3D ['pc-0.15'=2C 'pc-1.0'=2C 'pc'=2C
'pc-0.14'=2C 'pc-0.=
13'=2C 'pc-0.12'=2C 'pc-0.11'=2C 'pc-0.10'=2C
'isapc'=2C 'pc-0.15'=2C 'pc-1=
.0'=2C 'pc'=2C 'pc-0.14'=2C 'pc-0.13'=2C 'pc-0.12'=2C
'pc-0.11'=2C 'pc-0.10=
'=2C 'isapc']
=0A=
guestOverhead =3D 65
=0A=
hooks =3D {}
=0A=
kvmEnabled =3D true
=0A=
lastClient =3D 192.168.10.40
=0A=
lastClientIface =3D ovirtmgmt
=0A=
management_ip =3D=20
=0A=
memSize =3D 17926
=0A=
netConfigDirty =3D False
=0A=
networks =3D {'ovirtmgmt': {'addr': '192.168.10.24'=2C
'cfg': {'IPV6FORWAR=
DING': 'no'=2C 'IPV6INIT': 'no'=2C 'IPADDR':
'192.168.10.24'=2C 'ONBOOT': '=
yes'=2C 'IPV6_AUTOCONF': 'no'=2C 'DELAY': '0'=2C
'NM_CONTROLLED': 'no'=2C '=
NETMASK': '255.255.255.0'=2C 'BOOTPROTO': 'static'=2C
'DEVICE': 'ovirtmgmt'=
=2C 'PEERNTP': 'yes'=2C 'TYPE': 'Bridge'=2C
'GATEWAY': '192.168.10.254'}=2C=
'mtu': '1500'=2C 'netmask': '255.255.255.0'=2C
'stp': 'off'=2C 'bridged': =
True=2C 'gateway': '192.168.10.254'=2C 'ports':
['em1.10']}}
=0A=
nics =3D {'p1p1': {'hwaddr': 'd8:d3:85:67:e3:b8'=2C
'netmask': ''=2C 'spee=
d': 0=2C 'addr': ''=2C 'mtu': '1500'}=2C
'em1': {'hwaddr': 'd8:d3:85:bf:e9:=
b0'=2C 'netmask': ''=2C 'speed': 1000=2C 'addr':
''=2C 'mtu': '1500'}=2C 'r=
ename3': {'hwaddr': 'd8:d3:85:67:e3:ba'=2C 'netmask':
''=2C 'speed': 0=2C '=
addr': ''=2C 'mtu': '1500'}=2C 'em2':
{'hwaddr': 'd8:d3:85:bf:e9:b4'=2C 'ne=
tmask': ''=2C 'speed': 0=2C 'addr': ''=2C
'mtu': '1500'}}
=0A=
operatingSystem =3D {'release': '1'=2C 'version': '17'=2C
'name': 'oVirt N=
ode'}
=0A=
packages2 =3D {'kernel': {'release': '2.fc17.x86_64'=2C
'buildtime': 13436=
59739.0=2C 'version': '3.5.0'}=2C 'spice-server':
{'release': '5.fc17'=2C '=
buildtime': '1336983054'=2C 'version': '0.10.1'}=2C
'vdsm': {'release': '6.=
fc17'=2C 'buildtime': '1343817997'=2C 'version':
'4.10.0'}=2C 'qemu-kvm': {=
'release': '18.fc17'=2C 'buildtime': '1342650221'=2C
'version': '1.0'}=2C '=
libvirt': {'release': '3.fc17'=2C 'buildtime':
'1340891887'=2C 'version': '=
0.9.11.4'}=2C 'qemu-img': {'release': '18.fc17'=2C
'buildtime': '1342650221=
'=2C 'version': '1.0'}}
=0A=
reservedMem =3D 321
=0A=
software_revision =3D 6
=0A=
software_version =3D 4.10
=0A=
supportedProtocols =3D ['2.2'=2C '2.3']
=0A=
supportedRHEVMs =3D ['3.0'=2C '3.1']
=0A=
uuid =3D 37373035-3038-5A43-4A30-30333035455A_d8:d3:85:67:e3:b8
=0A=
version_name =3D Snow Man
=0A=
vlans =3D {'em1.10': {'netmask': ''=2C 'iface':
'em1'=2C 'addr': ''=2C 'mt=
u': '1500'}}
=0A=
vmTypes =3D ['kvm']
=0A=
=0A=
=0A=
[root@blade4 ~]# virsh capabilities
=0A=
<capabilities On 02/08/2012=2C at 2:29 AM=2C Ricardo Esteves wrote:=0A=
> And now=2C after reboot of the node=2C i get this:=0A=
> =0A=
> [root@blade4 ~]# virsh capabilities=0A=
> Segmentation fault=0A=
=0A=
When that seg fault happens=2C does anything get printed to=0A=
/var/log/messages?=0A=
=0A=
Kind of wondering if there's something else at play here=2C=0A=
which might show up there. Worth a look at. :)=0A=
=0A=
Regards and best wishes=2C=0A=
=0A=
Justin Clift=0A=
=0A=
Please note that vdsm hacks libvirt to use sasl authentication=2C which=0A=
may be related to this crash.=0A=
=0A=
Does anything look better with `virsh -r`?=0A=
=0A=
=0A=
=0A=
_______________________________________________=0A=
Users mailing list=0A=
Users(a)ovirt.org=0A=
http://lists.ovirt.org/mailman/listinfo/users =
--_9116751c-2c3c-47f8-bfc9-1a7743108df9_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
<br=0A=
Ok=2C i fixed the ssl problem=2C my ovirt manager machine
iptables was bloc=
king the 8443 port.<br=0A=
<br=0A=
I also reinstalled the lastest version of the node
(ovirt-node-iso-2.5.1-1.=
0.fc17.iso)=2C but ovirt manager still doesn't recognize the CPU. <br=0A=
<br=0A=
The
host status remains Non Operational :<br=0A=
<br=0A=
Host localhost.localdomain moved
to Non-Operational state as host does not =
meet the cluster's minimum CPU level. Missing CPU features : model_Nehalem<=
br=0A=
<br=0A=
Here
are the outputs of the commands vdsClient and virsh:<br=0A=
<br=0A=
[<a
href=3D"mailto:root@blade4">root@blade4</a> ~]# vdsClient -s 0
getVdsCa=
ps<br=0A=
HBAInventory =3D
{'iSCSI': [{'InitiatorName': 'iqn.1994-05.com.redhat:blad=
e4.vi.pt'}]=2C 'FC': []}<br=0A=
ISCSIInitiatorName =3D iqn.1994-05.com.redhat:blade4.vi.pt<br=0A=
bondings =3D {'bond4': {'addr':
''=2C 'cfg': {}=2C 'mtu': '1500'=2C 'netma=
sk': ''=2C 'slaves': []=2C 'hwaddr':
'00:00:00:00:00:00'}=2C 'bond0': {'add=
r': ''=2C 'cfg': {}=2C 'mtu': '1500'=2C
'netmask': ''=2C 'slaves': []=2C 'h=
waddr': '00:00:00:00:00:00'}=2C 'bond1': {'addr':
''=2C 'cfg': {}=2C 'mtu':=
'1500'=2C 'netmask': ''=2C 'slaves': []=2C
'hwaddr': '00:00:00:00:00:00'}=
=2C 'bond2': {'addr': ''=2C 'cfg': {}=2C 'mtu':
'1500'=2C 'netmask': ''=2C =
'slaves': []=2C 'hwaddr': '00:00:00:00:00:00'}=2C 'bond3':
{'addr': ''=2C '=
cfg': {}=2C 'mtu': '1500'=2C 'netmask': ''=2C
'slaves': []=2C 'hwaddr': '00=
:00:00:00:00:00'}}<br=0A=
clusterLevels =3D
['3.0'=2C '3.1']<br=0A=
cpuCores =3D 4<br=0A=
cpuFlags =3D
fpu=2Cvme=2Cde=2Cpse=2Ctsc=2Cmsr=2Cpae=2Cmce=2Ccx8=2Capic=2Cs=
ep=2Cmtrr=2Cpge=2Cmca=2Ccmov=2Cpat=2Cpse36=2Cclflush=2Cdts=2Cacpi=2Cmmx=2Cf=
xsr=2Csse=2Csse2=2Css=2Cht=2Ctm=2Cpbe=2Csyscall=2Cnx=2Crdtscp=2Clm=2Cconsta=
nt_tsc=2Carch_perfmon=2Cpebs=2Cbts=2Crep_good=2Cnopl=2Cxtopology=2Cnonstop_=
tsc=2Caperfmperf=2Cpni=2Cdtes64=2Cmonitor=2Cds_cpl=2Cvmx=2Cest=2Ctm2=2Cssse=
3=2Ccx16=2Cxtpr=2Cpdcm=2Cdca=2Csse4_1=2Csse4_2=2Cpopcnt=2Clahf_lm=2Cida=2Cd=
therm=2Ctpr_shadow=2Cvnmi=2Cflexpriority=2Cept=2Cvpid=2Cmodel_coreduo=2Cmod=
el_Conroe<br=0A=
cpuModel =3D Intel(R) Xeon(R)
CPU =3B =3B =3B =3B =3B&=
nbsp=3B =3B =3B =3B =3B E5530 =3B @
2.40GHz<br=0A=
cpuSockets =3D 1<br=0A=
cpuSpeed =3D 1600.000<br=0A=
emulatedMachines =3D ['pc-0.15'=2C 'pc-1.0'=2C 'pc'=2C
'pc-0.14'=2C 'pc-0.=
13'=2C 'pc-0.12'=2C 'pc-0.11'=2C 'pc-0.10'=2C
'isapc'=2C 'pc-0.15'=2C 'pc-1=
.0'=2C 'pc'=2C 'pc-0.14'=2C 'pc-0.13'=2C 'pc-0.12'=2C
'pc-0.11'=2C 'pc-0.10=
'=2C 'isapc']<br=0A=
guestOverhead =3D 65<br=0A=
hooks =3D {}<br=0A=
kvmEnabled =3D true<br=0A=
lastClient =3D
192.168.10.40<br=0A=
lastClientIface =3D
ovirtmgmt<br=0A=
management_ip =3D <br=0A=
memSize =3D 17926<br=0A=
netConfigDirty =3D False<br=0A=
networks =3D {'ovirtmgmt': {'addr': '192.168.10.24'=2C
'cfg': {'IPV6FORWAR=
DING': 'no'=2C 'IPV6INIT': 'no'=2C 'IPADDR':
'192.168.10.24'=2C 'ONBOOT': '=
yes'=2C 'IPV6_AUTOCONF': 'no'=2C 'DELAY': '0'=2C
'NM_CONTROLLED': 'no'=2C '=
NETMASK': '255.255.255.0'=2C 'BOOTPROTO': 'static'=2C
'DEVICE': 'ovirtmgmt'=
=2C 'PEERNTP': 'yes'=2C 'TYPE': 'Bridge'=2C
'GATEWAY': '192.168.10.254'}=2C=
'mtu': '1500'=2C 'netmask': '255.255.255.0'=2C
'stp': 'off'=2C 'bridged': =
True=2C 'gateway': '192.168.10.254'=2C 'ports':
['em1.10']}}<br=0A=
nics =3D {'p1p1':
{'hwaddr': 'd8:d3:85:67:e3:b8'=2C 'netmask': ''=2C
'spee=
d': 0=2C 'addr': ''=2C 'mtu': '1500'}=2C
'em1': {'hwaddr': 'd8:d3:85:bf:e9:=
b0'=2C 'netmask': ''=2C 'speed': 1000=2C 'addr':
''=2C 'mtu': '1500'}=2C 'r=
ename3': {'hwaddr': 'd8:d3:85:67:e3:ba'=2C 'netmask':
''=2C 'speed': 0=2C '=
addr': ''=2C 'mtu': '1500'}=2C 'em2':
{'hwaddr': 'd8:d3:85:bf:e9:b4'=2C 'ne=
tmask': ''=2C 'speed': 0=2C 'addr': ''=2C
'mtu': '1500'}}<br=0A=
operatingSystem =3D {'release': '1'=2C 'version':
'17'=2C 'name': 'oVirt N=
ode'}<br=0A=
packages2 =3D
{'kernel': {'release': '2.fc17.x86_64'=2C 'buildtime':
13436=
59739.0=2C 'version': '3.5.0'}=2C 'spice-server':
{'release': '5.fc17'=2C '=
buildtime': '1336983054'=2C 'version': '0.10.1'}=2C
'vdsm': {'release': '6.=
fc17'=2C 'buildtime': '1343817997'=2C 'version':
'4.10.0'}=2C 'qemu-kvm': {=
'release': '18.fc17'=2C 'buildtime': '1342650221'=2C
'version': '1.0'}=2C '=
libvirt': {'release': '3.fc17'=2C 'buildtime':
'1340891887'=2C 'version': '=
0.9.11.4'}=2C 'qemu-img': {'release': '18.fc17'=2C
'buildtime': '1342650221=
'=2C 'version': '1.0'}}<br=0A=
reservedMem =3D 321<br=0A=
software_revision =3D
6<br=0A=
software_version =3D 4.10<br=0A=
supportedProtocols =3D ['2.2'=2C
'2.3']<br=0A=
supportedRHEVMs =3D
['3.0'=2C '3.1']<br=0A=
uuid
=3D 37373035-3038-5A43-4A30-30333035455A_d8:d3:85:67:e3:b8<br=0A=
version_name =3D Snow Man<br=0A=
vlans =3D {'em1.10': {'netmask':
''=2C 'iface': 'em1'=2C 'addr': ''=2C 'mt=
u': '1500'}}<br=0A=
vmTypes =3D
['kvm']<br=0A=
<br=0A=
<br=0A=
[<a href=3D"mailto:root@blade4">root@blade4</a> ~]# virsh
capabilities<br>=
=0A=
<=3Bcapabilities>=3B<br=0A=
<br=0A=
 =3B
<=3Bhost>=3B<br=0A=
 =3B =3B =3B
<=3Buuid>=3B35303737-3830-435a-4a30-3033303545=
5a<=3B/uuid>=3B<br=0A=
 =3B =3B =3B <=3Bcpu>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Barch>=3Bx86_64<=3B/arch&=
gt=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmodel>=3BNehalem<=3B/mod=
el>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bvendor>=3BIntel<=3B/vend=
or>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Btopology
sockets=3D'1' cores=
=3D'4' threads=3D'2'/>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'rdtscp'/>=
=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'dca'/>=3B<=
br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'pdcm'/>=3B=
<br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'xtpr'/>=3B=
<br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'tm2'/>=3B<=
br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'est'/>=3B<=
br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'vmx'/>=3B<=
br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'ds_cpl'/>=
=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'monitor'/>=
=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'dtes64'/>=
=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'pbe'/>=3B<=
br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'tm'/>=3B<b=
r=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'ht'/>=3B<b=
r=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'ss'/>=3B<b=
r=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'acpi'/>=3B=
<br=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'ds'/>=3B<b=
r=0A=
 =3B =3B =3B =3B =3B <=3Bfeature
name=3D'vme'/>=3B<=
br=0A=
 =3B =3B =3B
<=3B/cpu>=3B<br=0A=
 =3B =3B =3B <=3Bpower_management/>=3B<br=0A=
 =3B =3B =3B
<=3Bmigration_features>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Blive/>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Buri_transports>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Buri_transpor=
t>=3Btcp<=3B/uri_transport>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3B/uri_transports>=3B<br=0A=
 =3B =3B =3B
<=3B/migration_features>=3B<br=0A=
 =3B =3B =3B <=3Btopology>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bcells
num=3D'1'>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bcell id=3D'0=
'>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B
&l=
t=3Bcpus num=3D'8'>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B =3B <=3Bcpu id=3D'0'/>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B =3B <=3Bcpu id=3D'1'/>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B =3B <=3Bcpu id=3D'2'/>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B =3B <=3Bcpu id=3D'3'/>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B =3B <=3Bcpu id=3D'4'/>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B =3B <=3Bcpu id=3D'5'/>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B =3B <=3Bcpu id=3D'6'/>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B =3B <=3Bcpu id=3D'7'/>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B
&l=
t=3B/cpus>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3B/cell>=3B<=
br=0A=
 =3B =3B =3B =3B =3B
<=3B/cells>=3B<br=0A=
 =3B =3B =3B <=3B/topology>=3B<br=0A=
 =3B =3B =3B
<=3Bsecmodel>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmodel>=3Bselinux<=3B/mod=
el>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bdoi>=3B0<=3B/doi>=3B<b=
r=0A=
 =3B =3B =3B
<=3B/secmodel>=3B<br=0A=
 =3B <=3B/host>=3B<br=0A=
<br=0A=
 =3B
<=3Bguest>=3B<br=0A=
 =3B =3B =3B
<=3Bos_type>=3Bhvm<=3B/os_type>=3B<br=0A=
 =3B =3B =3B <=3Barch
name=3D'i686'>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bwordsize>=3B32<=3B/words=
ize>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bemulator>=3B/usr/bin/qemu-=
system-x86_64<=3B/emulator>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.15<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-1.0<=3B/ma=
chine>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bmachine
canonical=3D'pc-1.0'=
>=3Bpc<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.14<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.13<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.12<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.11<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.10<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bisapc<=3B/mac=
hine>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bdomain
type=3D'qemu'>=3B<b=
r=0A=
 =3B =3B =3B =3B =3B
<=3B/domain>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bdomain
type=3D'kvm'>=3B<br=
=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bemulator>=
=3B/usr/bin/qemu-kvm<=3B/emulator>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.15<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-1.0<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine cano=
nical=3D'pc-1.0'>=3Bpc<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.14<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.13<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.12<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.11<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.10<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bisapc<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3B/domain>=3B<br=0A=
 =3B =3B =3B <=3B/arch>=3B<br=0A=
 =3B =3B =3B
<=3Bfeatures>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bcpuselection/>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bdeviceboot/>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bpae/>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bnonpae/>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bacpi
default=3D'on' toggle=
=3D'yes'/>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bapic
default=3D'on' toggle=
=3D'no'/>=3B<br=0A=
 =3B =3B =3B <=3B/features>=3B<br=0A=
 =3B <=3B/guest>=3B<br=0A=
<br=0A=
 =3B <=3Bguest>=3B<br=0A=
 =3B =3B =3B
<=3Bos_type>=3Bhvm<=3B/os_type>=3B<br=0A=
 =3B =3B =3B <=3Barch
name=3D'x86_64'>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bwordsize>=3B64<=3B/words=
ize>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bemulator>=3B/usr/bin/qemu-=
system-x86_64<=3B/emulator>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.15<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-1.0<=3B/ma=
chine>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bmachine
canonical=3D'pc-1.0'=
>=3Bpc<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.14<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.13<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.12<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.11<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bpc-0.10<=3B/m=
achine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bmachine>=3Bisapc<=3B/mac=
hine>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bdomain
type=3D'qemu'>=3B<b=
r=0A=
 =3B =3B =3B =3B =3B
<=3B/domain>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bdomain
type=3D'kvm'>=3B<br=
=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bemulator>=
=3B/usr/bin/qemu-kvm<=3B/emulator>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.15<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-1.0<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine cano=
nical=3D'pc-1.0'>=3Bpc<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.14<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.13<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.12<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.11<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bpc-0.10<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B =3B =3B
<=3Bmachine>=
=3Bisapc<=3B/machine>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3B/domain>=3B<br=0A=
 =3B =3B =3B <=3B/arch>=3B<br=0A=
 =3B =3B =3B
<=3Bfeatures>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bcpuselection/>=3B<br=0A=
 =3B =3B =3B =3B =3B
<=3Bdeviceboot/>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bacpi
default=3D'on' toggle=
=3D'yes'/>=3B<br=0A=
 =3B =3B =3B =3B =3B <=3Bapic
default=3D'on' toggle=
=3D'no'/>=3B<br=0A=
 =3B =3B =3B <=3B/features>=3B<br=0A=
 =3B <=3B/guest>=3B<br=0A=
<br=0A=
<=3B/capabilities>=3B<br=0A=
-<br=0A=
----Original
Message-----<br=0A=
<b>From</b>: Dan
Kenigsberg <=3B<a href=3D"mailto:Dan%20Kenigsberg%20%3cd=
anken@redhat.com%3e">danken(a)redhat.com</a>&gt=3B<br=0A=
<b>To</b>: Justin Clift <=3B<a
href=3D"mailto:Justin%20Clift%20%3cjclift@=
redhat.com%3e">jclift(a)redhat.com</a>&gt=3B<br=0A=
<b>Cc</b>: Ricardo Esteves <=3B<a
href=3D"mailto:Ricardo%20Esteves%20%3cm=
averick.pt@gmail.com%3e">maverick.pt(a)gmail.com</a>&gt=3B=2C <a
href=3D"mail=
to:users@ovirt.org">users@ovirt.org</a><br=0A=
<b>Subject</b>: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu
identificati=
on<br=0A=
<b>Date</b>: Sun=2C
5 Aug 2012 11:18:25 +0300<br=0A=
<br=0A=
<pre>On Fri=2C Aug 03=2C 2012 at 06:47:44AM +1000=2C
Justin Clift wrote:=0A=
>=3B On 02/08/2012=2C at 2:29 AM=2C Ricardo Esteves wrote:=0A=
>=3B >=3B And now=2C after reboot of the node=2C i get this:=0A=
>=3B >=3B =0A=
>=3B >=3B [root@blade4 ~]# virsh capabilities=0A=
>=3B >=3B Segmentation fault=0A=
>=3B =0A=
>=3B When that seg fault happens=2C does anything get printed to=0A=
>=3B /var/log/messages?=0A=
>=3B =0A=
>=3B Kind of wondering if there's something else at play here=2C=0A=
>=3B which might show up there. Worth a look at. :)=0A=
>=3B =0A=
>=3B Regards and best wishes=2C=0A=
>=3B =0A=
>=3B Justin Clift=0A=
=0A=
Please note that vdsm hacks libvirt to use sasl authentication=2C which=0A=
may be related to this crash.=0A=
=0A=
Does anything look better with `virsh -r`?=0A=
</pre=0A=
=0A=
=0A=
<br>_______________________________________________=0A=
Users mailing list=0A=
Users(a)ovirt.org=0A=
http://lists.ovirt.org/mailman/listinfo/users</div>
</div></body=
5:17 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
On 08/09/2012 04:17 PM, Ricardo Esteves wrote:
Ok, i fixed the ssl problem, my ovirt manager machine iptables was
blocking the 8443 port.
I also reinstalled the lastest version of the node
(ovirt-node-iso-2.5.1-1.0.fc17.iso), but ovirt manager still doesn't
recognize the CPU.
The host status remains Non Operational :
Host localhost.localdomain moved to Non-Operational state as host does
not meet the cluster's minimum CPU level. Missing CPU features :
model_Nehalem
danken - libvirt reports nehalem, yet vdsm reports conroe?
Here are the outputs of the commands vdsClient and virsh:
[root@blade4 <mailto:root@blade4> ~]# vdsClient -s 0 getVdsCaps
HBAInventory = {'iSCSI': [{'InitiatorName':
'iqn.1994-05.com.redhat:blade4.vi.pt'}], 'FC': []}
ISCSIInitiatorName = iqn.1994-05.com.redhat:blade4.vi.pt
bondings = {'bond4': {'addr': '', 'cfg': {},
'mtu': '1500', 'netmask':
'', 'slaves': [], 'hwaddr': '00:00:00:00:00:00'},
'bond0': {'addr': '',
'cfg': {}, 'mtu': '1500', 'netmask': '',
'slaves': [], 'hwaddr':
'00:00:00:00:00:00'}, 'bond1': {'addr': '',
'cfg': {}, 'mtu': '1500',
'netmask': '', 'slaves': [], 'hwaddr':
'00:00:00:00:00:00'}, 'bond2':
{'addr': '', 'cfg': {}, 'mtu': '1500',
'netmask': '', 'slaves': [],
'hwaddr': '00:00:00:00:00:00'}, 'bond3': {'addr':
'', 'cfg': {}, 'mtu':
'1500', 'netmask': '', 'slaves': [], 'hwaddr':
'00:00:00:00:00:00'}}
clusterLevels = ['3.0', '3.1']
cpuCores = 4
cpuFlags =
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,cx16,xtpr,pdcm,dca,sse4_1,sse4_2,popcnt,lahf_lm,ida,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_coreduo,model_Conroe
cpuModel = Intel(R) Xeon(R) CPU E5530 @ 2.40GHz
cpuSockets = 1
cpuSpeed = 1600.000
emulatedMachines = ['pc-0.15', 'pc-1.0', 'pc', 'pc-0.14',
'pc-0.13',
'pc-0.12', 'pc-0.11', 'pc-0.10', 'isapc',
'pc-0.15', 'pc-1.0', 'pc',
'pc-0.14', 'pc-0.13', 'pc-0.12', 'pc-0.11',
'pc-0.10', 'isapc']
guestOverhead = 65
hooks = {}
kvmEnabled = true
lastClient = 192.168.10.40
lastClientIface = ovirtmgmt
management_ip =
memSize = 17926
netConfigDirty = False
networks = {'ovirtmgmt': {'addr': '192.168.10.24',
'cfg':
{'IPV6FORWARDING': 'no', 'IPV6INIT': 'no',
'IPADDR': '192.168.10.24',
'ONBOOT': 'yes', 'IPV6_AUTOCONF': 'no', 'DELAY':
'0', 'NM_CONTROLLED':
'no', 'NETMASK': '255.255.255.0', 'BOOTPROTO':
'static', 'DEVICE':
'ovirtmgmt', 'PEERNTP': 'yes', 'TYPE': 'Bridge',
'GATEWAY':
'192.168.10.254'}, 'mtu': '1500', 'netmask':
'255.255.255.0', 'stp':
'off', 'bridged': True, 'gateway': '192.168.10.254',
'ports': ['em1.10']}}
nics = {'p1p1': {'hwaddr': 'd8:d3:85:67:e3:b8',
'netmask': '', 'speed':
0, 'addr': '', 'mtu': '1500'}, 'em1':
{'hwaddr': 'd8:d3:85:bf:e9:b0',
'netmask': '', 'speed': 1000, 'addr': '',
'mtu': '1500'}, 'rename3':
{'hwaddr': 'd8:d3:85:67:e3:ba', 'netmask': '',
'speed': 0, 'addr': '',
'mtu': '1500'}, 'em2': {'hwaddr':
'd8:d3:85:bf:e9:b4', 'netmask': '',
'speed': 0, 'addr': '', 'mtu': '1500'}}
operatingSystem = {'release': '1', 'version': '17',
'name': 'oVirt Node'}
packages2 = {'kernel': {'release': '2.fc17.x86_64',
'buildtime':
1343659739.0, 'version': '3.5.0'}, 'spice-server':
{'release': '5.fc17',
'buildtime': '1336983054', 'version': '0.10.1'},
'vdsm': {'release':
'6.fc17', 'buildtime': '1343817997', 'version':
'4.10.0'}, 'qemu-kvm':
{'release': '18.fc17', 'buildtime': '1342650221',
'version': '1.0'},
'libvirt': {'release': '3.fc17', 'buildtime':
'1340891887', 'version':
'0.9.11.4'}, 'qemu-img': {'release': '18.fc17',
'buildtime':
'1342650221', 'version': '1.0'}}
reservedMem = 321
software_revision = 6
software_version = 4.10
supportedProtocols = ['2.2', '2.3']
supportedRHEVMs = ['3.0', '3.1']
uuid = 37373035-3038-5A43-4A30-30333035455A_d8:d3:85:67:e3:b8
version_name = Snow Man
vlans = {'em1.10': {'netmask': '', 'iface':
'em1', 'addr': '', 'mtu':
'1500'}}
vmTypes = ['kvm']
[root@blade4 <mailto:root@blade4> ~]# virsh capabilities
<capabilities>
<host>
<uuid>35303737-3830-435a-4a30-30333035455a</uuid>
<cpu>
<arch>x86_64</arch>
<model>Nehalem</model>
<vendor>Intel</vendor>
<topology sockets='1' cores='4' threads='2'/>
<feature name='rdtscp'/>
<feature name='dca'/>
<feature name='pdcm'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/>
<feature name='ds_cpl'/>
<feature name='monitor'/>
<feature name='dtes64'/>
<feature name='pbe'/>
<feature name='tm'/>
<feature name='ht'/>
<feature name='ss'/>
<feature name='acpi'/>
<feature name='ds'/>
<feature name='vme'/>
</cpu>
<power_management/>
<migration_features>
<live/>
<uri_transports>
<uri_transport>tcp</uri_transport>
</uri_transports>
</migration_features>
<topology>
<cells num='1'>
<cell id='0'>
<cpus num='8'>
<cpu id='0'/>
<cpu id='1'/>
<cpu id='2'/>
<cpu id='3'/>
<cpu id='4'/>
<cpu id='5'/>
<cpu id='6'/>
<cpu id='7'/>
</cpus>
</cell>
</cells>
</topology>
<secmodel>
<model>selinux</model>
<doi>0</doi>
</secmodel>
</host>
<guest>
<os_type>hvm</os_type>
<arch name='i686'>
<wordsize>32</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<pae/>
<nonpae/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
<guest>
<os_type>hvm</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
</capabilities>
-
----Original Message-----
*From*: Dan Kenigsberg <danken(a)redhat.com
<mailto:Dan%20Kenigsberg%20%3cdanken@redhat.com%3e>>
*To*: Justin Clift <jclift(a)redhat.com
<mailto:Justin%20Clift%20%3cjclift@redhat.com%3e>>
*Cc*: Ricardo Esteves <maverick.pt(a)gmail.com
<mailto:Ricardo%20Esteves%20%3cmaverick.pt@gmail.com%3e>>,
users(a)ovirt.org <mailto:users@ovirt.org>
*Subject*: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
*Date*: Sun, 5 Aug 2012 11:18:25 +0300
On Fri, Aug 03, 2012 at 06:47:44AM +1000, Justin Clift wrote:
> On 02/08/2012, at 2:29 AM, Ricardo Esteves wrote:
> > And now, after reboot of the node, i get this:
> >
> > [root@blade4 ~]# virsh capabilities
> > Segmentation fault
>
> When that seg fault happens, does anything get printed to
> /var/log/messages?
>
> Kind of wondering if there's something else at play here,
> which might show up there. Worth a look at. :)
>
> Regards and best wishes,
>
> Justin Clift
Please note that vdsm hacks libvirt to use sasl authentication, which
may be related to this crash.
Does anything look better with `virsh -r`?
6:57 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
On Thu, Aug 09, 2012 at 05:17:14PM +0300, Itamar Heim wrote:
On 08/09/2012 04:17 PM, Ricardo Esteves wrote:
>
>Ok, i fixed the ssl problem, my ovirt manager machine iptables was
>blocking the 8443 port.
>
>I also reinstalled the lastest version of the node
>(ovirt-node-iso-2.5.1-1.0.fc17.iso), but ovirt manager still doesn't
>recognize the CPU.
>
>The host status remains Non Operational :
>
>Host localhost.localdomain moved to Non-Operational state as host does
>not meet the cluster's minimum CPU level. Missing CPU features :
>model_Nehalem
danken - libvirt reports nehalem, yet vdsm reports conroe?
Interesting...
If yo put
<cpu
match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>
in /tmp/cpu.xml
what does
virsh -r cpu-compare /tmp/cpu.xml
report?
7:22 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
[root@blade4 ~]# virsh -r cpu-compare /tmp/cpu.xml
Host CPU is a superset of CPU described in /tmp/cpu.xml
-----Original Message-----
From: Dan Kenigsberg <danken(a)redhat.com>
To: Itamar Heim <iheim(a)redhat.com>, gal(a)redhat.com
Cc: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>, users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Thu, 9 Aug 2012 18:57:29 +0300
On Thu, Aug 09, 2012 at 05:17:14PM +0300, Itamar Heim wrote:
On 08/09/2012 04:17 PM, Ricardo Esteves wrote:
>
>Ok, i fixed the ssl problem, my ovirt manager machine iptables was
>blocking the 8443 port.
>
>I also reinstalled the lastest version of the node
>(ovirt-node-iso-2.5.1-1.0.fc17.iso), but ovirt manager still doesn't
>recognize the CPU.
>
>The host status remains Non Operational :
>
>Host localhost.localdomain moved to Non-Operational state as host does
>not meet the cluster's minimum CPU level. Missing CPU features :
>model_Nehalem
danken - libvirt reports nehalem, yet vdsm reports conroe?
Interesting...
If yo put
<cpu
match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>
in /tmp/cpu.xml
what does
virsh -r cpu-compare /tmp/cpu.xml
report?
2:25 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
On Thu, Aug 09, 2012 at 05:22:09PM +0100, Ricardo Esteves wrote:
[root@blade4 ~]# virsh -r cpu-compare /tmp/cpu.xml
Host CPU is a superset of CPU described in /tmp/cpu.xml
-----Original Message-----
From: Dan Kenigsberg <danken(a)redhat.com>
To: Itamar Heim <iheim(a)redhat.com>, gal(a)redhat.com
Cc: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>, users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Thu, 9 Aug 2012 18:57:29 +0300
On Thu, Aug 09, 2012 at 05:17:14PM +0300, Itamar Heim wrote:
> On 08/09/2012 04:17 PM, Ricardo Esteves wrote:
> >
> >Ok, i fixed the ssl problem, my ovirt manager machine iptables was
> >blocking the 8443 port.
> >
> >I also reinstalled the lastest version of the node
> >(ovirt-node-iso-2.5.1-1.0.fc17.iso), but ovirt manager still doesn't
> >recognize the CPU.
> >
> >The host status remains Non Operational :
> >
> >Host localhost.localdomain moved to Non-Operational state as host does
> >not meet the cluster's minimum CPU level. Missing CPU features :
> >model_Nehalem
>
> danken - libvirt reports nehalem, yet vdsm reports conroe?
Interesting...
If yo put
<cpu
match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>
in /tmp/cpu.xml
what does
virsh -r cpu-compare /tmp/cpu.xml
report?
(top posting make it very difficult to follow a long thread)
I have a hunch that this is something that has been fixed by
http://gerrit.ovirt.org/#/c/5035/
Find vendor for all cpu models, including those based on another
cpu module.
it is accpeted upstream, but unfortunately did not make it into the ovirt-3.1 release.
Could you apply the patch to Vdsm and see if it fixes the reported cpu level?
Dan.
3:55 p.m.
New subject: [Users] oVIrt 3.1 - Network Bonding
Hi,
I the attached picture "net1.jpg" i have my initial network
configuration.
Physical card (em1) with vlan 10 (em1.10) bridged to the ovirtmgmt with
IP 192.168.10.25 and default gw 192.168.10.254.
Now i want to bond em1 card with p1p1 card (attached picture net2.jpg)
But if i fill the default gw it gives me this error: The default gateway
should be set only on engine network.
If i don't fill the default gw, when i click ok, i loose connection to
the server and then after more or less 1 minute the server automaticaly
reboots.
Anyone had this kind of problem?
Best regards,
Ricardo Esteves.
12:56 a.m.
New subject: [Users] oVIrt 3.1 - Network Bonding
On 13/08/2012, at 10:55 PM, Ricardo Esteves wrote:
Hi,
I the attached picture "net1.jpg" i have my initial network configuration.
Physical card (em1) with vlan 10 (em1.10) bridged to the ovirtmgmt with IP 192.168.10.25
and default gw 192.168.10.254.
Now i want to bond em1 card with p1p1 card (attached picture net2.jpg)
But if i fill the default gw it gives me this error: The default gateway should be set
only on engine network.
If i don't fill the default gw, when i click ok, i loose connection to the server and
then after more or less 1 minute the server automaticaly reboots.
Anyone had this kind of problem?
Two thoughts here: ;)
* The "lose connection to the server" bit sort of sounds like
this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=838816
Reckon that's a match?
* Aside from that, you might have to manually configure
networking for the hosts from the command line. Using the
normal Linux commands I mean, not oVirt specific ones.
i.e. creating the bridging and everything manually.
This is the approach I had to take last week when trying
out Aeolus with oVirt 3.1. Network layer breaks when
adding a 2nd interface, but was able to work around it
by manually creating the bridges from cli, after having
defined the logical networks in the oVirt Web UI.
The "configure things manually" approach isn't all that
documented either. I kind of stumbled my way through, by
looking at the examples here:
http://wiki.ovirt.org/wiki/Installing_VDSM_from_rpm#Configuring_the_bridg...
Is any of that helpful?
Regards and best wishes,
Justin Clift
Best regards,
Ricardo Esteves.
--
Aeolus Community Manager
http://www.aeolusproject.org
8:59 a.m.
New subject: [Users] oVIrt 3.1 - Network Bonding
--_000_E3028A1067B0412D83F3DFD15D668622sluse_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
13 aug 2012 kl. 23.56 skrev Justin Clift:
On 13/08/2012, at 10:55 PM, Ricardo Esteves wrote:
Hi,
I the attached picture "net1.jpg" i have my initial network configuration.
Physical card (em1) with vlan 10 (em1.10) bridged to the ovirtmgmt with IP =
192.168.10.25 and default gw 192.168.10.254.
Now i want to bond em1 card with p1p1 card (attached picture net2.jpg)
But if i fill the default gw it gives me this error: The default gateway sh=
ould be set only on engine network.
If i don't fill the default gw, when i click ok, i loose connection to the =
server and then after more or less 1 minute the server automaticaly reboots=
.
Anyone had this kind of problem?
Two thoughts here: ;)
* The "lose connection to the server" bit sort of sounds like
this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=3D838816
Reckon that's a match?
* Aside from that, you might have to manually configure
networking for the hosts from the command line. Using the
normal Linux commands I mean, not oVirt specific ones.
i.e. creating the bridging and everything manually.
This is the approach I had to take last week when trying
out Aeolus with oVirt 3.1. Network layer breaks when
adding a 2nd interface, but was able to work around it
by manually creating the bridges from cli, after having
defined the logical networks in the oVirt Web UI.
The "configure things manually" approach isn't all that
documented either. I kind of stumbled my way through, by
looking at the examples here:
I second that! I just trial and errored my way through bond -> vlan -> brid=
ge. Let=B4s just say that=B4s for people who are up for a challenge. But lu=
ckily, I=B4m one for sharing:
Start by defining to load bonding at boot:
# cat > /etc/modprobe.d/bonding.conf << EOF
alias bond0 bonding
EOF
Then define the bond. This is LACP mode:
# cat > /etc/sysconfig/network-scripts/ifcfg-bond0 << EOF
DEVICE=3Dbond0
NM_CONTROLLED=3Dno
USERCTL=3Dno
BOOTPROTO=3Dnone
BONDING_OPTS=3D"mode=3D4 miimon=3D100"
TYPE=3DEthernet
MTU=3D9000
EOF
Then "enslave" the physical NICs to the bond:
# cat > /etc/sysconfig/network-scripts/ifcfg-em1 << EOF
NM_CONTROLLED=3D"no"
BOOTPROTO=3D"none"
DEVICE=3D"em1"
ONBOOT=3D"yes"
USERCTL=3Dno
MASTER=3Dbond0
SLAVE=3Dyes
EOF
# cat > /etc/sysconfig/network-scripts/ifcfg-em2 << EOF
NM_CONTROLLED=3D"no"
BOOTPROTO=3D"none"
DEVICE=3D"em2"
ONBOOT=3D"yes"
USERCTL=3Dno
MASTER=3Dbond0
SLAVE=3Dyes
EOF
Then create VLAN interfaces ontop of the bond. In this example, I=B4m using=
VLAN ID 1 and 2:
# cat > /etc/sysconfig/network-scripts/ifcfg-bond0.1 << EOF
DEVICE=3Dbond0.1
VLAN=3Dyes
BOOTPROTO=3Dnone
NM_CONTROLLED=3Dno
BRIDGE=3Dbr1
MTU=3D1500
EOF
# cat > /etc/sysconfig/network-scripts/ifcfg-bond0.2 << EOF
DEVICE=3Dbond0.2
VLAN=3Dyes
BOOTPROTO=3Dnone
NM_CONTROLLED=3Dno
BRIDGE=3Dovirtmgmt
MTU=3D9000
EOF
Lastly, create the bridges ontop of the VLAN interfaces. The names, as I ha=
ve understood it, can be whatever you want, but one needs to be called "ovi=
rtmgmt" of course:
# cat > /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt << EOF
TYPE=3DBridge
NM_CONTROLLED=3D"no"
BOOTPROTO=3D"none"
DEVICE=3D"ovirtmgmt"
ONBOOT=3D"yes"
IPADDR=3DXXX.XXX.XXX.XXX
NETMASK=3D255.255.255.0
EOF
# cat > /etc/sysconfig/network-scripts/ifcfg-br0 << EOF
TYPE=3DBridge
NM_CONTROLLED=3D"no"
BOOTPROTO=3D"none"
DEVICE=3D"br0"
ONBOOT=3D"yes"
IPADDR=3DXXX.XXX.XXX.XXX
NETMASK=3D255.255.255.0
EOF
Gateway goes into:
# cat > /etc/sysconfig/network << EOF
GATEWAY=3DXXX.XXX.XXX.XXX
EOF
This way, you can have almost(4096) as many interfaces as you want with onl=
y two physical NICs. I also gave an example on how you tune Jumbo Frames to=
be active on some interfaces, and have regular windows size on the rest. J=
umbo most only be active on interfaces that isn=B4t routed, since the defau=
lt routing size is 1500.
/Karli
http://wiki.ovirt.org/wiki/Installing_VDSM_from_rpm#Configuring_the_bridge=
_Interface
Is any of that helpful?
Regards and best wishes,
Justin Clift
Best regards,
Ricardo Esteves.
--
Aeolus Community Manager
http://www.aeolusproject.org
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Med V=E4nliga H=E4lsningar
---------------------------------------------------------------------------=
----
Karli Sj=F6berg
Swedish University of Agricultural Sciences
Box 7079 (Visiting Address Kron=E5sv=E4gen 8)
S-750 07 Uppsala, Sweden
Phone: +46-(0)18-67 15 66
karli.sjoberg@slu.se<mailto:karli.sjoberg@adm.slu.se>
--_000_E3028A1067B0412D83F3DFD15D668622sluse_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html><head></head><body style=3D"word-wrap: break-word;
-webkit-nbsp-mode:=
space; -webkit-line-break: after-white-space;
"><br><div><div>13 aug 2012 =
kl. 23.56 skrev Justin Clift:</div><br
class=3D"Apple-interchange-newline">=
<blockquote type=3D"cite"><div>On 13/08/2012, at 10:55 PM, Ricardo
Esteves =
wrote:<br><blockquote
type=3D"cite">Hi,<br></blockquote><blockquote type=3D=
"cite"><br></blockquote><blockquote
type=3D"cite">I the attached picture "n=
et1.jpg" i have my initial network
configuration.<br></blockquote><blockquo=
te type=3D"cite"><br></blockquote><blockquote
type=3D"cite">Physical card (=
em1) with vlan 10 (em1.10) bridged to the ovirtmgmt with IP 192.168.10.25 a=
nd default gw 192.168.10.254. <br></blockquote><blockquote
type=3D"cite"><b=
r></blockquote><blockquote type=3D"cite">Now i want to bond em1
card with p=
1p1 card (attached picture net2.jpg)<br></blockquote><blockquote
type=3D"ci=
te"><br></blockquote><blockquote type=3D"cite">But if
i fill the default gw=
it gives me this error: The default gateway should be set only on engine n=
etwork.<br></blockquote><blockquote
type=3D"cite"><br></blockquote><blockqu=
ote type=3D"cite">If i don't fill the default gw, when i click ok, i
loose =
connection to the server and then after more or less 1 minute the server au=
tomaticaly reboots.<br></blockquote><blockquote
type=3D"cite"><br></blockqu=
ote><blockquote type=3D"cite">Anyone had this kind of
problem?<br></blockqu=
ote><br>Two thoughts here: ;)<br><br> * The "lose connection to
the server"=
bit sort of sounds like<br> this bug:<br><br>
&nbs=
p; <a
href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D838816"&g...
tps://bugzilla.redhat.com/show_bug.cgi?id=3D838816</a><br><...
=
Reckon that's a match?<br><br><br> * Aside from that, you might have
to man=
ually configure<br> networking for the hosts from the command
l=
ine. Using the<br> normal Linux commands I mean, not
oVir=
t specific ones.<br><br> i.e. creating
the bridging=
and everything manually.<br><br> This is the approach I
had to=
take last week when trying<br> out Aeolus with oVirt 3.1.
&nbs=
p;Network layer breaks when<br> adding a 2nd interface, but
was=
able to work around it<br> by manually creating the bridges
fr=
om cli, after having<br> defined the logical networks in the
oV=
irt Web UI.<br><br>The "configure things manually" approach
isn't all that<=
br>documented either. I kind of stumbled my way through, by<br>lookin=
g at the examples
here:<br></div></blockquote><div><br></div>I second
that!=
I just trial and errored my way through bond -> vlan -> bridge. Let=
=B4s just say that=B4s for people who are up for a challenge. But luckily, =
I=B4m one for sharing:</div><div><br></div><div>Start by
defining to load b=
onding at boot:</div><div><div># cat >
/etc/modprobe.d/bonding.conf <=
< EOF</div><div>alias bond0
bonding</div><div><br></div><div>EOF</div><d=
iv><br></div><div>Then define the bond. This is LACP
mode:</div><div><div>#=
cat > /etc/sysconfig/network-scripts/ifcfg-bond0 <<
EOF</div><div=
<div>DEVICE=3Dbond0</div><div>NM_CONTROLLED=3Dno</div><div>USERCTL=3Dno</d=
iv><div>BOOTPROTO=3Dnone</div><div>BONDING_OPTS=3D"mode=3D4
miimon=3D100"</=
div><div>TYPE=3DEthernet</div><div>MTU=3D9000</div></div><div><br></div><di=
v>EOF</div><div><br></div><div>Then "enslave"
the physical NICs to the bond=
:</div><div><div># cat > /etc/sysconfig/network-scripts/ifcfg-em1
<&l=
t;
EOF</div><div><div>NM_CONTROLLED=3D"no"</div><div>BOOTPROTO=3D"none"</di=
v><div>DEVICE=3D"em1"</div><div>ONBOOT=3D"yes"</div><div>USERCTL=3Dno</div>=
<div>MASTER=3Dbond0</div><div>SLAVE=3Dyes</div><div><br></div></div><div>EO=
F</div><div><br></div><div><div># cat >
/etc/sysconfig/network-scripts/i=
fcfg-em2 <<
EOF</div><div><div>NM_CONTROLLED=3D"no"</div><div>BOOTPRO=
TO=3D"none"</div><div>DEVICE=3D"em2"</div><div>ONBOOT=3D"yes"</div><div>USE=
RCTL=3Dno</div><div>MASTER=3Dbond0</div><div>SLAVE=3Dyes</div><div><br></di=
v></div><div>EOF</div><div><br></div><div>Then
create VLAN interfaces ontop=
of the bond. In this example, I=B4m using VLAN ID 1 and
2:</div><div><div>=
# cat
> /etc/sysconfig/network-scripts/ifcfg-bond0.1 <<
=
EOF</div><div><div><div>DEVICE=3Dbond0.1</div><div>VLAN=3Dyes</div><div>BOO=
TPROTO=3Dnone</div><div>NM_CONTROLLED=3Dno</div><div>BRIDGE=3Dbr1</div><div=
MTU=3D1500</div></div><div><br></div></div><div>EOF</div><div><br></div><d=
iv><div># cat
> /etc/sysconfig/network-scripts/ifcfg-bond0.2 <&l=
t;
EOF</div><div><div><div>DEVICE=3Dbond0.2</div><div>VLAN=3Dyes</div><div>=
BOOTPROTO=3Dnone</div><div>NM_CONTROLLED=3Dno</div><div>BRIDGE=3Dovirtmgmt<=
/div><div>MTU=3D9000</div></div><div><br></div></div><div>EOF</div><div><br=
</div><div>Lastly, create the bridges ontop of the VLAN
interfaces. The na=
mes, as I have understood it, can be whatever you want, but one
needs to be=
called "ovirtmgmt" of course:</div><div><div># cat
> /etc/sysconfi=
g/network-scripts/ifcfg-ovirtmgmt <<
EOF</div><div><div><div><div>TYP=
E=3DBridge</div><div>NM_CONTROLLED=3D"no"</div><div>BOOTPROTO=3D"none"</div=
<div>DEVICE=3D"ovirtmgmt"</div><div>ONBOOT=3D"yes"</div><div>IPADDR=3DXXX.=
XXX.XXX.XXX</div><div>NETMASK=3D255.255.255.0</div></div></div><div><br></d=
iv></div><div>EOF</div><div><br></div><div><div>#
cat > /etc/syscon=
fig/network-scripts/ifcfg-br0 <<
EOF</div><div><div><div><div>TYPE=3D=
Bridge</div><div>NM_CONTROLLED=3D"no"</div><div>BOOTPROTO=3D"none"</div><di=
v>DEVICE=3D"br0"</div><div>ONBOOT=3D"yes"</div><div>IPADDR=3DXXX.XXX.XXX.XX=
X</div><div>NETMASK=3D255.255.255.0</div></div></div><div><br></div></div><=
div>EOF</div><div><br></div><div>Gateway goes
into:</div><div><div><span cl=
ass=3D"Apple-style-span"># cat
> </span>/etc/sysconfig/network<span=
class=3D"Apple-style-span"> <<
EOF</span></div><div>GATEWAY=3DX=
XX.XXX.XXX.XXX</div><div><br></div><div>EOF</div></div><div><br></div><div>=
This way, you can have almost(4096) as many interfaces as you want with onl=
y two physical NICs. I also gave an example on how you tune Jumbo Frames to=
be active on some interfaces, and have regular windows size on the rest. J=
umbo most only be active on interfaces that isn=B4t routed, since the defau=
lt routing size is
1500.</div><div><br></div><div>/Karli</div><div><br></di=
v></div></div></div></div></div></div></div><blockquote
type=3D"cite"><div>=
<br> <a
href=3D"http://wiki.ovirt.org/wiki/Installing_VDSM_from_rpm#C=
onfiguring_the_bridge_Interface">http://wiki.ovirt.org/wiki/Insta...
_from_rpm#Configuring_the_bridge_Interface</a><br><br>Is any of that
helpfu=
l?<br><br>Regards and best wishes,<br><br>Justin
Clift<br><br><br><blockquo=
te type=3D"cite">Best regards,<br></blockquote><blockquote
type=3D"cite">Ri=
cardo Esteves.<br></blockquote><br>--<br>Aeolus Community
Manager<br><a hre=
f=3D"http://www.aeolusproject.org">http://www.aeolusproject.org</a><br><br>=
_______________________________________________<br>Users mailing list<br>Us=
ers@ovirt.org<br>http://lists.ovirt.org/mailman/listinfo/users<br></div></b=
lockquote></div><br><div>
<div><br
class=3D"Apple-interchange-newline"><br></div><div>Med
V=E4nliga H=
=E4lsningar<br>------------------------------------------------------------=
-------------------<br>Karli Sj=F6berg<br>Swedish University of Agricultura=
l Sciences<br>Box 7079 (Visiting Address Kron=E5sv=E4gen 8)<br>S-750 07 Upp=
sala, Sweden<br>Phone: +46-(0)18-67 15 66</div><div><a
href=3D"mailto=
:karli.sjoberg@adm.slu.se">karli.sjoberg@slu.se</a></div>
</div>
<br></body></html>=
--_000_E3028A1067B0412D83F3DFD15D668622sluse_--
9:30 a.m.
New subject: [Users] oVIrt 3.1 - Network Bonding
On 14/08/2012, at 3:59 PM, Karli Sjöberg wrote:
<snip>
This way, you can have almost(4096) as many interfaces as you want
with only two physical NICs. I also gave an example on how you tune Jumbo Frames to be
active on some interfaces, and have regular windows size on the rest. Jumbo most only be
active on interfaces that isn´t routed, since the default routing size is 1500.
Oooohhh Aaaahhh... that's really nicely written out. :)
Could you be convinced to make a wiki page for it?
(just hoping :>)
Regards and best wishes,
Justin Clift
--
Aeolus Community Manager
http://www.aeolusproject.org
9:33 a.m.
New subject: [Users] oVIrt 3.1 - Network Bonding
--_000_38DC2C5444574217A831EFC7E3BFC077sluse_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
14 aug 2012 kl. 08.30 skrev Justin Clift:
On 14/08/2012, at 3:59 PM, Karli Sj=F6berg wrote:
<snip>
This way, you can have almost(4096) as many interfaces as you want with onl=
y two physical NICs. I also gave an example on how you tune Jumbo Frames to=
be active on some interfaces, and have regular windows size on the rest. J=
umbo most only be active on interfaces that isn=B4t routed, since the defau=
lt routing size is 1500.
Oooohhh Aaaahhh... that's really nicely written out. :)
Could you be convinced to make a wiki page for it?
DIY? It=B4s just copy-pasting the instructions basically, but I would be ho=
nored to have contributed:)
(just hoping :>)
Regards and best wishes,
Justin Clift
--
Aeolus Community Manager
http://www.aeolusproject.org
Med V=E4nliga H=E4lsningar
---------------------------------------------------------------------------=
----
Karli Sj=F6berg
Swedish University of Agricultural Sciences
Box 7079 (Visiting Address Kron=E5sv=E4gen 8)
S-750 07 Uppsala, Sweden
Phone: +46-(0)18-67 15 66
karli.sjoberg@slu.se<mailto:karli.sjoberg@adm.slu.se>
--_000_38DC2C5444574217A831EFC7E3BFC077sluse_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html><head></head><body style=3D"word-wrap: break-word;
-webkit-nbsp-mode:=
space; -webkit-line-break: after-white-space;
"><br><div><div>14 aug 2012 =
kl. 08.30 skrev Justin Clift:</div><br
class=3D"Apple-interchange-newline">=
<blockquote type=3D"cite"><div>On 14/08/2012, at 3:59 PM, Karli
Sj=F6berg w=
rote:<br><snip><br><blockquote
type=3D"cite">This way, you can have a=
lmost(4096) as many interfaces as you want with only two physical NICs. I a=
lso gave an example on how you tune Jumbo Frames to be active on some inter=
faces, and have regular windows size on the rest. Jumbo most only be active=
on interfaces that isn=B4t routed, since the default routing size is 1500.=
<br></blockquote><br>Oooohhh Aaaahhh... that's really nicely written
out. :=
)<br><br>Could you be convinced to make a wiki page for
it?<br></div></bloc=
kquote><div><br></div>DIY? It=B4s just copy-pasting the instructions
basica=
lly, but I would be honored to have
contributed:)</div><div><br><blockquote=
type=3D"cite"><div><br>(just hoping
:>)<br><br>Regards and best wishes,=
<br><br>Justin Clift<br><br>--<br>Aeolus Community
Manager<br><a href=3D"ht=
tp://www.aeolusproject.org">http://www.aeolusproject.org</a><br><br></div><=
/blockquote></div><br><div>
<span class=3D"Apple-style-span" style=3D"border-collapse: separate;
color:=
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: no=
rmal; font-weight: normal; letter-spacing: normal; line-height: normal; orp=
hans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizonta=
l-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorati=
ons-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-wi=
dth: 0px; font-size: medium; "><div><br
class=3D"Apple-interchange-newline"=
<br></div><div>Med V=E4nliga
H=E4lsningar<br>-----------------------------=
--------------------------------------------------<br>Karli
Sj=F6berg<br>Sw=
edish University of Agricultural Sciences<br>Box 7079 (Visiting Address Kro=
n=E5sv=E4gen 8)<br>S-750 07 Uppsala, Sweden<br>Phone: +46-(0)18-67
15=
66</div><div><a
href=3D"mailto:karli.sjoberg@adm.slu.se">karli.sjoberg@slu=
.se</a></div></span>
</div>
<br></body></html>=
--_000_38DC2C5444574217A831EFC7E3BFC077sluse_--
10:14 a.m.
New subject: [Users] oVIrt 3.1 - Network Bonding
Hi,
There was a bug about this issue before which is solved:
https://bugzilla.redhat.com/show_bug.cgi?id=820989
Which version are you using ? Is it built from source or installed from
rpms ?
A simple test to verify if this fix included is to create the management
network (ovirtmgmt) over a nic with static boot protocol (also provide
ip, subnet mask and gateway).
Than via the Setup Networks drag another nic on top of the management
nic. If it fails for the same reason (NETWORK_ATTACH_ILLEGAL_GATEWAY) -
your version doesn't include that fix. If this scenario does work -
there is a potentially bug.
Note that the you shouldn't modify the management network bridge
connectivity details (meaning use the same ip, subnet mask and gateway).
I think this topic is entitled to its own thread as it was concealed in
a long unrelated thread.
Thanks,
Moti
On 08/13/2012 03:55 PM, Ricardo Esteves wrote:
Hi,
I the attached picture "net1.jpg" i have my initial network configuration.
Physical card (em1) with vlan 10 (em1.10) bridged to the ovirtmgmt with
IP 192.168.10.25 and default gw 192.168.10.254.
Now i want to bond em1 card with p1p1 card (attached picture net2.jpg)
But if i fill the default gw it gives me this error: The default gateway
should be set only on engine network.
If i don't fill the default gw, when i click ok, i loose connection to
the server and then after more or less 1 minute the server automaticaly
reboots.
Anyone had this kind of problem?
Best regards,
Ricardo Esteves.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
12:23 a.m.
New subject: [Users] oVIrt 3.1 - Network Bonding
On 14/08/2012, at 5:14 PM, Moti Asayag wrote:
There was a bug about this issue before which is solved:
https://bugzilla.redhat.com/show_bug.cgi?id=820989
This bug may be what Karli hit. It's almost definitely
not what I hit though. For my setup, already had the
ovirtmgmt interface in place (static), and was attempting
to add a new logical network on another interface. Wasn't
attempting to touch ovirtmgmt logical network at all.
Not sure if that helps.
+ Justin
--
Aeolus Community Manager
http://www.aeolusproject.org
7 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
On Thu, Aug 09, 2012 at 02:17:44PM +0100, Ricardo Esteves wrote:
Ok, i fixed the ssl problem, my ovirt manager machine iptables was
blocking the 8443 port.
Neither issue is a good-enough reason for virsh to segfault. Could you
provide more information so that some can solve that bug?
7:31 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Now it's difficult to reproduce the problem, unless i install the host
again.
The problem seemed to be, when i configured the ovirt engine options on
the host it failed to download the certificate because port 8443 was
blocked on ovirt engine machine.
virsh -r capabilites worked ok at that time
but
virsh capabilites crashed with segfault
-----Original Message-----
From: Dan Kenigsberg <danken(a)redhat.com>
To: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>, Justin Clift
<jclift(a)redhat.com>
Cc: Itamar Heim <iheim(a)redhat.com>, users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Thu, 9 Aug 2012 19:00:42 +0300
On Thu, Aug 09, 2012 at 02:17:44PM +0100, Ricardo Esteves wrote:
Ok, i fixed the ssl problem, my ovirt manager machine iptables was
blocking the 8443 port.
Neither issue is a good-enough reason for virsh to segfault. Could you
provide more information so that some can solve that bug?
1:18 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Ok, i reinstalled the host to try to reproduce the problem.
I blocked again the 8443 on ovirt manager machine.
Configured the ovirt engine options on the host and gave me the error
that couldn't download the certificate.
I run virsh capabilities and worked ok.
Then i rebooted the host and now when i run virsh capabilities it gives
me segfault.
On dmesg i get this message:
virsh -r capabilities runs ok.
-----Original Message-----
From: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>
To: Dan Kenigsberg <danken(a)redhat.com>
Cc: Justin Clift <jclift(a)redhat.com>, Itamar Heim <iheim(a)redhat.com>,
users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Thu, 09 Aug 2012 17:31:30 +0100
Now it's difficult to reproduce the problem, unless i install the host
again.
The problem seemed to be, when i configured the ovirt engine options on
the host it failed to download the certificate because port 8443 was
blocked on ovirt engine machine.
virsh -r capabilites worked ok at that time
but
virsh capabilites crashed with segfault
-----Original Message-----
From: Dan Kenigsberg <danken(a)redhat.com>
To: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>, Justin Clift
<jclift(a)redhat.com>
Cc: Itamar Heim <iheim(a)redhat.com>, users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Thu, 9 Aug 2012 19:00:42 +0300
On Thu, Aug 09, 2012 at 02:17:44PM +0100, Ricardo Esteves wrote:
Ok, i fixed the ssl problem, my ovirt manager machine iptables was
blocking the 8443 port.
Neither issue is a good-enough reason for virsh to segfault. Could you
provide more information so that some can solve that bug?
7:32 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
And now, after reboot of the node, i get this:
[root@blade4 ~]# virsh capabilities
Segmentation fault
-
----Original Message-----
From: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>
To: Itamar Heim <iheim(a)redhat.com>
Cc: users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Wed, 01 Aug 2012 16:52:11 +0100
I didn't disabled anything, but after installing the node when i
configure the option "oVirt Engine" it gives an error saying it can't
download the certificate, but i had this error with previous versions of
the node, and it detected ok the CPU family.
This is the output after a fresh install of the node:
[root@blade4 ~]# vdsClient -s 0 getVdsCaps | grep -i flags
Traceback (most recent call last):
File "/usr/share/vdsm/vdsClient.py", line 2275, in <module>
File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders
File "/usr/lib64/python2.7/httplib.py", line 814, in _send_output
File "/usr/lib64/python2.7/httplib.py", line 776, in send
File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
line 91, in connect
File "/usr/lib64/python2.7/socket.py", line 553, in create_connection
gaierror: [Errno -2] Name or service not known
[root@blade4 ~]# virsh capabilities
<capabilities>
<host>
<uuid>35303737-3830-435a-4a30-30333035455a</uuid>
<cpu>
<arch>x86_64</arch>
<model>Nehalem</model>
<vendor>Intel</vendor>
<topology sockets='1' cores='4' threads='2'/>
<feature name='rdtscp'/>
<feature name='dca'/>
<feature name='pdcm'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/>
<feature name='ds_cpl'/>
<feature name='monitor'/>
<feature name='dtes64'/>
<feature name='pbe'/>
<feature name='tm'/>
<feature name='ht'/>
<feature name='ss'/>
<feature name='acpi'/>
<feature name='ds'/>
<feature name='vme'/>
</cpu>
<power_management/>
<migration_features>
<live/>
<uri_transports>
<uri_transport>tcp</uri_transport>
</uri_transports>
</migration_features>
<topology>
<cells num='1'>
<cell id='0'>
<cpus num='8'>
<cpu id='0'/>
<cpu id='1'/>
<cpu id='2'/>
<cpu id='3'/>
<cpu id='4'/>
<cpu id='5'/>
<cpu id='6'/>
<cpu id='7'/>
</cpus>
</cell>
</cells>
</topology>
<secmodel>
<model>selinux</model>
<doi>0</doi>
</secmodel>
</host>
<guest>
<os_type>hvm</os_type>
<arch name='i686'>
<wordsize>32</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<pae/>
<nonpae/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
<guest>
<os_type>hvm</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
</capabilities>
When i add the host to oVirt i get this message:
Host blade4.vi.pt moved to Non-Operational state as host does not meet
the cluster's minimum CPU level. Missing CPU features : model_Nehalem
Best regards,
Ricardo Esteves.
-----Original Message-----
From: Itamar Heim <iheim(a)redhat.com>
To: Ricardo Esteves <ricardo.m.esteves(a)gmail.com>
Cc: users(a)ovirt.org
Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Date: Wed, 01 Aug 2012 15:43:22 +0300
On 08/01/2012 02:28 PM, Ricardo Esteves wrote:
[root@blade4 <mailto:root@blade4> ~]# vdsClient -s 0 getVdsCaps | grep
-i flags
Traceback (most recent call last):
File "/usr/share/vdsm/vdsClient.py", line 2275, in <module>
File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders
File "/usr/lib64/python2.7/httplib.py", line 814, in _send_output
File "/usr/lib64/python2.7/httplib.py", line 776, in send
File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
line 98, in connect
File "/usr/lib64/python2.7/ssl.py", line 381, in wrap_socket
File "/usr/lib64/python2.7/ssl.py", line 141, in __init__
SSLError: [Errno 0] _ssl.c:340: error:00000000:lib(0):func(0):reason(0)
did you somehow disable ssl?
is vdsm running?
what's its status in engine?
what does this return:
virsh capabilities | grep model
-----Original Message-----
*From*: Itamar Heim <iheim(a)redhat.com
<mailto:Itamar%20Heim%20%3ciheim@redhat.com%3e>>
*To*: Ricardo Esteves <ricardo.m.esteves(a)gmail.com
<mailto:Ricardo%20Esteves%20%3cricardo.m.esteves@gmail.com%3e>>
*Cc*: users(a)ovirt.org <mailto:users@ovirt.org>
*Subject*: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
*Date*: Wed, 01 Aug 2012 13:59:27 +0300
On 08/01/2012 12:57 PM, Ricardo Esteves wrote:
> Hi,
>
> With the latest version of ovirt my host's CPU is not correctly identified,
> my host's have an Intel Xeon E5530 (Nehalem family), but is being identified as
Conrad family.
>
> My installed versions:
>
> ovirt-engine-3.1.0-2.fc17.noarch
> ovirt-node-iso-2.5.0-2.0.fc17.iso
>
>
> Best regards,
> Ricardo Esteves.
>
>
>
> _______________________________________________
> Users mailing list
>Users(a)ovirt.org <mailto:Users@ovirt.org>
>http://lists.ovirt.org/mailman/listinfo/users
>
please share:
vdsClient -s 0 getVdsCaps | grep -i flags
8:26 p.m.
New subject: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
Oh, sorry to hear that, that doesn't sound good.
What did change on the server with reboot? I wonder how this is possible.
Martin
On 08/01/2012 06:32 PM, Ricardo Esteves wrote:
And now, after reboot of the node, i get this:
[root@blade4 <mailto:root@blade4> ~]# virsh capabilities
Segmentation fault
-
----Original Message-----
*From*: Ricardo Esteves <ricardo.m.esteves(a)gmail.com
<mailto:Ricardo%20Esteves%20%3cricardo.m.esteves@gmail.com%3e>>
*To*: Itamar Heim <iheim(a)redhat.com
<mailto:Itamar%20Heim%20%3ciheim@redhat.com%3e>>
*Cc*: users(a)ovirt.org <mailto:users@ovirt.org>
*Subject*: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
*Date*: Wed, 01 Aug 2012 16:52:11 +0100
I didn't disabled anything, but after installing the node when i
configure the option "oVirt Engine" it gives an error saying it can't
download the certificate, but i had this error with previous versions of
the node, and it detected ok the CPU family.
This is the output after a fresh install of the node:
[root@blade4 <mailto:root@blade4> ~]# vdsClient -s 0 getVdsCaps | grep
-i flags
Traceback (most recent call last):
File "/usr/share/vdsm/vdsClient.py", line 2275, in <module>
File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders
File "/usr/lib64/python2.7/httplib.py", line 814, in _send_output
File "/usr/lib64/python2.7/httplib.py", line 776, in send
File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
line 91, in connect
File "/usr/lib64/python2.7/socket.py", line 553, in create_connection
gaierror: [Errno -2] Name or service not known
[root@blade4 <mailto:root@blade4> ~]# virsh capabilities
<capabilities>
<host>
<uuid>35303737-3830-435a-4a30-30333035455a</uuid>
<cpu>
<arch>x86_64</arch>
<model>Nehalem</model>
<vendor>Intel</vendor>
<topology sockets='1' cores='4' threads='2'/>
<feature name='rdtscp'/>
<feature name='dca'/>
<feature name='pdcm'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/>
<feature name='ds_cpl'/>
<feature name='monitor'/>
<feature name='dtes64'/>
<feature name='pbe'/>
<feature name='tm'/>
<feature name='ht'/>
<feature name='ss'/>
<feature name='acpi'/>
<feature name='ds'/>
<feature name='vme'/>
</cpu>
<power_management/>
<migration_features>
<live/>
<uri_transports>
<uri_transport>tcp</uri_transport>
</uri_transports>
</migration_features>
<topology>
<cells num='1'>
<cell id='0'>
<cpus num='8'>
<cpu id='0'/>
<cpu id='1'/>
<cpu id='2'/>
<cpu id='3'/>
<cpu id='4'/>
<cpu id='5'/>
<cpu id='6'/>
<cpu id='7'/>
</cpus>
</cell>
</cells>
</topology>
<secmodel>
<model>selinux</model>
<doi>0</doi>
</secmodel>
</host>
<guest>
<os_type>hvm</os_type>
<arch name='i686'>
<wordsize>32</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<pae/>
<nonpae/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
<guest>
<os_type>hvm</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine>pc-0.15</machine>
<machine>pc-1.0</machine>
<machine canonical='pc-1.0'>pc</machine>
<machine>pc-0.14</machine>
<machine>pc-0.13</machine>
<machine>pc-0.12</machine>
<machine>pc-0.11</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
</capabilities>
When i add the host to oVirt i get this message:
Host blade4.vi.pt moved to Non-Operational state as host does not meet
the cluster's minimum CPU level. Missing CPU features : model_Nehalem
Best regards,
Ricardo Esteves.
-----Original Message-----
*From*: Itamar Heim <iheim(a)redhat.com
<mailto:Itamar%20Heim%20%3ciheim@redhat.com%3e>>
*To*: Ricardo Esteves <ricardo.m.esteves(a)gmail.com
<mailto:Ricardo%20Esteves%20%3cricardo.m.esteves@gmail.com%3e>>
*Cc*: users(a)ovirt.org <mailto:users@ovirt.org>
*Subject*: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
*Date*: Wed, 01 Aug 2012 15:43:22 +0300
On 08/01/2012 02:28 PM, Ricardo Esteves wrote:
>
> [root@blade4 <mailto:root@blade4> ~]# vdsClient -s 0 getVdsCaps | grep
> -i flags
> Traceback (most recent call last):
> File "/usr/share/vdsm/vdsClient.py", line 2275, in <module>
> File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
> File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
> File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
> File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
> File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
> File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
> File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders
> File "/usr/lib64/python2.7/httplib.py", line 814, in _send_output
> File "/usr/lib64/python2.7/httplib.py", line 776, in send
> File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
> line 98, in connect
> File "/usr/lib64/python2.7/ssl.py", line 381, in wrap_socket
> File "/usr/lib64/python2.7/ssl.py", line 141, in __init__
> SSLError: [Errno 0] _ssl.c:340: error:00000000:lib(0):func(0):reason(0)
did you somehow disable ssl?
is vdsm running?
what's its status in engine?
what does this return:
virsh capabilities | grep model
>
> -----Original Message-----
> *From*: Itamar Heim <iheim(a)redhat.com <mailto:iheim@redhat.com>
> <mailto:Itamar%20Heim%20%3ciheim@redhat.com%3e>>
> *To*: Ricardo Esteves <ricardo.m.esteves(a)gmail.com
<mailto:ricardo.m.esteves@gmail.com>
> <mailto:Ricardo%20Esteves%20%3cricardo.m.esteves@gmail.com%3e>>
> *Cc*: users(a)ovirt.org <mailto:users@ovirt.org> <mailto:users@ovirt.org>
> *Subject*: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
> *Date*: Wed, 01 Aug 2012 13:59:27 +0300
>
> On 08/01/2012 12:57 PM, Ricardo Esteves wrote:
>> Hi,
>>
>> With the latest version of ovirt my host's CPU is not correctly identified,
>> my host's have an Intel Xeon E5530 (Nehalem family), but is being identified
as Conrad family.
>>
>> My installed versions:
>>
>> ovirt-engine-3.1.0-2.fc17.noarch
>> ovirt-node-iso-2.5.0-2.0.fc17.iso
>>
>>
>> Best regards,
>> Ricardo Esteves.
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>>Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org>
>>http://lists.ovirt.org/mailman/listinfo/users
>>
>
> please share:
> vdsClient -s 0 getVdsCaps | grep -i flags
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4429
days inactive
4545
days old
45 comments
14 participants
participants (14)
-
Alan Johnson -
Ayal Baron -
Dan Kenigsberg -
Fabian Deutsch -
Itamar Heim -
Johan Kragsterman -
Justin Clift -
Karli Sjöberg -
Martin Kletzander -
Meni Yakvoe -
Moti Asayag -
Nicholas Kesick -
Ricardo Esteves -
Ricardo Esteves