January 2016 - Users - oVirt List Archives

Re: [ovirt-users] host status "Non Operational" - how to diagnose & fix?
by Karli Sjöberg 03 Jan '16

03 Jan '16

--_000_d073628bd7264472a089d77e6921e2acemailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMyBqYW4uIDIwMTYgMjo0MyBmbSBza3JldiBXaWxsIERlbm5pcyA8d2Rlbm5pc0BuZWMt bGFicy5jb20+Og0KPg0KPiBUaGUg4oCYb3ZpcnRtZ2104oCZIG5ldHdvcmsgaGFzIGJlZW4gJiBp cyBzdGlsbCBwbGFjZWQgb24gYSB3b3JraW5nIE5JQyAoZW5wMTJzMGYwKeKApiBJdOKAmXMganVz dCB0aGF0IG5vdywgb1ZpcnQgc29tZWhvdyBkb2VzbuKAmXQgKnRoaW5rKiBpdOKAmXMgd29ya2lu Z+KApg0KDQpIZXJlJ3Mgc29tZXRoaW5nIEkgd3JvdGUgYSBsb25nIHRpbWUgYWdvIG5vdywgZm9y IHRob3NlIHRpbWVzIHdoZW4gYXV0by1ndWktY29uZmlnIGZsdWZmIGp1c3Qgd29uJ3QgZG86DQoN Cmh0dHA6Ly93d3cub3ZpcnQub3JnL0JvbmRpbmdfVkxBTl9CcmlkZ2UNCg0KL0sNCj4NCj4gaHR0 cDovL3MxMDk2LnBob3RvYnVja2V0LmNvbS91c2VyL3dpbGxkZW5uaXMvbWVkaWEvc2V0dXAtbmV0 d29ya3MucG5nLmh0bWwNCj4NCj4gSG93ZXZlciwgYXMgSSBzaG93ZWQgeW91IGluIHRoZSDigJhp cCBsaW5rIHNob3cgdXDigJkgb3V0cHV0LCBpdCBpcyBpbmRlZWQgdXAgYW5kIHdvcmtpbmcuDQo+ DQo+DQo+DQo+DQo+IE9uIEphbiAyLCAyMDE2LCBhdCA4OjAwIFBNLCBSb3kgR29sYW4gPHJnb2xh bkByZWRoYXQuY29tPG1haWx0bzpyZ29sYW5AcmVkaGF0LmNvbT4+IHdyb3RlOg0KPg0KPg0KPg0K PiBPbiBTdW4sIEphbiAzLCAyMDE2IGF0IDI6NDYgQU0sIFdpbGwgRGVubmlzIDx3ZGVubmlzQG5l Yy1sYWJzLmNvbTxtYWlsdG86d2Rlbm5pc0BuZWMtbGFicy5jb20+PiB3cm90ZToNCj4gSSBoYXZl IGhhZCBvbmUgb2YgbXkgaG9zdHMgZ28gaW50byB0aGUgc3RhdGUg4oCcTm9uIE9wZXJhdGlvbmFs 4oCdIGFmdGVyIEkgcmVib290ZWQgaXTigKYgSSBhbHNvIG5vdGljZWQgdGhhdCBpbiB0aGUgb1Zp cnQgd2ViYWRtaW4gVUksIHRoZSBOSUMgdGhhdOKAmXMgdXNlZCBpbiB0aGUg4oCYb3ZpcnRtZ210 4oCZIG5ldHdvcmsgaXMgc2hvd2luZyDigJxkb3du4oCdLCBidXQgaW4gTGludXggdGhlIE5JQyBp cyBvcGVyYXRpb25hbCBhbmQgdXAsIGFzIGlzIHRoZSDigJhvdmlydG1nbXTigJkgYnJpZGdl4oCm DQo+DQo+DQo+IEhvc3RzIHRhYiAtPiBOZXR3b3JrIEludGVyZmFjZXMgc3VidGFiIC0+IGNsaWNr ICJTZXR1cCBuZXR3b3JrcyIgYW5kIG1ha2Ugc3VyZSAib3ZpcnRtZ210IiBpcyBwbGFjZWQgb24g YSB3b3JraW5nIG5pYy4NCj4NCj4gbWFrZSBzdXJlDQo+IFtyb290QG92aXJ0LW5vZGUtMDIgfl0j IGlwIGxpbmsgc2ggdXANCj4gMTogbG86IDxMT09QQkFDSyxVUCxMT1dFUl9VUD4gbXR1IDY1NTM2 IHFkaXNjIG5vcXVldWUgc3RhdGUgVU5LTk9XTiBtb2RlIERFRkFVTFQNCj4gICAgIGxpbmsvbG9v cGJhY2sgMDA6MDA6MDA6MDA6MDA6MDAgYnJkIDAwOjAwOjAwOjAwOjAwOjAwDQo+IDI6IGJvbmQw OiA8Tk8tQ0FSUklFUixCUk9BRENBU1QsTVVMVElDQVNULE1BU1RFUixVUD4gbXR1IDE1MDAgcWRp c2Mgbm9xdWV1ZSBzdGF0ZSBET1dOIG1vZGUgREVGQVVMVA0KPiAgICAgbGluay9ldGhlciAwMDox NToxNzo3YjplOTpiMCBicmQgZmY6ZmY6ZmY6ZmY6ZmY6ZmYNCj4gMzogZW5wNHMwZjA6IDxOTy1D QVJSSUVSLEJST0FEQ0FTVCxNVUxUSUNBU1QsU0xBVkUsVVA+IG10dSAxNTAwIHFkaXNjIHBmaWZv X2Zhc3QgbWFzdGVyIGJvbmQwIHN0YXRlIERPV04gbW9kZSBERUZBVUxUIHFsZW4gMTAwMA0KPiAg ICAgbGluay9ldGhlciAwMDoxNToxNzo3YjplOTpiMCBicmQgZmY6ZmY6ZmY6ZmY6ZmY6ZmYNCj4g NDogZW5wNHMwZjE6IDxOTy1DQVJSSUVSLEJST0FEQ0FTVCxNVUxUSUNBU1QsU0xBVkUsVVA+IG10 dSAxNTAwIHFkaXNjIHBmaWZvX2Zhc3QgbWFzdGVyIGJvbmQwIHN0YXRlIERPV04gbW9kZSBERUZB VUxUIHFsZW4gMTAwMA0KPiAgICAgbGluay9ldGhlciAwMDoxNToxNzo3YjplOTpiMCBicmQgZmY6 ZmY6ZmY6ZmY6ZmY6ZmYNCj4gNTogZW5wMTJzMGYwOiA8QlJPQURDQVNULE1VTFRJQ0FTVCxVUCxM T1dFUl9VUD4gbXR1IDE1MDAgcWRpc2MgcGZpZm9fZmFzdCBtYXN0ZXIgb3ZpcnRtZ210IHN0YXRl IFVQIG1vZGUgREVGQVVMVCBxbGVuIDEwMDANCj4gICAgIGxpbmsvZXRoZXIgMDA6MjE6ODU6MzU6 MDg6NGMgYnJkIGZmOmZmOmZmOmZmOmZmOmZmDQo+IDc6IG92aXJ0bWdtdDogPEJST0FEQ0FTVCxN VUxUSUNBU1QsVVAsTE9XRVJfVVA+IG10dSAxNTAwIHFkaXNjIG5vcXVldWUgc3RhdGUgVVAgbW9k ZSBERUZBVUxUDQo+ICAgICBsaW5rL2V0aGVyIDAwOjIxOjg1OjM1OjA4OjRjIGJyZCBmZjpmZjpm ZjpmZjpmZjpmZg0KPg0KPiBXaGF0IHNob3VsZCBJIHRha2UgYSBsb29rIGF0IGZpcnN0Pw0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBVc2Vy cyBtYWlsaW5nIGxpc3QNCj4gVXNlcnNAb3ZpcnQub3JnPG1haWx0bzpVc2Vyc0BvdmlydC5vcmc+ DQo+IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vycw0KPg0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBVc2Vy cyBtYWlsaW5nIGxpc3QNCj4gVXNlcnNAb3ZpcnQub3JnDQo+IGh0dHA6Ly9saXN0cy5vdmlydC5v cmcvbWFpbG1hbi9saXN0aW5mby91c2Vycw0K --_000_d073628bd7264472a089d77e6921e2acemailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <0551208209315D4AADBC80EA8AC627CE(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAzIGphbi4gMjAxNiAyOjQzIGZtIHNrcmV2IFdpbGwgRGVubmlzICZsdDt3ZGVu bmlzQG5lYy1sYWJzLmNvbSZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIOKAmG92aXJ0bWdt dOKAmSBuZXR3b3JrIGhhcyBiZWVuICZhbXA7IGlzIHN0aWxsIHBsYWNlZCBvbiBhIHdvcmtpbmcg TklDIChlbnAxMnMwZjAp4oCmIEl04oCZcyBqdXN0IHRoYXQgbm93LCBvVmlydCBzb21laG93IGRv ZXNu4oCZdCAqdGhpbmsqIGl04oCZcyB3b3JraW5n4oCmPC9wPg0KPHAgZGlyPSJsdHIiPkhlcmUn cyBzb21ldGhpbmcgSSB3cm90ZSBhIGxvbmcgdGltZSBhZ28gbm93LCBmb3IgdGhvc2UgdGltZXMg d2hlbiBhdXRvLWd1aS1jb25maWcgZmx1ZmYganVzdCB3b24ndCBkbzo8L3A+DQo8cCBkaXI9Imx0 ciI+aHR0cDovL3d3dy5vdmlydC5vcmcvQm9uZGluZ19WTEFOX0JyaWRnZTwvcD4NCjxwIGRpcj0i bHRyIj4vSzxicj4NCiZndDs8YnI+DQomZ3Q7IGh0dHA6Ly9zMTA5Ni5waG90b2J1Y2tldC5jb20v dXNlci93aWxsZGVubmlzL21lZGlhL3NldHVwLW5ldHdvcmtzLnBuZy5odG1sPGJyPg0KJmd0Ozxi cj4NCiZndDsgSG93ZXZlciwgYXMgSSBzaG93ZWQgeW91IGluIHRoZSDigJhpcCBsaW5rIHNob3cg dXDigJkgb3V0cHV0LCBpdCBpcyBpbmRlZWQgdXAgYW5kIHdvcmtpbmcuPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gSmFuIDIsIDIwMTYsIGF0IDg6 MDAgUE0sIFJveSBHb2xhbiAmbHQ7cmdvbGFuQHJlZGhhdC5jb20mbHQ7bWFpbHRvOnJnb2xhbkBy ZWRoYXQuY29tJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBPbiBTdW4sIEphbiAzLCAyMDE2IGF0IDI6NDYgQU0sIFdpbGwgRGVubmlzICZsdDt3 ZGVubmlzQG5lYy1sYWJzLmNvbSZsdDttYWlsdG86d2Rlbm5pc0BuZWMtbGFicy5jb20mZ3Q7Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7IEkgaGF2ZSBoYWQgb25lIG9mIG15IGhvc3RzIGdvIGludG8gdGhl IHN0YXRlIOKAnE5vbiBPcGVyYXRpb25hbOKAnSBhZnRlciBJIHJlYm9vdGVkIGl04oCmIEkgYWxz byBub3RpY2VkIHRoYXQgaW4gdGhlIG9WaXJ0IHdlYmFkbWluIFVJLCB0aGUgTklDIHRoYXTigJlz IHVzZWQgaW4gdGhlIOKAmG92aXJ0bWdtdOKAmSBuZXR3b3JrIGlzIHNob3dpbmcg4oCcZG93buKA nSwgYnV0IGluIExpbnV4IHRoZSBOSUMgaXMgb3BlcmF0aW9uYWwgYW5kIHVwLCBhcyBpcyB0aGUg 4oCYb3ZpcnRtZ2104oCZDQogYnJpZGdl4oCmPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IEhvc3RzIHRhYiAtJmd0OyBOZXR3b3JrIEludGVyZmFjZXMgc3VidGFiIC0mZ3Q7IGNsaWNrICZx dW90O1NldHVwIG5ldHdvcmtzJnF1b3Q7IGFuZCBtYWtlIHN1cmUgJnF1b3Q7b3ZpcnRtZ210JnF1 b3Q7IGlzIHBsYWNlZCBvbiBhIHdvcmtpbmcgbmljLjxicj4NCiZndDs8YnI+DQomZ3Q7IG1ha2Ug c3VyZTxicj4NCiZndDsgW3Jvb3RAb3ZpcnQtbm9kZS0wMiB+XSMgaXAgbGluayBzaCB1cDxicj4N CiZndDsgMTogbG86ICZsdDtMT09QQkFDSyxVUCxMT1dFUl9VUCZndDsgbXR1IDY1NTM2IHFkaXNj IG5vcXVldWUgc3RhdGUgVU5LTk9XTiBtb2RlIERFRkFVTFQ8YnI+DQomZ3Q7ICZuYnNwOyZuYnNw OyZuYnNwOyBsaW5rL2xvb3BiYWNrIDAwOjAwOjAwOjAwOjAwOjAwIGJyZCAwMDowMDowMDowMDow MDowMDxicj4NCiZndDsgMjogYm9uZDA6ICZsdDtOTy1DQVJSSUVSLEJST0FEQ0FTVCxNVUxUSUNB U1QsTUFTVEVSLFVQJmd0OyBtdHUgMTUwMCBxZGlzYyBub3F1ZXVlIHN0YXRlIERPV04gbW9kZSBE RUZBVUxUPGJyPg0KJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsgbGluay9ldGhlciAwMDoxNToxNzo3 YjplOTpiMCBicmQgZmY6ZmY6ZmY6ZmY6ZmY6ZmY8YnI+DQomZ3Q7IDM6IGVucDRzMGYwOiAmbHQ7 Tk8tQ0FSUklFUixCUk9BRENBU1QsTVVMVElDQVNULFNMQVZFLFVQJmd0OyBtdHUgMTUwMCBxZGlz YyBwZmlmb19mYXN0IG1hc3RlciBib25kMCBzdGF0ZSBET1dOIG1vZGUgREVGQVVMVCBxbGVuIDEw MDA8YnI+DQomZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyBsaW5rL2V0aGVyIDAwOjE1OjE3OjdiOmU5 OmIwIGJyZCBmZjpmZjpmZjpmZjpmZjpmZjxicj4NCiZndDsgNDogZW5wNHMwZjE6ICZsdDtOTy1D QVJSSUVSLEJST0FEQ0FTVCxNVUxUSUNBU1QsU0xBVkUsVVAmZ3Q7IG10dSAxNTAwIHFkaXNjIHBm aWZvX2Zhc3QgbWFzdGVyIGJvbmQwIHN0YXRlIERPV04gbW9kZSBERUZBVUxUIHFsZW4gMTAwMDxi cj4NCiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IGxpbmsvZXRoZXIgMDA6MTU6MTc6N2I6ZTk6YjAg YnJkIGZmOmZmOmZmOmZmOmZmOmZmPGJyPg0KJmd0OyA1OiBlbnAxMnMwZjA6ICZsdDtCUk9BRENB U1QsTVVMVElDQVNULFVQLExPV0VSX1VQJmd0OyBtdHUgMTUwMCBxZGlzYyBwZmlmb19mYXN0IG1h c3RlciBvdmlydG1nbXQgc3RhdGUgVVAgbW9kZSBERUZBVUxUIHFsZW4gMTAwMDxicj4NCiZndDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpbmsvZXRoZXIgMDA6MjE6ODU6MzU6MDg6NGMgYnJkIGZmOmZm OmZmOmZmOmZmOmZmPGJyPg0KJmd0OyA3OiBvdmlydG1nbXQ6ICZsdDtCUk9BRENBU1QsTVVMVElD QVNULFVQLExPV0VSX1VQJmd0OyBtdHUgMTUwMCBxZGlzYyBub3F1ZXVlIHN0YXRlIFVQIG1vZGUg REVGQVVMVDxicj4NCiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IGxpbmsvZXRoZXIgMDA6MjE6ODU6 MzU6MDg6NGMgYnJkIGZmOmZmOmZmOmZmOmZmOmZmPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hhdCBz aG91bGQgSSB0YWtlIGEgbG9vayBhdCBmaXJzdD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgVXNlcnMg bWFpbGluZyBsaXN0PGJyPg0KJmd0OyBVc2Vyc0BvdmlydC5vcmcmbHQ7bWFpbHRvOlVzZXJzQG92 aXJ0Lm9yZyZndDs8YnI+DQomZ3Q7IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0 aW5mby91c2Vyczxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgVXNlcnMgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyBVc2Vyc0BvdmlydC5vcmc8YnI+DQomZ3Q7IGh0dHA6Ly9saXN0cy5vdmly dC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vyczxicj4NCjwvcD4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_d073628bd7264472a089d77e6921e2acemailandroidcom_--

3 2

Re: [ovirt-users] iLO2
by Eli Mesika 03 Jan '16

03 Jan '16

----- Original Message ----- > From: "Eriks Goodwin" <eriks(a)connectcombpo.com> > To: "Eli Mesika" <emesika(a)redhat.com> > Sent: Tuesday, December 29, 2015 4:13:11 AM > Subject: Re: [ovirt-users] iLO2 > > [root@n001 ~]# /usr/sbin/fence_ipmilan --ip=10.0.1.104 --username=ovirtmgmt > --password=REDACTED -v --action=status --lanplus Please try again with # /usr/sbin/fence_ipmilan --ip=10.0.1.104 --username=ovirtmgmt --password=REDACTED -v --action=status --lanplus -T 4 > > Executing: /usr/bin/ipmitool -I lanplus -H 10.0.1.104 -U ovirtmgmt -P [set] > -p 623 -L ADMINISTRATOR chassis power status > > Connection timed out > > [root@n001 ~]# > > > ----- On Dec 22, 2015, at 8:48 AM, Eli Mesika <emesika(a)redhat.com> wrote: >

1 0

Re: [ovirt-users] Not able to attach my storage
by Nir Soffer 03 Jan '16

03 Jan '16

בתאריך 3 בינו׳ 2016 10:26 לפנה״צ,‏ "Michael Cooper" <mcooper(a)coopfire.com> כתב: (Adding users list) > > This from my engine.log (Snipped log) Next time please attach log files, dumping partial logs in the message body is not very useful. > > I have attached 2 screenshots as well for your review. Let me know I have read through the log but I am new to oVirt so I am not sure what I am looking for yet. > In the screenshot we can see that you already have iso domain attached (CF_ISO). Seems that the system does not support more than one attached iso domain. Why do you need multiple iso domains attached to the same dc? > > > On Sat, Jan 2, 2016 at 11:30 AM, Nir Soffer <nsoffer(a)redhat.com> wrote: >> >> On Sat, Jan 2, 2016 at 12:46 PM, Michael Cooper <mcooper(a)coopfire.com> wrote: >> > Hello Everyone, >> > >> > I wondering why I cannot attach my iso_domain to my Data Center. >> > When I try to attach it says no Valid DataCenters. Why is this happening? >> > Where should I start looking for the resolution? >> >> Can you describe your data center? do you have active hosts? active >> storage domain? >> >> Can you attach engine.log showing this error? >> >> Nir >> >> > >> > Thanks, >> > >> > -- >> > Michael A Cooper >> > Linux Certified >> > Zerto Certified >> > http://www.coopfire.com >> > >> > _______________________________________________ >> > Users mailing list >> > Users(a)ovirt.org >> > http://lists.ovirt.org/mailman/listinfo/users >> > > > > > > -- > Michael A Cooper > Linux Certified > Zerto Certified > http://www.coopfire.com

1 0

Re: [ovirt-users] Users Digest, Vol 52, Issue 1
by Michael Cooper 03 Jan '16

03 Jan '16

Hello Everyone, I wondering why I cannot attach my iso_domain to my Data Center. When I try to attach it says no Valid DataCenters. Why is this happening? Where should I start looking for the resolution? Thanks, -- Michael A Cooper Linux Certified Zerto Certified http://www.coopfire.com

3 2

how shutdown a host
by alireza sadeh seighalan 03 Jan '16

03 Jan '16

hi everyone how can i shutdown a host acording an standard? i want to shutdown or reboot hosts for maintenance purposes (for example host 2-6). thanks in advance

4 3

host status "Non Operational" - how to diagnose & fix?
by Will Dennis 03 Jan '16

03 Jan '16

I have had one of my hosts go into the state “Non Operational” after I rebooted it… I also noticed that in the oVirt webadmin UI, the NIC that’s used in the ‘ovirtmgmt’ network is showing “down”, but in Linux the NIC is operational and up, as is the ‘ovirtmgmt’ bridge… [root@ovirt-node-02 ~]# ip link sh up 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: bond0: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT link/ether 00:15:17:7b:e9:b0 brd ff:ff:ff:ff:ff:ff 3: enp4s0f0: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 state DOWN mode DEFAULT qlen 1000 link/ether 00:15:17:7b:e9:b0 brd ff:ff:ff:ff:ff:ff 4: enp4s0f1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 state DOWN mode DEFAULT qlen 1000 link/ether 00:15:17:7b:e9:b0 brd ff:ff:ff:ff:ff:ff 5: enp12s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovirtmgmt state UP mode DEFAULT qlen 1000 link/ether 00:21:85:35:08:4c brd ff:ff:ff:ff:ff:ff 7: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT link/ether 00:21:85:35:08:4c brd ff:ff:ff:ff:ff:ff What should I take a look at first?

2 2

Configuring another interface for trunked (tagged) VM traffic
by Will Dennis 03 Jan '16

03 Jan '16

Hi all, Taking the next step on configuring my newly-established oVirt cluster, and that would be to set up a trunk (VLAN tagged) connection to each cluster host (there are 3) for VM traffic. What I’m looking at is akin to setting up vSwitches on VMware, except I have never done this on a VMware cluster, just on individual hosts… Anyhow, I have the following NICs available on my three hosts (conveniently, they are the exact same hardware platform): ovirt-node-01 | success | rc=0 >> 3: enp4s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 4: enp4s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 5: enp12s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovirtmgmt state UP mode DEFAULT qlen 1000 6: enp12s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 ovirt-node-02 | success | rc=0 >> 3: enp4s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 4: enp4s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 5: enp12s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovirtmgmt state UP mode DEFAULT qlen 1000 6: enp12s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 ovirt-node-03 | success | rc=0 >> 3: enp4s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 4: enp4s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 5: enp12s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovirtmgmt state UP mode DEFAULT qlen 1000 6: enp12s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 As you may see, I am using the ‘enp12s0f0’ interface on each host for the ‘ovirtmgmt’ bridge. This network carries the admin traffic as well as Gluster distributed filesystem traffic, but I now want to establish a separate link to each host for VM traffic. The ‘ovirtmgmt’ bridge is NOT trunked/tagged, only a single VLAN is used. For the VM traffic, I’d like to use the ‘enp4s0f0’ interface on each host, and tie them into a logical network named “vm-traffic” (or the like) and make that a trunked/tagged interface. Are there any existing succinct instructions on how to do this? I have been reading thru the oVirt Admin Manual’s “Logical Networks” section (http://www.ovirt.org/OVirt_Administration_Guide#Logical_Network_Tasks) but it hasn’t “clicked” in my mind yet... Thanks, Will

1 1

SPM
by Fernando Fuentes 02 Jan '16

02 Jan '16

Team, I noticed that my SPM moved to another host which was odd because I have a set SPM. Somehow when that happen two of my hosts went down and all my vms when in pause state. The oddity behind all this is that my primary storage which has allways been my SPM was online without any issues.. What could of have cause that? and is there a way prevent from the SPM migrating unless there is an issue? -- Fernando Fuentes ffuentes(a)txweather.org http://www.txweather.org

2 1

oVirt hosted engine agent and broker duplicate logs to syslog
by Aleksey Chudov 02 Jan '16

02 Jan '16

Hi, After upgrade from 3.6.0 to 3.6.1 agent and broker duplicate their logs to syslog. So, the same messages logged twice to files in /var/log/ovirt-hosted-engine-ha/ directory and to /var/log/messages file. Agent and broker configuration files remain the same for 3.5, 3.6.0 and 3.6.1 and there is not such logs duplication in 3.5 and 3.6.0. Is it a bug or expected behavior? OS is CentOS 7.2 # rpm -qa 'ovirt*' ovirt-vmconsole-1.0.0-1.el7.centos.noarch ovirt-vmconsole-host-1.0.0-1.el7.centos.noarch ovirt-host-deploy-1.4.1-1.el7.centos.noarch ovirt-hosted-engine-ha-1.3.3.5-1.el7.centos.noarch ovirt-engine-sdk-python-3.6.0.3-1.el7.centos.noarch ovirt-release36-002-2.noarch ovirt-setup-lib-1.0.0-1.el7.centos.noarch ovirt-hosted-engine-setup-1.3.1.3-1.el7.centos.noarch # cat /etc/ovirt-hosted-engine-ha/agent-log.conf [loggers] keys=root [handlers] keys=syslog,logfile [formatters] keys=long,sysform [logger_root] level=INFO handlers=syslog,logfile propagate=0 [handler_syslog] level=ERROR class=handlers.SysLogHandler formatter=sysform args=('/dev/log', handlers.SysLogHandler.LOG_USER) [handler_logfile] class=logging.handlers.TimedRotatingFileHandler args=('/var/log/ovirt-hosted-engine-ha/agent.log', 'd', 1, 7) level=DEBUG formatter=long [formatter_long] format=%(threadName)s::%(levelname)s::%(asctime)s::%(module)s::%(lineno)d::%(name)s::(%(funcName)s) %(message)s [formatter_sysform] format=ovirt-ha-agent %(name)s %(levelname)s %(message)s datefmt= Aleksey

3 4