Storage VLAN Issue
by Kendal Montgomery
--_000_0366DCE80EE9443B80C6E891426FBB27cbuscollaboratorycom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
SGkgYWxsLA0KDQpJIGp1c3QgcmVjZW50bHkgc3RhcnRlZCB0ZXN0aW5nIG91dCBvVmlydCBpbiBv
dXIgbGFiLiAgSeKAmW0gdXNpbmcgQ2VudE9TIDcgb24gbXkgaG9zdHMgYW5kIHVzaW5nIHRoZSBo
b3N0ZWQtZW5naW5lIG1vZGVsLCBhbmQgdGhlIG9WaXJ0IDMuNiByZXBvc2l0b3J5LiAgSSBoYXZl
IE5GUyBzdG9yYWdlLiAgSSByYW4gYWNyb3NzIHdoYXQgSSB0aGluayBpcyBhIGJ1ZyBvZiBzb21l
IHNvcnQsIGFuZCBJ4oCZbSBjdXJpb3VzIGlmIGFueW9uZSBlbHNlIGhhcyB0cmllZCB0aGlzIG9y
IGtub3cgd2hhdOKAmXMgZ29pbmcgb24uDQoNCkkgd2FudGVkIHRvIGJlIGFibGUgdG8gZXhwb3Nl
IHRoZSBORlMgc2VydmVyIChub3QgbmVjZXNzYXJpbHkgdGhlIHNoYXJlIHVzZWQgZm9yIG9WaXJ0
IHN0b3JhZ2UgZG9tYWlucywgYnV0IG90aGVyIHNoYXJlcyBvbiB0aGUgTkZTIHNlcnZlcikgdG8g
Vk1zIHJ1bm5pbmcgb24gbXkgaG9zdCAoY3VycmVudGx5IG15IHNldHVwIG9ubHkgaW52b2x2ZXMg
YSBzaW5nbGUgaG9zdCkuIEkgaGF2ZSB0d28gMTBHYmFzZVQgaW50ZXJmYWNlZCBib25kZWQgdG9n
ZXRoZXIgb24gdGhlIGhvc2Ugd2l0aCB0d28gVkxBTiBuZXR3b3JrcyBvbiBpdCBjdXJyZW50bHks
IG9uZSBmb3IgdGhlIG1hbmFnZW1lbnQgbmV0d29yaywgb25lIGZvciBzdG9yYWdlLiAgV2hlbiB0
aGUgaG9zdGVkLWVuZ2luZSBkZXBsb3ltZW50IHdhcyBzZXQgdXAsIEkgZW5kZWQgdXAgd2l0aCBh
biBvdmlydG1nbXQgaW50ZXJmYWNlIHRoYXQgd2FzIGJyaWRnZWQgdG8gbXkgaW5mcmFzdHJ1Y3R1
cmUgdmxhbiBpbnRlcmZhY2UgKHZsYW4gMTA4MCkuICBTbywgSSBhZGRlZCBhbm90aGVyIG5ldHdv
cmsgaW4gbXkgb1ZpcnQgY2x1c3RlciBuYW1lZCBWTS1TdG9yYWdlIHdpdGggdmxhbiAxMDkyICht
eSBzdG9yYWdlIG5ldHdvcmspLiAgSGVyZSBpcyBhcHByb3hpbWF0ZWx5IGhvdyBJIGV4cGVjdGVk
IHRoaXMgdG8gZW5kIHVwOg0KDQpib25kMCAtIChib25kZWQgaW50ZXJmYWNlKQ0KICAtIGJvbmQw
LjEwOTIgKFNUT1JBR0UgLSB2bGFuIGludGVyZmFjZSkNCiAgICAgLSBWTS1zdG9yYWdlIChicmlk
Z2VkIGludGVyZmFjZSkNCiAgLSBib25kMC4xMDgwIChJTkZSIC0gdmFuIGludGVyZmFjZSkNCiAg
ICAtIG92aXJ0bWdtdCAoYnJpZGdlZCBpbnRlcmZhY2UpDQoNCkhvd2V2ZXIsIHdoZW4gSSBkaWQg
bmV0d29yayBzZXR1cCBvbiB0aGUgaG9zdCwgYW5kIGRyYWdnZWQgdGhlIFZNLVN0b3JhZ2UgbmV0
d29yayBvdmVyIHRvIHRoZSBuZXR3b3JrIGludGVyZmFjZSBhbmQgaGl0IE9LLCB0aGUgVUkganVz
dCBmcm96ZSwgYW5kIGZvciBhIGZldyBzZWNvbmRzIEkgY2hlY2tlZCBvbiB0aGUgaG9zdCB2aWEg
c3NoIHNlc3Npb24gYW5kIHRoZSBWTS1zdG9yYWdlIGJyaWRnZSB3YXMgc2V0dXAsIHRoZW4gdGhl
IHNlcnZlciBqdXN0IHJlYm9vdGVkLiAgQWZ0ZXIgaXQgcmVib290ZWQsIG15IHZsYW4gaW50ZXJm
YWNlIHdhcyBubyBsb25nZXIgdGhlcmUgYW5kIGl0IHNlZW1zIGxpa2UgYm90aCB0aGUgaG9zdGVk
IGVuZ2luZSBWTSBhbmQgdGhlIGhvc3QgZW5kZWQgdXAgYmVpbmcgcmVib290ZWQuICBJbiB0aGlu
a2luZyBhYm91dCBpdCwgSSBtYXkgaGF2ZSBjYXVzZWQgYXQgbGVhc3QgYSB0ZW1wb3Jhcnkgb3V0
YWdlIHdpdGggbXkgTkZTIHN0b3JhZ2Ugd2hlbiB0aGUgbmV3IGJyaWRnZWQgaW50ZXJmYWNlIHdh
cyBzZXQgdXAgd2hpY2ggY2F1c2VkIChtYXliZSkgdGhlIEhBIGFnZW50IHRvIHRoaW5rIHRoZSBo
b3N0ZWQgZW5naW5lIHZtIHdlbnQgYXdheSBvciBzb21ldGhpbmcsIGFuZCB0aGF0IGNhdXNlIHRo
ZSByZWJvb3RzLiAgTm90IGVudGlyZWx5IHN1cmUsIGJ1dCB0aGlzIHdhcyBjZXJ0YWlubHkgdW5l
eHBlY3RlZC4gIEkgaGF2ZSB0cmllZCBzZXZlcmFsIHRpbWVzIGFuZCB0aGUgc2FtZSByZXN1bHQg
ZWFjaCB0aW1lLg0KDQpJIGRpZCBjaGVjayB0aGF0IGFueSBvdGhlciBWTSBuZXR3b3JrIHdpdGgg
YSBkaWZmZXJlbnQgVkxBTiBJRCBwcm92aXNpb25zIGp1c3QgZmluZSBvbiB0aGUgaG9zdCwgc28g
SSBhc3N1bWUgdGhlcmXigJlzIHNvbWV0aGluZyB0aGF0IGhhcHBlbnMgd2hlbiB0aGlzIHN0b3Jh
Z2UgbmV0d29yayBpcyBwcm92aXNpb25lZCB0aGF0IGlzIGNhdGNoaW5nIG9WaXJ0IG9mZi1ndWFy
ZCBzb21laG93Lg0KDQpBbnlvbmUgZWxzZSBoYXZlIHRoaXMgaXNzdWUgYmVmb3JlPyAgQ2FuIEkg
c29sdmUgdGhpcyBieSBhZGRpbmcgYW5vdGhlciBob3N0LCB0aGVuIG1vdmluZyB0aGUgaG9zdGVk
LWVuZ2luZSB0byBhIGRpZmZlcmVudCBob3N0IHdoaWxlIEkgYWRkIHRoZSBzdG9yYWdlIG5ldHdv
cmsgdG8gZWFjaCBob3N0Pw0KDQpUaGFua3MuDQoNCktlbmRhbCBNb250Z29tZXJ5DQpMYWIgTWFu
YWdlcg0KTzogNjE0LjQwNy41NTg0IHwgTTogNjE0LjU3MS4wMTcyDQprbW9udGdvbWVyeUBjYnVz
Y29sbGFib3JhdG9yeS5jb208bWFpbHRvOmttb250Z29tZXJ5QGNidXNjb2xsYWJvcmF0b3J5LmNv
bT4NCg0K
--_000_0366DCE80EE9443B80C6E891426FBB27cbuscollaboratorycom_
Content-Type: text/html; charset="utf-8"
Content-ID: <91F0E571AB281F44B836DAD9F2229895(a)namprd04.prod.outlook.com>
Content-Transfer-Encoding: base64
PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBhbGws
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij5JIGp1c3QgcmVjZW50bHkgc3RhcnRlZCB0ZXN0aW5nIG91dCBvVmlydCBpbiBvdXIgbGFiLiAm
bmJzcDtJ4oCZbSB1c2luZyBDZW50T1MgNyBvbiBteSBob3N0cyBhbmQgdXNpbmcgdGhlIGhvc3Rl
ZC1lbmdpbmUgbW9kZWwsIGFuZCB0aGUgb1ZpcnQgMy42IHJlcG9zaXRvcnkuICZuYnNwO0kgaGF2
ZSBORlMgc3RvcmFnZS4gJm5ic3A7SSByYW4gYWNyb3NzIHdoYXQgSSB0aGluayBpcyBhIGJ1ZyBv
ZiBzb21lIHNvcnQsIGFuZCBJ4oCZbSBjdXJpb3VzIGlmIGFueW9uZQ0KIGVsc2UgaGFzIHRyaWVk
IHRoaXMgb3Iga25vdyB3aGF04oCZcyBnb2luZyBvbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgd2FudGVkIHRvIGJlIGFibGUgdG8g
ZXhwb3NlIHRoZSBORlMgc2VydmVyIChub3QgbmVjZXNzYXJpbHkgdGhlIHNoYXJlIHVzZWQgZm9y
IG9WaXJ0IHN0b3JhZ2UgZG9tYWlucywgYnV0IG90aGVyIHNoYXJlcyBvbiB0aGUgTkZTIHNlcnZl
cikgdG8gVk1zIHJ1bm5pbmcgb24gbXkgaG9zdCAoY3VycmVudGx5IG15IHNldHVwIG9ubHkgaW52
b2x2ZXMgYSBzaW5nbGUgaG9zdCkuIEkgaGF2ZSB0d28gMTBHYmFzZVQgaW50ZXJmYWNlZA0KIGJv
bmRlZCB0b2dldGhlciBvbiB0aGUgaG9zZSB3aXRoIHR3byBWTEFOIG5ldHdvcmtzIG9uIGl0IGN1
cnJlbnRseSwgb25lIGZvciB0aGUgbWFuYWdlbWVudCBuZXR3b3JrLCBvbmUgZm9yIHN0b3JhZ2Uu
ICZuYnNwO1doZW4gdGhlIGhvc3RlZC1lbmdpbmUgZGVwbG95bWVudCB3YXMgc2V0IHVwLCBJIGVu
ZGVkIHVwIHdpdGggYW4gb3ZpcnRtZ210IGludGVyZmFjZSB0aGF0IHdhcyBicmlkZ2VkIHRvIG15
IGluZnJhc3RydWN0dXJlIHZsYW4gaW50ZXJmYWNlDQogKHZsYW4gMTA4MCkuICZuYnNwO1NvLCBJ
IGFkZGVkIGFub3RoZXIgbmV0d29yayBpbiBteSBvVmlydCBjbHVzdGVyIG5hbWVkIFZNLVN0b3Jh
Z2Ugd2l0aCB2bGFuIDEwOTIgKG15IHN0b3JhZ2UgbmV0d29yaykuICZuYnNwO0hlcmUgaXMgYXBw
cm94aW1hdGVseSBob3cgSSBleHBlY3RlZCB0aGlzIHRvIGVuZCB1cDo8L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmJvbmQwIC0gKGJvbmRl
ZCBpbnRlcmZhY2UpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAtIGJvbmQwLjEwOTIgKFNU
T1JBR0UgLSB2bGFuIGludGVyZmFjZSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw
OyAmbmJzcDstIFZNLXN0b3JhZ2UgKGJyaWRnZWQgaW50ZXJmYWNlKTwvZGl2Pg0KPGRpdiBjbGFz
cz0iIj4mbmJzcDsgLSBib25kMC4xMDgwIChJTkZSIC0gdmFuIGludGVyZmFjZSk8L2Rpdj4NCjxk
aXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAtIG92aXJ0bWdtdCAoYnJpZGdlZCBpbnRlcmZhY2Up
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij5Ib3dldmVyLCB3aGVuIEkgZGlkIG5ldHdvcmsgc2V0dXAgb24gdGhlIGhvc3QsIGFuZCBkcmFn
Z2VkIHRoZSBWTS1TdG9yYWdlIG5ldHdvcmsgb3ZlciB0byB0aGUgbmV0d29yayBpbnRlcmZhY2Ug
YW5kIGhpdCBPSywgdGhlIFVJIGp1c3QgZnJvemUsIGFuZCBmb3IgYSBmZXcgc2Vjb25kcyBJIGNo
ZWNrZWQgb24gdGhlIGhvc3QgdmlhIHNzaCBzZXNzaW9uIGFuZCB0aGUgVk0tc3RvcmFnZSBicmlk
Z2Ugd2FzIHNldHVwLCB0aGVuDQogdGhlIHNlcnZlciBqdXN0IHJlYm9vdGVkLiAmbmJzcDtBZnRl
ciBpdCByZWJvb3RlZCwgbXkgdmxhbiBpbnRlcmZhY2Ugd2FzIG5vIGxvbmdlciB0aGVyZSBhbmQg
aXQgc2VlbXMgbGlrZSBib3RoIHRoZSBob3N0ZWQgZW5naW5lIFZNIGFuZCB0aGUgaG9zdCBlbmRl
ZCB1cCBiZWluZyByZWJvb3RlZC4gJm5ic3A7SW4gdGhpbmtpbmcgYWJvdXQgaXQsIEkgbWF5IGhh
dmUgY2F1c2VkIGF0IGxlYXN0IGEgdGVtcG9yYXJ5IG91dGFnZSB3aXRoIG15IE5GUyBzdG9yYWdl
IHdoZW4NCiB0aGUgbmV3IGJyaWRnZWQgaW50ZXJmYWNlIHdhcyBzZXQgdXAgd2hpY2ggY2F1c2Vk
IChtYXliZSkgdGhlIEhBIGFnZW50IHRvIHRoaW5rIHRoZSBob3N0ZWQgZW5naW5lIHZtIHdlbnQg
YXdheSBvciBzb21ldGhpbmcsIGFuZCB0aGF0IGNhdXNlIHRoZSByZWJvb3RzLiAmbmJzcDtOb3Qg
ZW50aXJlbHkgc3VyZSwgYnV0IHRoaXMgd2FzIGNlcnRhaW5seSB1bmV4cGVjdGVkLiAmbmJzcDtJ
IGhhdmUgdHJpZWQgc2V2ZXJhbCB0aW1lcyBhbmQgdGhlIHNhbWUgcmVzdWx0DQogZWFjaCB0aW1l
LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+SSBkaWQgY2hlY2sgdGhhdCBhbnkgb3RoZXIgVk0gbmV0d29yayB3aXRoIGEgZGlmZmVyZW50
IFZMQU4gSUQgcHJvdmlzaW9ucyBqdXN0IGZpbmUgb24gdGhlIGhvc3QsIHNvIEkgYXNzdW1lIHRo
ZXJl4oCZcyBzb21ldGhpbmcgdGhhdCBoYXBwZW5zIHdoZW4gdGhpcyBzdG9yYWdlIG5ldHdvcmsg
aXMgcHJvdmlzaW9uZWQgdGhhdCBpcyBjYXRjaGluZyBvVmlydCBvZmYtZ3VhcmQgc29tZWhvdy48
L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PkFueW9uZSBlbHNlIGhhdmUgdGhpcyBpc3N1ZSBiZWZvcmU/ICZuYnNwO0NhbiBJIHNvbHZlIHRo
aXMgYnkgYWRkaW5nIGFub3RoZXIgaG9zdCwgdGhlbiBtb3ZpbmcgdGhlIGhvc3RlZC1lbmdpbmUg
dG8gYSBkaWZmZXJlbnQgaG9zdCB3aGlsZSBJIGFkZCB0aGUgc3RvcmFnZSBuZXR3b3JrIHRvIGVh
Y2ggaG9zdD88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPlRoYW5rcy48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm
b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7
IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1
dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw
eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7
IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0
ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9
ImZvbnQtc2l6ZTogMTRweDsgbWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyI+PHNwYW4gY2xhc3M9
IiIgc3R5bGU9ImNvbG9yOiByZ2IoMjM3LCAxMDMsIDIxKTsiPjxmb250IGZhY2U9IlRpbWVzIiBz
aXplPSIzIiBjbGFzcz0iIj48YiBjbGFzcz0iIj5LZW5kYWwgTW9udGdvbWVyeTwvYj48L2ZvbnQ+
PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBtYXJn
aW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48Zm9udCBmYWNlPSJUaW1lcyIgY2xhc3M9IiI+PGIgY2xh
c3M9IiI+TGFiIE1hbmFnZXI8L2I+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i
Zm9udC1zaXplOiAxNHB4OyBtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48Zm9udCBmYWNlPSJU
aW1lcyIgY2xhc3M9IiI+TzogNjE0LjQwNy41NTg0IHwmbmJzcDtNOiA2MTQuNTcxLjAxNzI8L2Zv
bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IG1hcmdpbjog
MGluIDBpbiAwLjAwMDFwdDsiPjxmb250IGZhY2U9IlRpbWVzIiBjbGFzcz0iIj48YSBocmVmPSJt
YWlsdG86a21vbnRnb21lcnlAY2J1c2NvbGxhYm9yYXRvcnkuY29tIiBjbGFzcz0iIj5rbW9udGdv
bWVyeUBjYnVzY29sbGFib3JhdG9yeS5jb208L2E+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K
--_000_0366DCE80EE9443B80C6E891426FBB27cbuscollaboratorycom_--
8 years, 5 months
Local storage & shared in same cluster
by Sebastian Greco
Hi,
Is there a technical reason for not being able to use the local host
storage if that host is already in a cluster with shared storage?
For instance, if a user has a server with with a lot of storage and he
wants to use that storage for non HA VMs that will only run over that host
while, that host is also part of a cluster running VMs in a shared storage.
If there's no technical reason/limitation behind this and this is a design
choice, do you consider this to be in a roadmap?
Thanks!
Sebastián Greco
IT Consultant
Cloud Computing - Red Hat - VMware - Zimbra
www.essiprojects.com
*www.essiprojects.co.uk <http://www.essiprojects.co.uk>*
Pl. Prim, 4-5 Pral 2a · T:+34 977 221 182 · M: +34 619 985 161 F: +34 977
230 170 · 43001 Tarragona Spain
120 Pall Mall · T:+44 207 101 0778 · F: +44 843 538 3112 · SW1Y 5ED *London*
UK
8 years, 5 months
Hosted Engine CPU usage always shows 100%
by knarra
Hi,
I have latest ovirt master and i see that Hosted Engine CPU is
always shown 100%. But the actual usage in the system is very less. Is
this a known issue or a bug ?
Thanks
kasturi
8 years, 5 months
mass upload of disks?
by Ben De Luca
Hi,
I was wondering if there was a method on the cli/script to mass upload
disks to ovirt. The web loader is great, but also I have 20 disks that I
really just want to upload via shell.
I can't seem to find a tool to do it, I have found ovirt-image-uploader
(but that's for ovf files).
I hoped that I could just pull the date directly off nfs but that
doesnt seem to be possible, or I am blind?
Thanks
-Ben
8 years, 5 months
Setting DNS servers problem on ovirt
by Thing
Hi,
I have installed IPA across 3 nodes. In order to point the ovirt server at
the new IPA/DNS servers and to clean up I ran engine-cleanup aiming to
delte the ovirt setup. However it seems even though I ran this something,
"vdsm?" is still running and controlling the networking.
So down under /etc/sysconfig/network-scripts I see,
=========
/etc/sysconfig/network-scripts
[root@ovirt1 network-scripts]# ls -l
total 256
-rw-rw-r--. 1 root root 130 Nov 1 10:32 ifcfg-enp0s25
-rw-r--r--. 1 root root 254 Sep 16 2015 ifcfg-lo
-rw-rw-r--. 1 root root 252 Nov 1 10:32 ifcfg-ovirtmgmt
8><-----
==========
So my first Q is why when I run engine-cleanup isnt the networking cleaned
up? should I file this as a bugzilla?
After that I can see that ifcfg-ovirtmgmt is still controlling DNS,
==========
8><----
[root@ovirt1 network-scripts]# tail ifcfg-ovirtmgmt
ONBOOT=yes
IPADDR=192.168.1.34
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
BOOTPROTO=none
MTU=1500
DEFROUTE=yes
NM_CONTROLLED=no
IPV6INIT=no
DNS1=192.168.1.240
[root@ovirt1 network-scripts]#
===========
So I tried to set,
DNS1=192.168.1.31
DNS2=192.168.1.32
DNS3=192.168.1.33
rebooted and, no I see,
DNS1=192.168.1.240 again
So I also see that the vdsm service is still running,
==========
[root@ovirt1 network-scripts]# systemctl status vdsm-network.service
● vdsm-network.service - Virtual Desktop Server Manager network restoration
Loaded: loaded (/usr/lib/systemd/system/vdsm-network.service; enabled;
vendor preset: enabled)
Active: active (exited) since Tue 2016-11-01 10:32:51 NZDT; 2h 0min ago
Process: 2873 ExecStart=/usr/bin/vdsm-tool restore-nets (code=exited,
status=0/SUCCESS)
Process: 2848 ExecStartPre=/usr/bin/vdsm-tool --vvverbose --append
--logfile=/var/log/vdsm/upgrade.log upgrade-unified-persistence
(code=exited, status=0/SUCCESS)
Main PID: 2873 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/vdsm-network.service
Nov 01 10:32:45 ovirt1.ods.graywitch.co.nz python[2887]: DIGEST-MD5 client
step 2
Nov 01 10:32:45 ovirt1.ods.graywitch.co.nz python[2887]: DIGEST-MD5
parse_server_challenge()
Nov 01 10:32:45 ovirt1.ods.graywitch.co.nz python[2887]: DIGEST-MD5
ask_user_info()
Nov 01 10:32:45 ovirt1.ods.graywitch.co.nz python[2887]: DIGEST-MD5 client
step 2
Nov 01 10:32:45 ovirt1.ods.graywitch.co.nz python[2887]: DIGEST-MD5
ask_user_info()
Nov 01 10:32:45 ovirt1.ods.graywitch.co.nz python[2887]: DIGEST-MD5
make_client_response()
Nov 01 10:32:45 ovirt1.ods.graywitch.co.nz python[2887]: DIGEST-MD5 client
step 3
Nov 01 10:32:51 ovirt1.ods.graywitch.co.nz python[2887]: DIGEST-MD5 client
mech dispose
Nov 01 10:32:51 ovirt1.ods.graywitch.co.nz python[2887]: DIGEST-MD5 common
mech dispose
Nov 01 10:32:51 ovirt1.ods.graywitch.co.nz systemd[1]: Started Virtual
Desktop Server Manager network restoration.
[root@ovirt1 network-scripts]#
===========
why after cleaning up is this still active?
Next, I have grep'd under /etc/ and cannot find where its getting its
obsolete network DNS info info from.
So I need to know where this info is stored? so I can edit is via the CLI?
database?
There is no web ui running as engine-cleanup has removed that so I cant
work via the web ui.
Is there anything else I need to manually stop, disable and remove after
running engine-cleanup?
thanks
8 years, 5 months
Kill a failed VM import
by Chris Cowley
Hello all
I have just imported physical machine into my export datastore using
virt-p2v. While I was importing it, my hosted-engine died (VM went into
paused state) during the disk-copy stage.
Now, that half-imported VM is in the status "image locked" and I am un able
to do anything with it. The disk image does not seem to be in my master
data store so I think I can safely delete the VM and re-import it. However,
that is not available in the web GUI. How can I work around that and force
the deletion?
8 years, 5 months
Local and Shared storage in same datacenter
by Mike (maillinglists)
Hi guys,
There have been a few related questions already that I could find, but I
did not find anything relating to my specific use case.
Currently it is not possible to mix local storage with shared storage in
the same datacenter.
The reason seems to be because of the storage pool manager (SPM).
This is a role in the datacenter provided to one specific host.
While I understand that this makes having local storage impossible, I
believe there is a use case to have local storage in a shared storage
datacenter.
Consider the following:
I have a few applications that require 1 milli second latency and at
most 2 milli second.
That is not consistenly achievable with shared storage, to that end I
added flash storage to a few hypervisors.
About 5% of my servers require this and are not that resource hungry to
require a dedicated physical server.
That same 5% also has no requirement to be migrated if a host fails.
So in short I have 5 heavy hosts running ovirt with a shared storage
domain on NFS for 95% of my servers.
All running fine, but I am now unable to run my remaining 5%.
To finish up my summary I have been testing various virtualization
technologies, like VmWare and Hyper-V.
They allow such configurations as I mentioned.
I already had some chat on irc with various guys and they suggested that
I put this on the mailing list, so here goes.
My suggestion would be to evoluate from SPM to SDM.
SDM stands for Storage Domain Manager.
This would create the possibility to have all nodes in the datacenter
participate in the storage handling.
A extra benefit would be that local storage could be added.
What do you think?
Thanks for reading.
Kind regards,
Mike van Goor
8 years, 5 months
Re: [ovirt-users] Local and Shared storage in same datacenter
by Pavel Gashev
I think it's all about online VM migration. oVirt doesn't support online VM migration together with online storage migration. So any storage has to be accessible from any hosts in a datacenter. That's why local storages are too restricted.
Converting Local storages to Shared removes the restriction. Avoiding NFS layer locally removes the NFS performance drawback. And both allow to adhere to the oVirt way.
-----Original Message-----
From: Fernando Frediani <fernando.frediani(a)upx.com.br>
Date: Monday 31 October 2016 at 17:07
To: Pavel Gashev <Pax(a)acronis.com>
Subject: Re: [ovirt-users] Local and Shared storage in same datacenter
Why this 'workdaround' to share a local storage as NFS instead os just
use it as a 'normal' Local storage ? Looks more like a chewing gum.
Is there any work in progress to change the way this storage pool
manager works ?
On 31/10/2016 12:02, Pavel Gashev wrote:
> Mike,
>
> As workaround it's not very hard to create a mount command wrapper that converts local NFS mounts to bind-mounts. The propper way I think is to patch the VDSM service to handle local NFS mounts. In result, a NFS storage will work like a local storage if it's local.
>
> -----Original Message-----
> From: Mike <maillist(a)probie.nl>
> Date: Monday 31 October 2016 at 16:33
> To: Pavel Gashev <Pax(a)acronis.com>, "users(a)ovirt.org" <users(a)ovirt.org>
> Subject: Re: [ovirt-users] Local and Shared storage in same datacenter
>
> Hi Pavel,
>
> Op 31-10-2016 om 11:22 schreef Pavel Gashev:
>> Mike,
>>
>> You can share and use your local storage via NFS. So all your storages are shared, and can be used in the same datacenter.
> I installed a nfs server on the hypervisor and am using it that way at
> the moment.
> It feels 'wrong' but it seems to work okay and it is fast as far as I
> can tell.
> Still would like to see another solution without the added latency of
> nfs and be able to utilize directio, etc.
>> -----Original Message-----
>> From: <users-bounces(a)ovirt.org> on behalf of "Mike (maillinglists)" <maillist(a)probie.nl>
>> Date: Sunday 30 October 2016 at 13:02
>> To: "users(a)ovirt.org" <users(a)ovirt.org>
>> Subject: [ovirt-users] Local and Shared storage in same datacenter
>>
>> Hi guys,
>>
>> There have been a few related questions already that I could find, but I
>> did not find anything relating to my specific use case.
>>
>> Currently it is not possible to mix local storage with shared storage in
>> the same datacenter.
>> The reason seems to be because of the storage pool manager (SPM).
>> This is a role in the datacenter provided to one specific host.
>>
>> While I understand that this makes having local storage impossible, I
>> believe there is a use case to have local storage in a shared storage
>> datacenter.
>> Consider the following:
>> I have a few applications that require 1 milli second latency and at
>> most 2 milli second.
>> That is not consistenly achievable with shared storage, to that end I
>> added flash storage to a few hypervisors.
>> About 5% of my servers require this and are not that resource hungry to
>> require a dedicated physical server.
>> That same 5% also has no requirement to be migrated if a host fails.
>>
>> So in short I have 5 heavy hosts running ovirt with a shared storage
>> domain on NFS for 95% of my servers.
>> All running fine, but I am now unable to run my remaining 5%.
>>
>> To finish up my summary I have been testing various virtualization
>> technologies, like VmWare and Hyper-V.
>> They allow such configurations as I mentioned.
>>
>> I already had some chat on irc with various guys and they suggested that
>> I put this on the mailing list, so here goes.
>>
>> My suggestion would be to evoluate from SPM to SDM.
>> SDM stands for Storage Domain Manager.
>> This would create the possibility to have all nodes in the datacenter
>> participate in the storage handling.
>> A extra benefit would be that local storage could be added.
>>
>> What do you think?
>>
>> Thanks for reading.
>>
>> Kind regards,
>> Mike van Goor
>> _______________________________________________
>> 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
8 years, 5 months
Updated ovirt-guest-agent puppet module
by René Koch
This is a cryptographically signed message in MIME format.
--------------ms090308070008040700020706
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Hi,
there's an updated version of scrat14/ovirt-guest-agent available at=20
https://forge.puppet.com/scrat14/ovirt_guest_agent
Latest version includes support for installing oVirt guest agent on RHEV =
hypervisors in addition to oVirt nodes.
Furthermore this module will now use rhevm-guest-agent-common for RHEL 7 =
machines from rhel-7-server-rh-common-rpms repository by default=20
(instead of ovirt-guest-agent-common from EPEL).
Regards,
Ren=C3=A9
--------------ms090308070008040700020706
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CtUwggTrMIID06ADAgECAhAja0pvtE6eFeIAvVog9AvcMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwNjA2MTQwNjA0WhcNMTkwOTA2MTQwNjA0WjA4MRcwFQYDVQQDDA5ya29j
aEByay1pdC5hdDEdMBsGCSqGSIb3DQEJARYOcmtvY2hAcmstaXQuYXQwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDTzwY3gPTUDKgjrFFJa0rWfBjMuhDfVnveWxpTRG81IKQ1
4eClq53KsFsegqhf6vTRZ8M+frzEIT4J3DkTrYfYIbK8rN3VIR7TXVPYAA5g9QDJz9CWOCej
F7xmw2tOKpFa6ozBPxB8k2Irpl7KTXWmFZ/iN9+wCersY/7hYiXh/S59G7YEioJciaXkdqfR
8R0QDkEcVRAQme2SgjU1tYGJemX+2XYx3Y9z43QgBLdeAwPXYoSdp1TEpOQh+heiKNNm138V
Bm8sD/NDxm3ksnhNMjKvqUhVK9z35iksNG7Ao7rgGMtwhd8+mCgFSRQ27lcwwN7cbUpibkGs
kQGsoQD/AgMBAAGjggGyMIIBrjAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH
AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFAov/LAlauAjKdUMLVlx8JW7P63Q
MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr
BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v
YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug
KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB
DnJrb2NoQHJrLWl0LmF0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBH
BgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUHAgEWH2h0dHBzOi8vd3d3LnN0
YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEBAK/kRL1+Hopu1wu7Nni3KEZj
CpCDNcUZFgK+TVKEBKLwYgOuy0qe5+z3buQVBJUWlUGKUeY/ifPWU2GKU9X/nxnihQiaOhBW
O9XcXg6PcY3N6Vk5akvHE1OWxK0QfpLJYe0jP3PA5fqgWSEUFZQYDz4v3izeSyy+nG7XGC1o
mmLEVhAaa2OqaBXphFwfSmdHUmdfrBXwXUI1DMiZX1W13VY/Tw8CWuOLOZ8XWl1IUOTRoO8a
XYEUeKjbtEJTaEEUzBpihoN0ueeK5E2wtbI1mfhOoCGpg3EGoKdSV0OR4AQOhzMQRqKMKGfY
4Nq9IjwzwI6TE7Thy5xYjaIzzi/1Ei8wggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57Th
MA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD
EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xNTEyMTYwMTAwMDVaFw0z
MDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw
JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh
cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwObhajcVmnKVxh
rUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0qn4TPgnr3
X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsSslxL
ce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO
AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIB
YDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Au
c3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0
cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L
7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5o
dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fs
AYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarK
QTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3r
bA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaPv3u1JELyszXqOzjIYo4sWlC8
iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue/quWp9j9ou4T/OY0CXMuY+B8
wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQyCkC2aNNsK5cWOojBar5c7Hpl
X9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVDo/ebn9c6PaM/XtDYCCaM
/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2B2NLatidKE/m7G+r
B9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6jbAV+WL+LDeG
fVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0peVLadVHh
qf9nXqKaxnr358VgfrxzUIrvOaOjMYICjzCCAosCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAU
BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQI2tKb7RO
nhXiAL1aIPQL3DANBglghkgBZQMEAgEFAKCB1zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0xNjEwMzExMjQxNTJaMC8GCSqGSIb3DQEJBDEiBCD5Pw8ttser
m2R2dNfTRgdWX6jZV00IVk5BJFOCmbG3cDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB
KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAFcpkb2xanUd
ytf2LS7Ti9pz6i+TCU25pgUcl/Xl/NCm/S6awSaM7TsqAJ7P595zKs63weeXmNAIH7hKikD3
zw0GXqLbXLtgKBjo969A5Mw7hJhSPRiuyQF5rqzuspx1kH+oH5F8F64eMC2iKdUv2z8qSnv7
HRLwWC7K82hSqyi7wLki9u/gjW2rZcp0AaXQ9LAW3SGxTNojtxGOhwdypXeWoj+0mhiEoofJ
aJJQriy7jyos8EjIV9mgQAmHv1Wld81g/OYRbJg1FyZXiVF7syuFzlXS689aY3ADUSGmSVpD
bwrR5nu6ZARgGH4NjGTJhzwHl0898ku67tDXTlQUBfEAAAAAAAA=
--------------ms090308070008040700020706--
8 years, 5 months
quick way to see total RAM and CPU count on VM listing
by Nelson Lameiras
------=_Part_49066511_63048749.1475160413304
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hello oVirt community,=20
When listing virtual machines, is there a quick way to see how much RAM/CPU=
each machine has?=20
In oVirt 4.0.4, I can see ram/cpu usage in a very nice way, but I can not a=
ccess easily the total RAM and number of CPUs.=20
The only way to find this information in GUI is to edit a vm and see the sy=
stem tab (and that's when the "edit" context menu is available, which is no=
t always)=20
Am I missing something?=20
This information is very usefull and sometimes critical (when migrating VM =
to hosts which are already low on free RAM, specially when balloning is inv=
olved)=20
I would like to see this information always on screen, like a (un)checkable=
column... does it seem doable ?=20
Maybe it would be possible to show it while hoovering the memory/cpu inform=
ation with the mouse ?=20
Please forgive me if this is not the rigth place to post this question/requ=
est.=20
cordialement, regards,=20
Nelson LAMEIRAS=20
Lyra Network=20
Service Projets et Processus=20
Tel : +33 (0) 5 32 09 09 70=20
109 rue de l=E2=80=99innovation=20
31670 Lab=C3=A8ge - France=20
www.lyra-network.com=20
------=_Part_49066511_63048749.1475160413304
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s=
ize: 12pt; color: #000000"><div>Hello oVirt community,<br></div><div><br da=
ta-mce-bogus=3D"1"></div><div>When listing virtual machines, is there a qui=
ck way to see how much RAM/CPU each machine has?<br data-mce-bogus=3D"1"></=
div><div><br data-mce-bogus=3D"1"></div><div>In oVirt 4.0.4, I can see ram/=
cpu usage in a very nice way, but I can not access easily the total RAM and=
number of CPUs. </div><div>The only way to find this information in GUI is=
to edit a vm and see the system tab (and that's when the "edit" context me=
nu is available, which is not always)<br data-mce-bogus=3D"1"></div><div><b=
r data-mce-bogus=3D"1"></div><div>Am I missing something?</div><div>This in=
formation is very usefull and sometimes critical (when migrating VM to host=
s which are already low on free RAM, specially when balloning is involved)<=
br data-mce-bogus=3D"1"></div><div><br data-mce-bogus=3D"1"></div><div>I wo=
uld like to see this information always on screen, like a (un)checkable col=
umn... does it seem doable ? </div><div>Maybe it would be possible to show =
it while hoovering the memory/cpu information with the mouse ?<br data-mce-=
bogus=3D"1"></div><div><br data-mce-bogus=3D"1"></div><div>Please forgive m=
e if this is not the rigth place to post this question/request.<br data-mce=
-bogus=3D"1"></div><div><br data-mce-bogus=3D"1"></div><div data-marker=3D"=
__SIG_PRE__"><div><div><span style=3D"font-size: 12pt; color: rgb(0, 0, 0);=
" data-mce-style=3D"font-size: 12pt; color: #000000;"><span style=3D"font-f=
amily: "century gothic",sans-serif;">cordialement, regards,<br da=
ta-mce-bogus=3D"1"></span></span></div><div><span style=3D"font-size: 12pt;=
color: rgb(0, 0, 0);" data-mce-style=3D"font-size: 12pt; color: #000000;">=
<span style=3D"font-family: "century gothic",sans-serif;">Nelson =
LAMEIRAS<br data-mce-bogus=3D"1"></span></span></div><div><span style=3D"fo=
nt-size: 9pt;" data-mce-style=3D"font-size: 9pt;"><b><span style=3D"font-fa=
mily: "century gothic",sans-serif; color: rgb(54, 95, 145);"><br =
data-mce-bogus=3D"1"></span></b></span></div><div><span style=3D"font-size:=
9pt;" data-mce-style=3D"font-size: 9pt;"><b><span style=3D"font-family: &q=
uot;century gothic",sans-serif; color: rgb(54, 95, 145);">Lyra Network=
</span></b></span></div><div><div><span style=3D"font-size: 9pt; color: #36=
5f91;" data-mce-style=3D"font-size: 9pt; color: #365f91;">Service Projets e=
t Processus</span></div><div><span style=3D"font-size: 9pt; color: rgb(54, =
95, 145);" data-mce-style=3D"font-size: 9pt; color: #365f91;">Tel : +33 (0)=
5 32 09 09 70</span></div></div><span style=3D"font-size: 9pt;" data-mce-s=
tyle=3D"font-size: 9pt;"><span style=3D"font-family: "century gothic&q=
uot;,sans-serif; color: rgb(54, 95, 145);">109 rue de l=E2=80=99innovation<=
/span><span style=3D"font-family: geneva;"></span></span><br><span style=3D=
"font-size: 9pt; font-family: geneva;" data-mce-style=3D"font-size: 9pt; fo=
nt-family: geneva;"></span><div><span style=3D"font-size: 9pt; font-family:=
'century gothic',sans-serif; color: #365f91;" data-mce-style=3D"font-size:=
9pt; font-family: 'century gothic',sans-serif; color: #365f91;">31670 Lab=
=C3=A8ge - France</span><span style=3D"font-size: 9pt; font-family: geneva;=
" data-mce-style=3D"font-size: 9pt; font-family: geneva;"></span><br data-m=
ce-bogus=3D"1"></div><div><span style=3D"font-size: 9pt; font-family: 'cent=
ury gothic',sans-serif; color: #365f91;" data-mce-style=3D"font-size: 9pt; =
font-family: 'century gothic',sans-serif; color: #365f91;"><a href=3D"http:=
//www.lyra-network.com" data-mce-href=3D"http://www.lyra-network.com">www.l=
yra-network.com</a></span><br data-mce-bogus=3D"1"></div></div></div></div>=
</body></html>
------=_Part_49066511_63048749.1475160413304--
8 years, 5 months
