- Users - oVirt List Archives

attaching a storage domain to a datacenter
by Fabrice Bacchella 22 May '16

22 May '16

--Apple-Mail=_33DFF62E-3CCC-498F-8E1E-FD21397C6DBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm trying to attach a SAN domain to data center. It's an old domain that is re-attached. Import works fine. But doing the attachement failed, either throug the UI or REST API call. The log of the api calls are : > POST = /api/datacenters/92fbe5d6-2920-401d-b69b-ad4568e4f407/storagedomains = HTTP/1.1 > Host: example.com:1443 > Authorization: XXX > User-Agent: PycURL/7.43.0 libcurl/7.46.0 OpenSSL/1.0.2e zlib/1.2.8 > Cookie: XXXX > Version: 3 > Content-Type: application/xml > Accept: application/xml > Filter: False > Prefer: persistent-auth > Content-Length: 60 > <storage_domain id=3D"a8dedf2c-5574-48e9-a7fb-e343dc0c6b4d"/> * upload completely sent off: 60 out of 60 bytes * ? < HTTP/1.1 400 Bad Request < Date: Thu, 14 Apr 2016 16:31:48 GMT < Server: Apache < Content-Type: application/xml < Content-Length: 135 < JSESSIONID: R4TTWw65M5TIhbVJo8VBuOOV < Connection: close <=20 * ? < <?xml version=3D"1.0" encoding=3D"UTF-8" standalone=3D"yes"?> < <fault> < <reason>Operation Failed</reason> < <detail>[]</detail> < </fault> There is nothing in the engine.log : 2016-04-14 18:00:57,831 ERROR = [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] = (default task-23) [] Correlation ID: 59497e82, Job ID: = 84e0e22c-bb28-434b-a952-73f0e2c4cfaa, Call Stack: null, Custom Event ID: = -1, Message: Failed to attach Storage Domain vmsys01 to Data Center = en01. (User: FA4@apachesso) Where can I find informations about that ? --Apple-Mail=_33DFF62E-3CCC-498F-8E1E-FD21397C6DBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">I'm trying to attach a SAN domain to data center.<div = class=3D""><br class=3D""></div><div class=3D"">It's an old domain that = is re-attached. Import works fine.</div><div class=3D""><br = class=3D""></div><div class=3D"">But doing the attachement failed, = either throug the UI or REST API call.</div><div class=3D""><br = class=3D""></div><div class=3D"">The log of the api calls are = :</div><div class=3D""><br class=3D""></div><div class=3D""><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">> POST = /api/datacenters/92fbe5d6-2920-401d-b69b-ad4568e4f407/storagedomains = HTTP/1.1</div><div style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;" class=3D"">> Host: <a href=3D"http://example.com" = class=3D"">example.com</a>:1443</div><div style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;" class=3D"">> Authorization: = XXX</div><div style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;" class=3D"">> User-Agent: PycURL/7.43.0 libcurl/7.46.0 = OpenSSL/1.0.2e zlib/1.2.8</div><div style=3D"margin: 0px; font-size: = 11px; font-family: Menlo;" class=3D"">> Cookie: XXXX</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">> Version: 3</div><div style=3D"margin: 0px; font-size: = 11px; font-family: Menlo;" class=3D"">> Content-Type: = application/xml</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">> Accept: application/xml</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">> Filter: False</div><div style=3D"margin: 0px; font-size: = 11px; font-family: Menlo;" class=3D"">> Prefer: = persistent-auth</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">> Content-Length: 60</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">> <storage_domain = id=3D"a8dedf2c-5574-48e9-a7fb-e343dc0c6b4d"/></div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" class=3D"">* = upload completely sent off: 60 out of 60 bytes</div><div style=3D"margin: = 0px; font-size: 11px; font-family: Menlo;" class=3D"">* ?</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">< HTTP/1.1 400 Bad Request</div><div style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;" class=3D"">< Date: Thu, 14 Apr = 2016 16:31:48 GMT</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">< Server: Apache</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">< Content-Type: application/xml</div><div style=3D"margin: = 0px; font-size: 11px; font-family: Menlo;" class=3D"">< = Content-Length: 135</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">< JSESSIONID: = R4TTWw65M5TIhbVJo8VBuOOV</div><div style=3D"margin: 0px; font-size: = 11px; font-family: Menlo;" class=3D"">< Connection: close</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">< </div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">* ?</div><div style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;" class=3D"">< <?xml = version=3D"1.0" encoding=3D"UTF-8" standalone=3D"yes"?></div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">< <fault></div><div style=3D"margin: 0px; font-size: = 11px; font-family: Menlo;" class=3D""><     = <reason>Operation Failed</reason></div><div style=3D"margin: = 0px; font-size: 11px; font-family: Menlo;" class=3D""><     = <detail>[]</detail></div><div style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;" class=3D"">< = </fault></div></div><div class=3D""><br class=3D""></div><div = class=3D"">There is nothing in the engine.log :</div><div class=3D""><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">2016-04-14 18:00:57,831 ERROR = [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] = (default task-23) [] Correlation ID: 59497e82, Job ID: = 84e0e22c-bb28-434b-a952-73f0e2c4cfaa, Call Stack: null, Custom Event ID: = -1, Message: Failed to attach Storage Domain vmsys01 to Data Center = en01. (User: FA4@apachesso)</div></div><div class=3D""><br = class=3D""></div><div class=3D"">Where can I find informations about = that ?</div><div class=3D""><br class=3D""></div><div class=3D""><br = class=3D""></div></body></html>= --Apple-Mail=_33DFF62E-3CCC-498F-8E1E-FD21397C6DBD--

2 1

Upgrade path/possibility from 3.3?
by William Kwan 22 May '16

22 May '16

------=_Part_731664_597039218.1460392041230 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I have a couple of oVirt cluster running 3.3.3-2.el6. =C2=A0I would like to= upgrade them to the latest version. I sort of remember upgrading from 3.3 = to 3.5 required an step to upgrade to 3.4 as an extra step. =C2=A0With the = new 3.6, will it be fine to upgrade straight from 3.3.3 to 3.6? or I need s= ome extra steps? Another question is about preservation of the virtual machines. Can I expor= t the VMs to some storage, upgrade oVirt and then import the VMs afterwards= ? =C2=A0 Thanks in advance.Will ------=_Part_731664_597039218.1460392041230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body><div style=3D"color:#000; background-color:#fff; f= ont-family:Courier New, courier, monaco, monospace, sans-serif;font-size:13= px"><div id=3D"yui_3_16_0_ym19_1_1460391403570_2952">Hi all,</div><div id= =3D"yui_3_16_0_ym19_1_1460391403570_2952"><br></div><div id=3D"yui_3_16_0_y= m19_1_1460391403570_2952" dir=3D"ltr">I have a couple of oVirt cluster runn= ing 3.3.3-2.el6.  I would like to upgrade them to the latest version. = I sort of remember upgrading from 3.3 to 3.5 required an step to upgrade to= 3.4 as an extra step.  With the new 3.6, will it be fine to upgrade s= traight from 3.3.3 to 3.6? or I need some extra steps?</div><div id=3D"yui_= 3_16_0_ym19_1_1460391403570_2952" dir=3D"ltr"><br></div><div id=3D"yui_3_16= _0_ym19_1_1460391403570_2952" dir=3D"ltr">Another question is about preserv= ation of the virtual machines. Can I export the VMs to some storage, upgrad= e oVirt and then import the VMs afterwards?  </div><div id=3D"yui_3_16= _0_ym19_1_1460391403570_2952" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_y= m19_1_1460391403570_2952" dir=3D"ltr">Thanks in advance.</div><div id=3D"yu= i_3_16_0_ym19_1_1460391403570_2952" dir=3D"ltr">Will</div></div></body></ht= ml> ------=_Part_731664_597039218.1460392041230--

2 1

Cannot create local ISO storage domain from UI.
by knarra 22 May '16

22 May '16

Hi, I am trying to set up Hosted Engine. I wanted to deploy windows virtual machines in this environment and as part of that i am creating ISO Domain to upload my windows image. But for some reason, while i create ISO domain it always fails with error "Failed to add Storage Domain <storagedomain_name"> and always remains in unattached state. Can some one please help me to reslove this issue? Attaching the vdsm logs. Thanks kasturi.

3 3

[Users] Host moved to Non-operational state interfaces are down
by Clifford Trueman 22 May '16

22 May '16

Morning, Having an issue with a completely standalone system (no actual network connectivity) Fresh out of the box installation. The issue I'm running into is actually well described here; https://lists.fedorahosted.org/pipermail/vdsm-devel/2013-June/002403.html I've read through the admin guide several times and I'm struggling to find any information detailing exactly how ovirtmangment network exists on my system. My configuration is process was as follows: Centos 7 System has two physical interfaces we'll call them en1 en2 for simplicities sake. en1 = 10.0.0.1/24 resolves to in host file as localmachine.test.net en2 = 192.168.0.1 bridged to ovirtmgmt with my fresh install of ovirt-engine, I added my local machine as host node and it installed the packages and shows up, but fails to down state after about 10 - 15 seconds with Host moved to Non-Operational state due to interfaces which are down are needed by required networks in your cluster. I then tried binding the ovirtmgmt network to the other interface so it didn't ride on the same NIC that resolves the FQDN of the box. So I'm currently at a loss of what to try next, any help would be greatly appreciated.

2 1

Hosted engine setup fails - system unreliable
by Bill Bill 22 May '16

22 May '16

--_000_SN1PR08MB13891E43AC557902F457B133A64C0SN1PR08MB1389namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIHRyaWVkIG92ZXIgJiBvdmVyIG9uIGZyZXNoIGluc3RhbGxzIHRvIHNldHVwIHRoZSBo b3N0ZWQgZW5naW5lIFZNIGhvd2V2ZXIsIGVhY2ggdGltZSwgaXQgZmFpbHMuIE5vIGNsdWUgYXMg dG8gd2hhdCB0aGUgcHJvYmxlbSBpcyBhcyBpdCBqdXN0IHNheXMg4oCcdGhpcyBzeXN0ZW0gaXMg dW5yZWxpYWJsZeKAnS4NCg0KLy8vLy8vLy8vLy8NCg0KTG9nIG91dHB1dDoNCg0KLy8vLy8vLy8v Ly8NCg0KMjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVt cEVudmlyb25tZW50OjUxMCBFTlYgT1ZFSE9TVEVEX1ZNL25pY1VVSUQ9c3RyOic1OGEyOGE1ZS01 ZDBlLTRhYzMtODM1YS1hMWU5YjBkZjZhZTYnDQoyMDE2LTA1LTIxIDAxOjQyOjQyIERFQlVHIG90 b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJvbm1lbnQ6NTEwIEVOViBPVkVIT1NURURfVk0v b3ZmQXJjaGl2ZT11bmljb2RlOicvdXNyL3NoYXJlL292aXJ0LWVuZ2luZS1hcHBsaWFuY2Uvb3Zp cnQtZW5naW5lLWFwcGxpYW5jZS0zLjYtMjAxNjA0MjAuMS5lbDcuY2VudG9zLm92YScNCjIwMTYt MDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0LmR1bXBFbnZpcm9ubWVu dDo1MTAgRU5WIE9WRUhPU1RFRF9WTS9zdWJzdD1kaWN0Oid7J0BDRFJPTUAnOiAnL3RtcC90bXBU eUw4SVcvc2VlZC5pc28nLCAnQFNEX1VVSURAJzogJzI0NTVhYTgxLTE0NmYtNGE2ZS1iZDZjLWMz NjhmYTFkMTBiOCcsICdAQ09OU09MRV9VVUlEQCc6ICdiZWY1MDNiMS00MjI0LTRkODItOGFjZC04 YjAzZDIxYWU2MGInLCAnQE5BTUVAJzogJ0hvc3RlZEVuZ2luZScsICdAQlJJREdFQCc6ICdvdmly dG1nbXQnLCAnQENEUk9NX1VVSURAJzogJzRmNjRlOGJhLTUyNTMtNGI5Yy1iMWE3LWJjNTUwZTIy ZjA5NycsICdATUVNX1NJWkVAJzogNDA5NiwgJ0BOSUNfVVVJREAnOiAnNThhMjhhNWUtNWQwZS00 YWMzLTgzNWEtYTFlOWIwZGY2YWU2JywgJ0BCT09UX0NEUk9NQCc6ICcnLCAnQFZDUFVTQCc6ICc0 JywgJ0BDUFVfVFlQRUAnOiAnU2FuZHlCcmlkZ2UnLCAnQFZNX1VVSURAJzogJzhjYzMwYmJmLThm NGItNGZjZS1hZTRhLWZmZDQ3NmJhZjJiMycsICdARU1VTEFURURfTUFDSElORUAnOiAncGMnLCAn QEJPT1RfUFhFQCc6ICcnLCAnQElNR19VVUlEQCc6ICc0MTQ4ZmI3Mi03M2YxLTRkOGYtODM2OC01 YjZlMWRkYjRlOTYnLCAnQEJPT1RfRElTS0AnOiAnLGJvb3RPcmRlcjoxJywgJ0BDT05TT0xFX1RZ UEVAJzogJ3ZuYycsICdATUFDX0FERFJAJzogJzAwOjE2OjNlOjQxOjIxOmRiJywgJ0BTUF9VVUlE QCc6ICcwMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAwMDAnLCAnQFZPTF9VVUlEQCc6 ICc5YzE3NTMyOS03ZDFhLTRiNTEtODIxOC04YTI1MTIzMDU2ODQnfScNCjIwMTYtMDUtMjEgMDE6 NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0LmR1bXBFbnZpcm9ubWVudDo1MTAgRU5W IE9WRUhPU1RFRF9WTS92bUJvb3Q9c3RyOidkaXNrJw0KMjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJV RyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgT1ZFSE9TVEVE X1ZNL3ZtQ0RSb209Tm9uZVR5cGU6J05vbmUnDQoyMDE2LTA1LTIxIDAxOjQyOjQyIERFQlVHIG90 b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJvbm1lbnQ6NTEwIEVOViBPVkVIT1NURURfVk0v dm1NQUNBZGRyPXN0cjonMDA6MTY6M2U6NDE6MjE6ZGInDQoyMDE2LTA1LTIxIDAxOjQyOjQyIERF QlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJvbm1lbnQ6NTEwIEVOViBPVkVIT1NU RURfVk0vdm1NZW1TaXplTUI9aW50Oic0MDk2Jw0KMjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBv dG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgT1ZFSE9TVEVEX1ZN L3ZtVVVJRD1zdHI6JzhjYzMwYmJmLThmNGItNGZjZS1hZTRhLWZmZDQ3NmJhZjJiMycNCjIwMTYt MDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0LmR1bXBFbnZpcm9ubWVu dDo1MTAgRU5WIE9WRUhPU1RFRF9WTS92bVZDcHVzPXN0cjonNCcNCjIwMTYtMDUtMjEgMDE6NDI6 NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0LmR1bXBFbnZpcm9ubWVudDo1MTAgRU5WIE9W RVNFVFVQX0NPUkUvb2ZmbGluZVBhY2thZ2VyPWJvb2w6J1RydWUnDQoyMDE2LTA1LTIxIDAxOjQy OjQyIERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJvbm1lbnQ6NTEwIEVOViBQ QUNLQUdFUi9kbmZEaXNhYmxlZFBsdWdpbnM9bGlzdDonW10nDQoyMDE2LTA1LTIxIDAxOjQyOjQy IERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJvbm1lbnQ6NTEwIEVOViBQQUNL QUdFUi9kbmZFeHBpcmVDYWNoZT1ib29sOidUcnVlJw0KMjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJV RyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgUEFDS0FHRVIv ZG5mUm9sbGJhY2s9Ym9vbDonVHJ1ZScNCjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGku Y29udGV4dCBjb250ZXh0LmR1bXBFbnZpcm9ubWVudDo1MTAgRU5WIFBBQ0tBR0VSL2RuZnBhY2th Z2VyRW5hYmxlZD1ib29sOidUcnVlJw0KMjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5j b250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgUEFDS0FHRVIva2VlcEFsaXZl SW50ZXJ2YWw9aW50OiczMCcNCjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4 dCBjb250ZXh0LmR1bXBFbnZpcm9ubWVudDo1MTAgRU5WIFBBQ0tBR0VSL3l1bURpc2FibGVkUGx1 Z2lucz1saXN0OidbXScNCjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBj b250ZXh0LmR1bXBFbnZpcm9ubWVudDo1MTAgRU5WIFBBQ0tBR0VSL3l1bUVuYWJsZWRQbHVnaW5z PWxpc3Q6J1tdJw0KMjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRl eHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgUEFDS0FHRVIveXVtRXhwaXJlQ2FjaGU9Ym9vbDon VHJ1ZScNCjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0LmR1 bXBFbnZpcm9ubWVudDo1MTAgRU5WIFBBQ0tBR0VSL3l1bVJvbGxiYWNrPWJvb2w6J1RydWUnDQoy MDE2LTA1LTIxIDAxOjQyOjQyIERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJv bm1lbnQ6NTEwIEVOViBQQUNLQUdFUi95dW1wYWNrYWdlckVuYWJsZWQ9Ym9vbDonRmFsc2UnDQoy MDE2LTA1LTIxIDAxOjQyOjQyIERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJv bm1lbnQ6NTEwIEVOViBTWVNURU0vY2xvY2tNYXhHYXA9aW50Oic1Jw0KMjAxNi0wNS0yMSAwMTo0 Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYg U1lTVEVNL2Nsb2NrU2V0PWJvb2w6J0ZhbHNlJw0KMjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBv dG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgU1lTVEVNL2NvbW1h bmRQYXRoPXN0cjonL3Vzci9sb2NhbC9zYmluOi91c3IvbG9jYWwvYmluOi91c3Ivc2JpbjovdXNy L2Jpbjovc2JpbjovYmluJw0KMjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0 IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgU1lTVEVNL3JlYm9vdD1ib29sOidGYWxz ZScNCjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0LmR1bXBF bnZpcm9ubWVudDo1MTAgRU5WIFNZU1RFTS9yZWJvb3RBbGxvdz1ib29sOidUcnVlJw0KMjAxNi0w NS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50 OjUxMCBFTlYgU1lTVEVNL3JlYm9vdERlZmVyVGltZT1pbnQ6JzEwJw0KMjAxNi0wNS0yMSAwMTo0 Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxNCBFTlZJ Uk9OTUVOVCBEVU1QIC0gRU5EDQoyMDE2LTA1LTIxIDAxOjQyOjQyIERFQlVHIG90b3BpLmNvbnRl eHQgY29udGV4dC5fZXhlY3V0ZU1ldGhvZDoxNDIgU3RhZ2UgcHJlLXRlcm1pbmF0ZSBNRVRIT0Qg b3RvcGkucGx1Z2lucy5vdG9waS5kaWFsb2cuY2xpLlBsdWdpbi5fcHJlX3Rlcm1pbmF0ZQ0KMjAx Ni0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQuX2V4ZWN1dGVNZXRo b2Q6MTQ4IGNvbmRpdGlvbiBGYWxzZQ0KMjAxNi0wNS0yMSAwMTo0Mjo0MiBJTkZPIG90b3BpLmNv bnRleHQgY29udGV4dC5ydW5TZXF1ZW5jZTo0MjcgU3RhZ2U6IFRlcm1pbmF0aW9uDQoyMDE2LTA1 LTIxIDAxOjQyOjQyIERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5ydW5TZXF1ZW5jZTo0MzEg U1RBR0UgdGVybWluYXRlDQoyMDE2LTA1LTIxIDAxOjQyOjQyIERFQlVHIG90b3BpLmNvbnRleHQg Y29udGV4dC5fZXhlY3V0ZU1ldGhvZDoxNDIgU3RhZ2UgdGVybWluYXRlIE1FVEhPRCBvdG9waS5w bHVnaW5zLm92aXJ0X2hvc3RlZF9lbmdpbmVfc2V0dXAuY29yZS5taXNjLlBsdWdpbi5fdGVybWlu YXRlDQoyMDE2LTA1LTIxIDAxOjQyOjQyIEVSUk9SIG90b3BpLnBsdWdpbnMub3ZpcnRfaG9zdGVk X2VuZ2luZV9zZXR1cC5jb3JlLm1pc2MgbWlzYy5fdGVybWluYXRlOjE3MCBIb3N0ZWQgRW5naW5l IGRlcGxveW1lbnQgZmFpbGVkOiB0aGlzIHN5c3RlbSBpcyBub3QgcmVsaWFibGUsIHBsZWFzZSBj aGVjayB0aGUgaXNzdWUsIGZpeCBhbmQgcmVkZXBsb3kNCjIwMTYtMDUtMjEgMDE6NDI6NDIgREVC VUcgb3RvcGkucGx1Z2lucy5vdG9waS5kaWFsb2cuaHVtYW4gZGlhbG9nLl9fbG9nU3RyaW5nOjIx OSBESUFMT0c6U0VORCAgICAgICAgICAgICAgICAgTG9nIGZpbGUgaXMgbG9jYXRlZCBhdCAvdmFy L2xvZy9vdmlydC1ob3N0ZWQtZW5naW5lLXNldHVwL292aXJ0LWhvc3RlZC1lbmdpbmUtc2V0dXAt MjAxNjA1MjEwMTMxNDctbWszY21zLmxvZw0KMjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9w aS5jb250ZXh0IGNvbnRleHQuX2V4ZWN1dGVNZXRob2Q6MTQyIFN0YWdlIHRlcm1pbmF0ZSBNRVRI T0Qgb3RvcGkucGx1Z2lucy5vdG9waS5kaWFsb2cuaHVtYW4uUGx1Z2luLl90ZXJtaW5hdGUNCjIw MTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0Ll9leGVjdXRlTWV0 aG9kOjE0MiBTdGFnZSB0ZXJtaW5hdGUgTUVUSE9EIG90b3BpLnBsdWdpbnMub3RvcGkuZGlhbG9n Lm1hY2hpbmUuUGx1Z2luLl90ZXJtaW5hdGUNCjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3Rv cGkuY29udGV4dCBjb250ZXh0Ll9leGVjdXRlTWV0aG9kOjE0OCBjb25kaXRpb24gRmFsc2UNCjIw MTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0Ll9leGVjdXRlTWV0 aG9kOjE0MiBTdGFnZSB0ZXJtaW5hdGUgTUVUSE9EIG90b3BpLnBsdWdpbnMub3RvcGkuY29yZS5s b2cuUGx1Z2luLl90ZXJtaW5hdGUNCg== --_000_SN1PR08MB13891E43AC557902F457B133A64C0SN1PR08MB1389namp_ Content-Type: text/html; charset="utf-8" Content-ID: <1E387677AE22424480FD1BAD64C5C36A(a)sct-15-1-485-2-msonline-outlook-1173a.templateTenant> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKA mXZlIHRyaWVkIG92ZXIgJmFtcDsgb3ZlciBvbiBmcmVzaCBpbnN0YWxscyB0byBzZXR1cCB0aGUg aG9zdGVkIGVuZ2luZSBWTSBob3dldmVyLCBlYWNoIHRpbWUsIGl0IGZhaWxzLiBObyBjbHVlIGFz IHRvIHdoYXQgdGhlIHByb2JsZW0gaXMgYXMgaXQganVzdCBzYXlzIOKAnHRoaXMgc3lzdGVtIGlz IHVucmVsaWFibGXigJ0uPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vLy8vLy8vLy8vLzwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9n IG91dHB1dDo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi8vLy8vLy8vLy8vPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2LTA1LTIx IDAxOjQyOjQyIERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJvbm1lbnQ6NTEw IEVOViBPVkVIT1NURURfVk0vbmljVVVJRD1zdHI6JzU4YTI4YTVlLTVkMGUtNGFjMy04MzVhLWEx ZTliMGRmNmFlNic8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2LTA1LTIxIDAxOjQyOjQy IERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJvbm1lbnQ6NTEwIEVOViBPVkVI T1NURURfVk0vb3ZmQXJjaGl2ZT11bmljb2RlOicvdXNyL3NoYXJlL292aXJ0LWVuZ2luZS1hcHBs aWFuY2Uvb3ZpcnQtZW5naW5lLWFwcGxpYW5jZS0zLjYtMjAxNjA0MjAuMS5lbDcuY2VudG9zLm92 YSc8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2LTA1LTIxIDAxOjQyOjQyIERFQlVHIG90 b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJvbm1lbnQ6NTEwIEVOViBPVkVIT1NURURfVk0v c3Vic3Q9ZGljdDoneydAQ0RST01AJzogJy90bXAvdG1wVHlMOElXL3NlZWQuaXNvJywgJ0BTRF9V VUlEQCc6ICcyNDU1YWE4MS0xNDZmLTRhNmUtYmQ2Yy1jMzY4ZmExZDEwYjgnLCAnQENPTlNPTEVf VVVJREAnOiAnYmVmNTAzYjEtNDIyNC00ZDgyLThhY2QtOGIwM2QyMWFlNjBiJywNCiAnQE5BTUVA JzogJ0hvc3RlZEVuZ2luZScsICdAQlJJREdFQCc6ICdvdmlydG1nbXQnLCAnQENEUk9NX1VVSURA JzogJzRmNjRlOGJhLTUyNTMtNGI5Yy1iMWE3LWJjNTUwZTIyZjA5NycsICdATUVNX1NJWkVAJzog NDA5NiwgJ0BOSUNfVVVJREAnOiAnNThhMjhhNWUtNWQwZS00YWMzLTgzNWEtYTFlOWIwZGY2YWU2 JywgJ0BCT09UX0NEUk9NQCc6ICcnLCAnQFZDUFVTQCc6ICc0JywgJ0BDUFVfVFlQRUAnOiAnU2Fu ZHlCcmlkZ2UnLCAnQFZNX1VVSURAJzoNCiAnOGNjMzBiYmYtOGY0Yi00ZmNlLWFlNGEtZmZkNDc2 YmFmMmIzJywgJ0BFTVVMQVRFRF9NQUNISU5FQCc6ICdwYycsICdAQk9PVF9QWEVAJzogJycsICdA SU1HX1VVSURAJzogJzQxNDhmYjcyLTczZjEtNGQ4Zi04MzY4LTViNmUxZGRiNGU5NicsICdAQk9P VF9ESVNLQCc6ICcsYm9vdE9yZGVyOjEnLCAnQENPTlNPTEVfVFlQRUAnOiAndm5jJywgJ0BNQUNf QUREUkAnOiAnMDA6MTY6M2U6NDE6MjE6ZGInLCAnQFNQX1VVSURAJzogJzAwMDAwMDAwLTAwMDAt MDAwMC0wMDAwLTAwMDAwMDAwMDAwMCcsDQogJ0BWT0xfVVVJREAnOiAnOWMxNzUzMjktN2QxYS00 YjUxLTgyMTgtOGEyNTEyMzA1Njg0J30nPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0w NS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50 OjUxMCBFTlYgT1ZFSE9TVEVEX1ZNL3ZtQm9vdD1zdHI6J2Rpc2snPC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQu ZHVtcEVudmlyb25tZW50OjUxMCBFTlYgT1ZFSE9TVEVEX1ZNL3ZtQ0RSb209Tm9uZVR5cGU6J05v bmUnPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBv dG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgT1ZFSE9TVEVEX1ZN L3ZtTUFDQWRkcj1zdHI6JzAwOjE2OjNlOjQxOjIxOmRiJzwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0LmR1bXBF bnZpcm9ubWVudDo1MTAgRU5WIE9WRUhPU1RFRF9WTS92bU1lbVNpemVNQj1pbnQ6JzQwOTYnPC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5j b250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgT1ZFSE9TVEVEX1ZNL3ZtVVVJ RD1zdHI6JzhjYzMwYmJmLThmNGItNGZjZS1hZTRhLWZmZDQ3NmJhZjJiMyc8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4yMDE2LTA1LTIxIDAxOjQyOjQyIERFQlVHIG90b3BpLmNvbnRleHQgY29u dGV4dC5kdW1wRW52aXJvbm1lbnQ6NTEwIEVOViBPVkVIT1NURURfVk0vdm1WQ3B1cz1zdHI6JzQn PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9w aS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgT1ZFU0VUVVBfQ09SRS9v ZmZsaW5lUGFja2FnZXI9Ym9vbDonVHJ1ZSc8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2 LTA1LTIxIDAxOjQyOjQyIERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJvbm1l bnQ6NTEwIEVOViBQQUNLQUdFUi9kbmZEaXNhYmxlZFBsdWdpbnM9bGlzdDonW10nPC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0 IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgUEFDS0FHRVIvZG5mRXhwaXJlQ2FjaGU9 Ym9vbDonVHJ1ZSc8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2LTA1LTIxIDAxOjQyOjQy IERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJvbm1lbnQ6NTEwIEVOViBQQUNL QUdFUi9kbmZSb2xsYmFjaz1ib29sOidUcnVlJzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIw MTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0LmR1bXBFbnZpcm9u bWVudDo1MTAgRU5WIFBBQ0tBR0VSL2RuZnBhY2thZ2VyRW5hYmxlZD1ib29sOidUcnVlJzwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29u dGV4dCBjb250ZXh0LmR1bXBFbnZpcm9ubWVudDo1MTAgRU5WIFBBQ0tBR0VSL2tlZXBBbGl2ZUlu dGVydmFsPWludDonMzAnPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wNS0yMSAwMTo0 Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYg UEFDS0FHRVIveXVtRGlzYWJsZWRQbHVnaW5zPWxpc3Q6J1tdJzwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0LmR1 bXBFbnZpcm9ubWVudDo1MTAgRU5WIFBBQ0tBR0VSL3l1bUVuYWJsZWRQbHVnaW5zPWxpc3Q6J1td JzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3Rv cGkuY29udGV4dCBjb250ZXh0LmR1bXBFbnZpcm9ubWVudDo1MTAgRU5WIFBBQ0tBR0VSL3l1bUV4 cGlyZUNhY2hlPWJvb2w6J1RydWUnPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wNS0y MSAwMTo0Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUx MCBFTlYgUEFDS0FHRVIveXVtUm9sbGJhY2s9Ym9vbDonVHJ1ZSc8L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4yMDE2LTA1LTIxIDAxOjQyOjQyIERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5k dW1wRW52aXJvbm1lbnQ6NTEwIEVOViBQQUNLQUdFUi95dW1wYWNrYWdlckVuYWJsZWQ9Ym9vbDon RmFsc2UnPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJV RyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgU1lTVEVNL2Ns b2NrTWF4R2FwPWludDonNSc8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2LTA1LTIxIDAx OjQyOjQyIERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5kdW1wRW52aXJvbm1lbnQ6NTEwIEVO ViBTWVNURU0vY2xvY2tTZXQ9Ym9vbDonRmFsc2UnPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ MjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmly b25tZW50OjUxMCBFTlYgU1lTVEVNL2NvbW1hbmRQYXRoPXN0cjonL3Vzci9sb2NhbC9zYmluOi91 c3IvbG9jYWwvYmluOi91c3Ivc2JpbjovdXNyL2Jpbjovc2JpbjovYmluJzwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250 ZXh0LmR1bXBFbnZpcm9ubWVudDo1MTAgRU5WIFNZU1RFTS9yZWJvb3Q9Ym9vbDonRmFsc2UnPC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5j b250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgU1lTVEVNL3JlYm9vdEFsbG93 PWJvb2w6J1RydWUnPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wNS0yMSAwMTo0Mjo0 MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQuZHVtcEVudmlyb25tZW50OjUxMCBFTlYgU1lT VEVNL3JlYm9vdERlZmVyVGltZT1pbnQ6JzEwJzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIw MTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0LmR1bXBFbnZpcm9u bWVudDo1MTQgRU5WSVJPTk1FTlQgRFVNUCAtIEVORDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0Ll9leGVjdXRl TWV0aG9kOjE0MiBTdGFnZSBwcmUtdGVybWluYXRlIE1FVEhPRCBvdG9waS5wbHVnaW5zLm90b3Bp LmRpYWxvZy5jbGkuUGx1Z2luLl9wcmVfdGVybWluYXRlPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+MjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5jb250ZXh0IGNvbnRleHQuX2V4ZWN1 dGVNZXRob2Q6MTQ4IGNvbmRpdGlvbiBGYWxzZTwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIw MTYtMDUtMjEgMDE6NDI6NDIgSU5GTyBvdG9waS5jb250ZXh0IGNvbnRleHQucnVuU2VxdWVuY2U6 NDI3IFN0YWdlOiBUZXJtaW5hdGlvbjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTYtMDUt MjEgMDE6NDI6NDIgREVCVUcgb3RvcGkuY29udGV4dCBjb250ZXh0LnJ1blNlcXVlbmNlOjQzMSBT VEFHRSB0ZXJtaW5hdGU8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2LTA1LTIxIDAxOjQy OjQyIERFQlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5fZXhlY3V0ZU1ldGhvZDoxNDIgU3RhZ2Ug dGVybWluYXRlIE1FVEhPRCBvdG9waS5wbHVnaW5zLm92aXJ0X2hvc3RlZF9lbmdpbmVfc2V0dXAu Y29yZS5taXNjLlBsdWdpbi5fdGVybWluYXRlPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAx Ni0wNS0yMSAwMTo0Mjo0MiBFUlJPUiBvdG9waS5wbHVnaW5zLm92aXJ0X2hvc3RlZF9lbmdpbmVf c2V0dXAuY29yZS5taXNjIG1pc2MuX3Rlcm1pbmF0ZToxNzAgSG9zdGVkIEVuZ2luZSBkZXBsb3lt ZW50IGZhaWxlZDogdGhpcyBzeXN0ZW0gaXMgbm90IHJlbGlhYmxlLCBwbGVhc2UgY2hlY2sgdGhl IGlzc3VlLCBmaXggYW5kIHJlZGVwbG95PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0w NS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5wbHVnaW5zLm90b3BpLmRpYWxvZy5odW1hbiBkaWFs b2cuX19sb2dTdHJpbmc6MjE5IERJQUxPRzpTRU5EJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IExvZyBmaWxlIGlzIGxvY2F0ZWQgYXQgL3Zhci9sb2cvb3ZpcnQtaG9zdGVk LWVuZ2luZS1zZXR1cC9vdmlydC1ob3N0ZWQtZW5naW5lLXNldHVwLTIwMTYwNTIxMDEzMTQ3LW1r M2Ntcy5sb2c8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2LTA1LTIxIDAxOjQyOjQyIERF QlVHIG90b3BpLmNvbnRleHQgY29udGV4dC5fZXhlY3V0ZU1ldGhvZDoxNDIgU3RhZ2UgdGVybWlu YXRlIE1FVEhPRCBvdG9waS5wbHVnaW5zLm90b3BpLmRpYWxvZy5odW1hbi5QbHVnaW4uX3Rlcm1p bmF0ZTwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTYtMDUtMjEgMDE6NDI6NDIgREVCVUcg b3RvcGkuY29udGV4dCBjb250ZXh0Ll9leGVjdXRlTWV0aG9kOjE0MiBTdGFnZSB0ZXJtaW5hdGUg TUVUSE9EIG90b3BpLnBsdWdpbnMub3RvcGkuZGlhbG9nLm1hY2hpbmUuUGx1Z2luLl90ZXJtaW5h dGU8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2LTA1LTIxIDAxOjQyOjQyIERFQlVHIG90 b3BpLmNvbnRleHQgY29udGV4dC5fZXhlY3V0ZU1ldGhvZDoxNDggY29uZGl0aW9uIEZhbHNlPC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wNS0yMSAwMTo0Mjo0MiBERUJVRyBvdG9waS5j b250ZXh0IGNvbnRleHQuX2V4ZWN1dGVNZXRob2Q6MTQyIFN0YWdlIHRlcm1pbmF0ZSBNRVRIT0Qg b3RvcGkucGx1Z2lucy5vdG9waS5jb3JlLmxvZy5QbHVnaW4uX3Rlcm1pbmF0ZTwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR08MB13891E43AC557902F457B133A64C0SN1PR08MB1389namp_--

2 1

RFC - dropping ISO domain creation from engine-setup
by Sandro Bonazzola 22 May '16

22 May '16

Hi, I'd like to get comments on removing ISO domain creation from engine-setup. ISO domain creation was included in 3.2 for allowing to finish the setup with ISO domain ready to serve Windows Guest Tools which is injected into the iso domain if the rpm is installed. The NFS share was created *(rw) in 3.2. In later releases we first restricted access, then asked the user to provide access policy during setup and now we moved the default to not create the ISO domain. We have several issues with iso domain creation: Bug 1302745 <https://bugzilla.redhat.com/show_bug.cgi?id=1302745> - [engine-setup] creation of iso domain path is not rolled back, a next attempt leaves an empty domain Bug 1332813 <https://bugzilla.redhat.com/show_bug.cgi?id=1332813> - Hosted engine should not allow iso domain to be configured in the RHEV-M VM Having ISO domain within hosted engine leads to really bad issues and we're streamlining the hosted engine installation with NGN, cockpit and appliance so HE will be the most easy way to have oVirt installed making ISO domain not useful and even dangerous in engine-setup. For this reason the bug has ben changed in: Deprecate the ISO domain setup on the RHEV-M machine (hide it in 4.0) Meaning that using answer file you'll be able to create it anyway in 4.0 but the question won't be exposed in interactive setup. Any concern about this change? Any comment? Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 3

unreachable iso domain
by Fabrice Bacchella 21 May '16

21 May '16

--Apple-Mail=_00AFD7BD-2DBB-487F-96CD-3D6FDE49EB9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I try to attach an iso domain but it keep saying that it doesn't exist. = But if I look in = /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf, the directory = given in OVESETUP_CONFIG/isoDomainStorageDir exists and the logs says : =20 2016-05-19 19:23:23,900 ERROR = [org.ovirt.engine.core.vdsbroker.irsbroker.AttachStorageDomainVDSCommand] = (org.ovirt.thread.pool-8-thread-19) [78115edf] Command = 'AttachStorageDomainVDSCommand( = AttachStorageDomainVDSCommandParameters:{runAsync=3D'true', = storagePoolId=3D'17434f4e-8d1a-4a88-ae39-d2ddd46b3b9b', = ignoreFailoverLimit=3D'false', = storageDomainId=3D'2a9fe2d7-ea38-4ced-a274-32734b7b571b'})' execution = failed: IRSGenericException: IRSErrorException: Failed to = AttachStorageDomainVDS, error =3D Storage domain does not exist: = (u'2a9fe2d7-ea38-4ced-a274-32734b7b571b',), code =3D 358 Does code =3D 358 means something important ? --Apple-Mail=_00AFD7BD-2DBB-487F-96CD-3D6FDE49EB9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;" class=3D"">I try to attach an iso domain but it keep saying that = it doesn't exist. But if I look in = /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf, the directory = given in OVESETUP_CONFIG/isoDomainStorageDir exists and the logs says = :</div><div style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D""> </div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">2016-05-19 19:23:23,900 ERROR = [org.ovirt.engine.core.vdsbroker.irsbroker.AttachStorageDomainVDSCommand] = (org.ovirt.thread.pool-8-thread-19) [78115edf] Command = 'AttachStorageDomainVDSCommand( = AttachStorageDomainVDSCommandParameters:{runAsync=3D'true', = storagePoolId=3D'17434f4e-8d1a-4a88-ae39-d2ddd46b3b9b', = ignoreFailoverLimit=3D'false', = storageDomainId=3D'2a9fe2d7-ea38-4ced-a274-32734b7b571b'})' execution = failed: IRSGenericException: IRSErrorException: Failed to = AttachStorageDomainVDS, error =3D Storage domain does not exist: = (u'2a9fe2d7-ea38-4ced-a274-32734b7b571b',), code =3D 358</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" class=3D""><br= class=3D""></div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">Does code =3D 358 means something = important ?</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D""><br class=3D""></div></body></html>= --Apple-Mail=_00AFD7BD-2DBB-487F-96CD-3D6FDE49EB9C--

3 2

gluster VM disk permissions
by Bill James 19 May '16

19 May '16

--------------060108010807030305050803 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit I tried posting this to ovirt-users list but got no response so I'll try here too. I just setup a new ovirt cluster with gluster & nfs data domains. VMs on the NFS domain startup with no issues. VMs on the gluster domains complain of "Permission denied" on startup. 2016-05-17 14:14:51,959 ERROR [org.ovirt.engine.core.dal.dbbroker.audi tloghandling.AuditLogDirector] (ForkJoinPool-1-worker-11) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VM billj7-2.j2noc.com is down with error. Exit message: internal error: process exited while connecting to monitor: 2016-05-17T21:14:51.162932Z qemu-kvm: -drive file=/rhev/data-center/00000001-0001-0001-0001-0000000002c5/22df0943-c131-4ed8-ba9c-05923afcf8e3/images/2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25/a2b0a04d-041f-4342-9687-142cc641b35e,if=none,id=drive-virtio-disk0,format=raw,serial=2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25,cache=none,werror=stop,rerror=stop,aio=threads: Could not open '/rhev/data-center/00000001-0001-0001-0001-0000000002c5/22df0943-c131-4ed8-ba9c-05923afcf8e3/images/2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25/a2b0a04d-041f-4342-9687-142cc641b35e': Permission denied I did setup gluster permissions: gluster volume set gv1 storage.owner-uid 36 gluster volume set gv1 storage.owner-gid 36 files look fine: [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# ls -lah total 2.0G drwxr-xr-x 2 vdsm kvm 4.0K May 17 09:39 . drwxr-xr-x 11 vdsm kvm 4.0K May 17 10:40 .. -rw-rw---- 1 vdsm kvm 20G May 17 10:33 a2b0a04d-041f-4342-9687-142cc641b35e -rw-rw---- 1 vdsm kvm 1.0M May 17 09:38 a2b0a04d-041f-4342-9687-142cc641b35e.lease -rw-r--r-- 1 vdsm kvm 259 May 17 09:39 a2b0a04d-041f-4342-9687-142cc641b35e.meta I did check and vdsm user can read the file just fine. *If I change mod disk to 666 VM starts up fine.* ALso if I chgrp to qemu VM starts up fine. [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l 253f9615-f111-45ca-bdce-cbc9e70406df -rw-rw---- 1 vdsm qemu 21474836480 May 18 11:38 253f9615-f111-45ca-bdce-cbc9e70406df Seems similar to issue here but that suggests it was fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1052114 [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# grep 36 /etc/passwd /etc/group /etc/passwd:vdsm:x:36:36:Node Virtualization Manager:/:/bin/bash /etc/group:kvm:x:36:qemu,sanlock ovirt-engine-3.6.4.1-1.el7.centos.noarch glusterfs-3.7.11-1.el7.x86_64 qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64 qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64 libvirt-daemon-1.2.17-13.el7_2.4.x86_64 I also set libvirt qemu user to root, for import-to-ovirt.pl script. [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# grep ^user /etc/libvirt/qemu.conf user = "root" [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# gluster volume info gv1 Volume Name: gv1 Type: Replicate Volume ID: 062aa1a5-91e8-420d-800e-b8bc4aff20d8 Status: Started Number of Bricks: 1 x 3 = 3 Transport-type: tcp Bricks: Brick1: ovirt1-gl.j2noc.com:/ovirt-store/brick1/gv1 Brick2: ovirt2-gl.j2noc.com:/ovirt-store/brick1/gv1 Brick3: ovirt3-gl.j2noc.com:/ovirt-store/brick1/gv1 Options Reconfigured: performance.readdir-ahead: on performance.quick-read: off performance.read-ahead: off performance.io-cache: off performance.stat-prefetch: off cluster.eager-lock: enable network.remote-dio: enable cluster.quorum-type: auto cluster.server-quorum-type: server features.shard: on features.shard-block-size: 64MB storage.owner-uid: 36 storage.owner-gid: 36 [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# gluster volume status gv1 Status of volume: gv1 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick ovirt1-gl.j2noc.com:/ovirt-store/bric k1/gv1 49152 0 Y 2046 Brick ovirt2-gl.j2noc.com:/ovirt-store/bric k1/gv1 49152 0 Y 22532 Brick ovirt3-gl.j2noc.com:/ovirt-store/bric k1/gv1 49152 0 Y 59683 NFS Server on localhost 2049 0 Y 2200 Self-heal Daemon on localhost N/A N/A Y 2232 NFS Server on ovirt3-gl.j2noc.com 2049 0 Y 65363 Self-heal Daemon on ovirt3-gl.j2noc.com N/A N/A Y 65371 NFS Server on ovirt2-gl.j2noc.com 2049 0 Y 17621 Self-heal Daemon on ovirt2-gl.j2noc.com N/A N/A Y 17629 Task Status of Volume gv1 ------------------------------------------------------------------------------ There are no active volume tasks any ideas on why ovirt thinks it needs group of qemu?? --------------060108010807030305050803 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> I tried posting this to ovirt-users list but got no response so I'll try here too.<br> <br> <div class="moz-text-html" lang="x-unicode"><br> I just setup a new ovirt cluster with gluster & nfs data domains.<br> <br> VMs on the NFS domain startup with no issues.<br> VMs on the gluster domains complain of "Permission denied" on startup.<br> <br> 2016-05-17 14:14:51,959 ERROR [org.ovirt.engine.core.dal.dbbroker.audi<br> tloghandling.AuditLogDirector] (ForkJoinPool-1-worker-11) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VM billj7-2.j2noc.com is down with error. Exit message: internal error: process exited while connecting to monitor: 2016-05-17T21:14:51.162932Z qemu-kvm: -drive file=/rhev/data-center/00000001-0001-0001-0001-0000000002c5/22df0943-c131-4ed8-ba9c-05923afcf8e3/images/2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25/a2b0a04d-041f-4342-9687-142cc641b35e,if=none,id=drive-virtio-disk0,format=raw,serial=2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25,cache=none,werror=stop,rerror=stop,aio=threads: Could not open '/rhev/data-center/00000001-0001-0001-0001-0000000002c5/22df0943-c131-4ed8-ba9c-05923afcf8e3/images/2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25/a2b0a04d-041f-4342-9687-142cc641b35e': Permission denied<br> <br> <br> I did setup gluster permissions:<br> gluster volume set gv1 storage.owner-uid 36<br> gluster volume set gv1 storage.owner-gid 36<br> <br> files look fine:<br> [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# ls -lah<br> total 2.0G<br> drwxr-xr-x 2 vdsm kvm 4.0K May 17 09:39 .<br> drwxr-xr-x 11 vdsm kvm 4.0K May 17 10:40 ..<br> -rw-rw---- 1 vdsm kvm 20G May 17 10:33 a2b0a04d-041f-4342-9687-142cc641b35e<br> -rw-rw---- 1 vdsm kvm 1.0M May 17 09:38 a2b0a04d-041f-4342-9687-142cc641b35e.lease<br> -rw-r--r-- 1 vdsm kvm 259 May 17 09:39 a2b0a04d-041f-4342-9687-142cc641b35e.meta<br> <br> I did check and vdsm user can read the file just fine.<br> <b>If I change mod disk to 666 VM starts up fine.</b><br> ALso if I chgrp to qemu VM starts up fine.<br> <br> [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l 253f9615-f111-45ca-bdce-cbc9e70406df<br> -rw-rw---- 1 vdsm qemu 21474836480 May 18 11:38 253f9615-f111-45ca-bdce-cbc9e70406df<br> <br> <br> Seems similar to issue here but that suggests it was fixed: <br> <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1052114">https://bugzilla.redhat.com/show_bug.cgi?id=1052114</a><br> <br> <br> <br> [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# grep 36 /etc/passwd /etc/group<br> /etc/passwd:vdsm:x:36:36:Node Virtualization Manager:/:/bin/bash<br> /etc/group:kvm:x:36:qemu,sanlock<br> <br> <br> ovirt-engine-3.6.4.1-1.el7.centos.noarch<br> glusterfs-3.7.11-1.el7.x86_64<br> qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64<br> qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64<br> libvirt-daemon-1.2.17-13.el7_2.4.x86_64<br> <br> <br> I also set libvirt qemu user to root, for import-to-ovirt.pl script.<br> <br> [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# grep ^user /etc/libvirt/qemu.conf <br> user = "root"<br> <br> <br> [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# gluster volume info gv1<br> <br> Volume Name: gv1<br> Type: Replicate<br> Volume ID: 062aa1a5-91e8-420d-800e-b8bc4aff20d8<br> Status: Started<br> Number of Bricks: 1 x 3 = 3<br> Transport-type: tcp<br> Bricks:<br> Brick1: ovirt1-gl.j2noc.com:/ovirt-store/brick1/gv1<br> Brick2: ovirt2-gl.j2noc.com:/ovirt-store/brick1/gv1<br> Brick3: ovirt3-gl.j2noc.com:/ovirt-store/brick1/gv1<br> Options Reconfigured:<br> performance.readdir-ahead: on<br> performance.quick-read: off<br> performance.read-ahead: off<br> performance.io-cache: off<br> performance.stat-prefetch: off<br> cluster.eager-lock: enable<br> network.remote-dio: enable<br> cluster.quorum-type: auto<br> cluster.server-quorum-type: server<br> features.shard: on<br> features.shard-block-size: 64MB<br> storage.owner-uid: 36<br> storage.owner-gid: 36<br> <br> [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# gluster volume status gv1<br> Status of volume: gv1<br> Gluster process TCP Port RDMA Port Online Pid<br> ------------------------------------------------------------------------------<br> Brick ovirt1-gl.j2noc.com:/ovirt-store/bric<br> k1/gv1 49152 0 Y 2046 <br> Brick ovirt2-gl.j2noc.com:/ovirt-store/bric<br> k1/gv1 49152 0 Y 22532<br> Brick ovirt3-gl.j2noc.com:/ovirt-store/bric<br> k1/gv1 49152 0 Y 59683<br> NFS Server on localhost 2049 0 Y 2200 <br> Self-heal Daemon on localhost N/A N/A Y 2232 <br> NFS Server on ovirt3-gl.j2noc.com 2049 0 Y 65363<br> Self-heal Daemon on ovirt3-gl.j2noc.com N/A N/A Y 65371<br> NFS Server on ovirt2-gl.j2noc.com 2049 0 Y 17621<br> Self-heal Daemon on ovirt2-gl.j2noc.com N/A N/A Y 17629<br> <br> Task Status of Volume gv1<br> ------------------------------------------------------------------------------<br> There are no active volume tasks<br> <br> <br> <br> any ideas on why ovirt thinks it needs group of qemu??<br> <br> <br> </div> <br> </body> </html> --------------060108010807030305050803--

1 0

100% memory usage on desktop environments
by Nicolás 19 May '16

19 May '16

Hi, Probably not an oVirt issue, but maybe someone can help. I've deployed a pretty basic VM (ubuntu 14.04 server, 4GB RAM, 4 CPUs, 15GB storage). Each time I install an additional desktop environment (Gnome, KDE, whatever...), CPU usage rises to 100% all time to the extreme that interacting with the machine becomes impossible (maybe a mouse movement is propagated 3 minutes later or so...). To debug this, I installed LXDE, which is a lightweight desktop environment based on Xorg. I could see there is an Xorg process consuming one of the CPUs and the machine stops responding as far as the desktop environment goes. I have not changed anything in the configuration file. I could also see this only happens when QXL is chosen as the display driver. When CIRRUS is chosen, everything works smoothly and CPU is ~100% idle. The downside is that we want to use SPICE and CIRRUS won't allow it. Why does this happen? Is this an OS-side driver issue? Any hint how can it be fixed? Thanks. Nicolás

4 3

oVirt All-in-One upgrade path and requested improvements
by Neal Gompa 19 May '16

19 May '16

Hello, I recently found out that oVirt "deprecated" the All-in-One configuration option in oVirt 3.6 and removed it in oVirt 4.0. This is a huge problem for me, as it means that my oVirt machines don't have an upgrade path. My experiments with the self-hosted engine have ended in failure for a couple of reasons: * The hosted engine deploy expects that a FQDN is already paired with an IP address. This is obviously false in most home environments, and even in the work environment where I use oVirt regularly. There's no workaround for this (except having a third machine to run the engine!), and this utterly breaks the only way to use oVirt in a DHCP-centric environment where I may not control the network addressing. * Other error states have caused the whole thing to break and just leave the system a broken mess. With no way to clean up, I'm left guessing how to undo everything, which is hellish and leads me to just wipe the whole system and start over. In addition, I was hoping that there would be improvements with the single system case, rather than destruction of this capability. Some of the improvements are things I think would be useful in even a multi-node setup, too. For example, I would like to see live migration capabilities with local storage across datacenters, as this capability in vMotion makes deployments a lot more flexible. Sometimes, local storage is really the only way to get the kind of speed needed for some workloads, and being able to offer some kind of HA for VMs on local storage would be excellent. In addition to being useful for all-in-one setups, it's quite useful for self-hosted engine configurations, too. It's also rather irritating that there's no way to migrate stuff from shared storage to local storage and back. On top of that, datacenters that have local storage can't have shared storage or vice versa. On top of that, it looks like the all-in-one code is being kept around anyway for the oVirt Live stuff, so why not just keep the capability and improve it? oVirt should become the best virtualization solution for everyone, not just people who have access to huge datacenters where all the conditions are perfect. -- 真実はいつも一つ！/ Always, there's only one truth!

3 3

[ANN] oVirt 4.0.0 First Beta Release is now available for testing
by Sandro Bonazzola 19 May '16

19 May '16

The oVirt Project is pleased to announce the availability of the First Beta Release of oVirt 4.0.0 for testing, as of May 19th, 2016 This is pre-release software. Please take a look at our community page[1] to know how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This pre-release should not to be used in production. This release is available now for: * Fedora 23 * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 23 * oVirt Next Generation Node 4.0 See the release notes draft [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO is already available [4]. * A new oVirt Next Generation Node is already available [4] * A new oVirt Engine Appliance is already available [4] * A new oVirt Guest Tools ISO is already available [4] * Mirrors[5] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 4.0.0 alpha release highlights: http://www.ovirt.org/release/4.0.0/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.0.0/ [4] http://resources.ovirt.org/pub/ovirt-4.0_beta1/iso/ [5] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Re: [ovirt-users] oVirt hosted-engine setup stuck in final phase registering host to engine
by Ralf Schenk 19 May '16

19 May '16

This is a multi-part message in MIME format. --------------0CC9A5CD7BA82A048CB9D135 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, don't waste time on it. I reinstalled ovirt-hosted-engine-ha.noarch an then after some time engine magically started. I'm now adding hosts to the engine and will deploy two other instances of the engine on two other hosts to get it highly available. So far my gluster seems usable inside the engine and the hosts. If its interesing for you: I also setup up HA nfs-ganesha on the hosts to provide NFS Shares to multiple VM's (will be php-fpm Backends to Nginx) in an efficient way. I also tested and benchmarked (only sysbench) using one host as MDS for pNFS with gluster FSAL. So I'm able to mount my gluster via "mount ... type nfs4 -o minorversion=1" an am rewarded with pnfs=LAYOUT_NFSV4_1_FILES in "/proc/self/mountstats". I can see good network distribution and connections to multiple servers of the cluster when benchmarking an NFS mount. What I don't understand: Engine and also setup seem to have a problem with my type 6 bond. That type proved to be best in glusterfs and nfs performance and distribution over my 2 network-interfaces. Additionally I'm loosing my IPMI on shared LAN if I use a type 4 802.3ad Bond. Thats what i have: eth0___bond0_________br0 (192.168.252.x) for VMs/Hosts eth1__/ \__bond0.10_ovirtmgmt (172.16.252.x, VLAN 10) for Gluster, NFS, Migration, Management Is this ok ? Thanks a lot for your effort. I hope that I can give back something to the community by actively using the mailing-list. Bye Am 18.05.2016 um 16:36 schrieb Simone Tiraboschi: > Really really strange, > adding Martin here. > > > > On Wed, May 18, 2016 at 4:32 PM, Ralf Schenk <rs(a)databay.de > <mailto:rs@databay.de>> wrote: > > Hello, > > When I restart (systemctl restart ovirt-ha-broker ovirt-ha-agent) > broker seems to fail: (from journalctl -xe) > > -- Unit ovirt-ha-agent.service has begun starting up. > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: Traceback > (most recent call last): > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker", line 25, in > <module> > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: > broker.Broker().run() > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/broker.py", > line 56, in run > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: > self._initialize_logging(options.daemon) > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/broker.py", > line 131, in _initialize_logging > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: > level=logging.DEBUG) > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/lib64/python2.7/logging/__init__.py", line 1529, in basicConfig > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: hdlr = > FileHandler(filename, mode) > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__ > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: > StreamHandler.__init__(self, self._open()) > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: stream = > open(self.baseFilename, self.mode) > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: IOError: > [Errno 6] No such device or address: '/dev/stdout' > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: Traceback (most > recent call last): > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/share/ovirt-hosted-engine-ha/ovirt-ha-agent", line 25, in > <module> > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: agent.Agent().run() > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", > line 77, in run > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: > self._initialize_logging(options.daemon) > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", > line 159, in _initialize_logging > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: > level=logging.DEBUG) > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/lib64/python2.7/logging/__init__.py", line 1529, in basicConfig > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: hdlr = > FileHandler(filename, mode) > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__ > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: > StreamHandler.__init__(self, self._open()) > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: stream = > open(self.baseFilename, self.mode) > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: IOError: [Errno > 6] No such device or address: '/dev/stdout' > May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service: > main process exited, code=exited, status=1/FAILURE > May 18 16:26:19 microcloud21 systemd[1]: Unit > ovirt-ha-broker.service entered failed state. > May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service > failed. > May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-agent.service: > main process exited, code=exited, status=1/FAILURE > May 18 16:26:19 microcloud21 systemd[1]: Unit > ovirt-ha-agent.service entered failed state. > May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-agent.service > failed. > May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service > holdoff time over, scheduling restart. > > Of course /dev/stdout exists: > > [root@microcloud21 ~]# ls -al /dev/stdout > lrwxrwxrwx 1 root root 15 May 18 12:29 /dev/stdout -> /proc/self/fd/1 > -- *Ralf Schenk* fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail *rs(a)databay.de* <mailto:rs@databay.de> *Databay AG* Jens-Otto-Krag-Straße 11 D-52146 Würselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) ------------------------------------------------------------------------ --------------0CC9A5CD7BA82A048CB9D135 Content-Type: multipart/related; boundary="------------69E1DCACD77B617618016FDF" --------------69E1DCACD77B617618016FDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <p>Hello,</p> <p>don't waste time on it. I reinstalled ovirt-hosted-engine-ha.noarch an then after some time engine magically started. I'm now adding hosts to the engine and will deploy two other instances of the engine on two other hosts to get it highly available. So far my gluster seems usable inside the engine and the hosts. <br> </p> <p>If its interesing for you: I also setup up HA nfs-ganesha on the hosts to provide NFS Shares to multiple VM's (will be php-fpm Backends to Nginx) in an efficient way. I also tested and benchmarked (only sysbench) using one host as MDS for pNFS with gluster FSAL. So I'm able to mount my gluster via "mount ... type nfs4 -o minorversion=1" an am rewarded with pnfs=LAYOUT_NFSV4_1_FILES in "/proc/self/mountstats". I can see good network distribution and connections to multiple servers of the cluster when benchmarking an NFS mount.</p> <p>What I don't understand: Engine and also setup seem to have a problem with my type 6 bond. That type proved to be best in glusterfs and nfs performance and distribution over my 2 network-interfaces. Additionally I'm loosing my IPMI on shared LAN if I use a type 4 802.3ad Bond.<br> </p> <p>Thats what i have:</p> <p><tt>eth0___bond0_________br0 (192.168.252.x) for VMs/Hosts</tt><tt><br> </tt><tt>eth1__/ \__bond0.10_ovirtmgmt (172.16.252.x, VLAN 10) for Gluster, NFS, Migration, Management</tt><br> </p> <p>Is this ok ?<br> </p> <p>Thanks a lot for your effort. I hope that I can give back something to the community by actively using the mailing-list.</p> <p>Bye<br> </p> <div class="moz-cite-prefix">Am 18.05.2016 um 16:36 schrieb Simone Tiraboschi:<br> </div> <blockquote cite="mid:CAN8-ONr-48CYUXhTNs571DQu=_jCN3uOXUhDBKPSGyTdVzZw0w@mail.gmail.com" type="cite">Really really strange, <div>adding Martin here.</div> <div><br> </div> <div><br> </div> <div class="gmail_extra"><br> <div class="gmail_quote">On Wed, May 18, 2016 at 4:32 PM, Ralf Schenk <span dir="ltr"><<a moz-do-not-send="true" href="mailto:rs@databay.de" target="_blank">rs(a)databay.de</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div bgcolor="#FFFFFF" text="#000000"> <p>Hello,</p> <p>When I restart (systemctl restart ovirt-ha-broker ovirt-ha-agent) broker seems to fail: (from journalctl -xe)<br> </p> <p><tt>-- Unit ovirt-ha-agent.service has begun starting up.</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: Traceback (most recent call last):</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker", line 25, in <module></tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: broker.Broker().run()</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/broker.py", line 56, in run</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: self._initialize_logging(options.daemon)</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/broker.py", line 131, in _initialize_logging</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: level=logging.DEBUG)</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/lib64/python2.7/logging/__init__.py", line 1529, in basicConfig</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: hdlr = FileHandler(filename, mode)</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: StreamHandler.__init__(self, self._open())</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: stream = open(self.baseFilename, self.mode)</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: IOError: [Errno 6] No such device or address: '/dev/stdout'</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: Traceback (most recent call last):</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/share/ovirt-hosted-engine-ha/ovirt-ha-agent", line 25, in <module></tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: agent.Agent().run()</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 77, in run</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: self._initialize_logging(options.daemon)</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 159, in _initialize_logging</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: level=logging.DEBUG)</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/lib64/python2.7/logging/__init__.py", line 1529, in basicConfig</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: hdlr = FileHandler(filename, mode)</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: StreamHandler.__init__(self, self._open())</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: stream = open(self.baseFilename, self.mode)</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: IOError: [Errno 6] No such device or address: '/dev/stdout'</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service: main process exited, code=exited, status=1/FAILURE</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: Unit ovirt-ha-broker.service entered failed state.</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service failed.</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-agent.service: main process exited, code=exited, status=1/FAILURE</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: Unit ovirt-ha-agent.service entered failed state.</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-agent.service failed.</tt><tt><br> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service holdoff time over, scheduling restart.</tt><tt><br> </tt></p> <p>Of course /dev/stdout exists:</p> <p><tt>[root@microcloud21 ~]# ls -al /dev/stdout</tt><tt><br> </tt><tt>lrwxrwxrwx 1 root root 15 May 18 12:29 /dev/stdout -> /proc/self/fd/1</tt><tt><br> </tt></p> </div> </blockquote> </div> </div> </blockquote> <br> <div class="moz-signature">-- <br> <p> </p> <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td colspan="3"><img src="cid:part2.29C79524.2BD951A4@databay.de" height="30" border="0" width="151"></td> </tr> <tr> <td valign="top"> <font face="Verdana, Arial, sans-serif" size="-1"><br> <b>Ralf Schenk</b><br> fon +49 (0) 24 05 / 40 83 70<br> fax +49 (0) 24 05 / 40 83 759<br> mail <a href="mailto:rs@databay.de"><font color="#FF0000"><b>rs(a)databay.de</b></font></a><br> </font> </td> <td width="30"> </td> <td valign="top"> <font face="Verdana, Arial, sans-serif" size="-1"><br> <b>Databay AG</b><br> Jens-Otto-Krag-Straße 11<br> D-52146 Würselen<br> <a href="http://www.databay.de"><font color="#FF0000"><b>www.databay.de</b></font></a> </font> </td> </tr> <tr> <td colspan="3" valign="top"> <font face="Verdana, Arial, sans-serif" size="1"><br> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202<br> Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns<br> Aufsichtsratsvorsitzender: Klaus Scholzen (RA) </font> </td> </tr> </tbody> </table> <hr color="#000000" noshade="noshade" size="1" width="100%"> </div> </body> </html> --------------69E1DCACD77B617618016FDF Content-Type: image/gif; name="logo_databay_email.gif" Content-Transfer-Encoding: base64 Content-ID: <part2.29C79524.2BD951A4(a)databay.de> Content-Disposition: inline; filename="logo_databay_email.gif" R0lGODlhlwAeAMQAAObm5v9QVf/R0oKBgfDw8NfX105MTLi3t/r6+sfHx/+rrf98gC0sLP8L EhIQEKalpf/g4ZmYmHd2dmppaf8uNP/y8v8cIv+Ym//AwkE/P46NjRwbG11cXP8ABwUDA/// /yH5BAAAAAAALAAAAACXAB4AAAX/4CeOYnUJZKqubOu+cCzPNA0tVnfVfO//wGAKk+t0Ap+K QMFUYCDCqHRKJVUWDaPRUsFktZ1G4AKtms9o1gKsFVS+7I5ll67bpd647hPQawNld4KDMQJF bA07F35aFBiEkJEpfXEBjx8KjI0Vkp2DEIdaCySgFBShbEgrCQOtrq+uEQcALQewrQUjEbe8 rgkkD7y5KhMZB3drqSoVFQhdlHGXKQYe1dbX2BvHKwzY1RMiAN7j1xEjBeTmKeIeD3cYCxRf FigvChRxFJwkBBvk5A7cpZhAjgGCDwn+kfslgto4CSoSehh2BwEEBQvowDAUR0EKdArHZTg4 4oDCXBFC/3qj9SEluZEpHnjYQFIGgpo1KgSasYjNKBImrzF4NaFbNgIjCGRQeIyVKwneOLzS cLCAg38OWI4Y4GECgQcSOEwYcADnh6/FNjAwoGFYAQ0atI4AAFeEFwsLFLiJUQEfGH0kNGAD x8+oNQdIRQg+7NCaOhIgD8sVgYADNsPVGI5YWjRqzQTdHDDIYHRDLokaUhCglkFEJi0NKJhl 0RP2TsvXUg88KiLBVWsZrF6DmMKlNYMqglqTik1guN8OBgAgkGCpB+L9ugK4iSCBvwEfECw1 kILrBpa1jVCQIQBRvbP+rlEcQVAoSevWyv6uhpwE12uEkQAAZucpVw1xIsjkgf8B863mQVYt eQATCZYJZJ5WBfij2wfpHcEeHGG8Z+BMszVWDXkfKLhceJhBSAJ+1ThH32AfRFZNayNAtUFi wFSTSwEHJIYAAQU84IADwyjIEALU9MchG+vFgIF7W2GDI2T7HfjBgNcgKQKMHmwjgnCSpeCb ULRkdxhF1CDY40RjgmUAA/v1J5FAKW2gGSZscBFDMraNgJs1AYpAAGYP5jJoNQ4Y4Gh8jpFg HH9mgbmWo1l6oA4C3Ygp6UwEIFBfNRtkMIBlKMLnAXgAXLWhXXH85EIFqMhGGZgDEKArABGA ed0HI4bk5qgnprCYSt88B6dqS0FEEAMPJDCdCJYViur/B1BlwGMJqDTwnhqxJgUpo0ceOQ4D 0yEakpMm/jqCRMgWm2I1j824Y6vLvuuPjHnqOJkIgP6xzwp5sCFNsCFp88Gxh11lrjfDcNrc CEx64/CD3iAHlQcMUEQXvcA+qBkBB4Q2X1CusjBlJdKMYAKI6g28MbKN5hJsBAXknHOwutn4 oFYqkpqAzjnPbE0u1PxmwAQGXLWBbvhuIIEGEnRjlAHO4SvhbCNAkwoGzEBwgV9U0lfu2WiX OkDEGaCdKgl0nk2YkWdPOCDabvaGdkAftL1LlgwCM+7Tq11V71IO7LkM2XE0YAHMYMhqqK6U V165CpaHukLmiXFO8XSVzzakX+UH6TrmAajPNxfqByTQec41AeBPvSwIALkmAnuiexCsca3C BajgfsROuxcPA8kHQJX4DAIwjnsAvhsvfXHWKEwDAljg7sj03L9wwAQTxOWD2AE0YP75eCkw cPfs+xACADs= --------------69E1DCACD77B617618016FDF-- --------------0CC9A5CD7BA82A048CB9D135--

1 0

thin provisioned vm suspend
by Dobó László 19 May '16

19 May '16

Hi, I have an annoying problem with thin provisioned vms, which are on iscsi lvm. When I'm copying big files, qemu often suspending the vm while vdsm extending the volume. (VM test2 has been paused due to no Storage space error) Can i tune this free space detection behavior somehow? - should be good to start lvextend much more earlier. Regards, enax

1 0

Re: [ovirt-users] 100% memory usage on desktop environments
by Karli Sjöberg 18 May '16

18 May '16

--_000_5534f35e19cb423287f13a0e5159163cexch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTggbWFqIDIwMTYgNzo0OCBlbSBza3JldiBOaWNvbMOhcyA8bmljb2xhc0BkZXZlbHMu ZXM+Og0KPg0KPg0KPg0KPiBFbCAxOC8wNS8xNiBhIGxhcyAxODoxMSwgS2FybGkgU2rDtmJlcmcg ZXNjcmliacOzOg0KPj4NCj4+DQo+PiBEZW4gMTggbWFqIDIwMTYgNzowMyBlbSBza3JldiBOaWNv bMOhcyA8bmljb2xhc0BkZXZlbHMuZXM+Og0KPj4gPg0KPj4gPiBIaSBLYXJsaSwNCj4+ID4NCj4+ ID4gRWwgMTgvMDUvMTYgYSBsYXMgMTY6NTksIEthcmxpIFNqw7ZiZXJnIGVzY3JpYmnDszoNCj4+ ID4+DQo+PiA+Pg0KPj4gPj4gRGVuIDE4IG1haiAyMDE2IDU6NDkgZW0gc2tyZXYgTmljb2zDoXMg PG5pY29sYXNAZGV2ZWxzLmVzPjoNCj4+ID4+ID4NCj4+ID4+ID4gSGksDQo+PiA+PiA+DQo+PiA+ PiA+IFByb2JhYmx5IG5vdCBhbiBvVmlydCBpc3N1ZSwgYnV0IG1heWJlIHNvbWVvbmUgY2FuIGhl bHAuIEkndmUgZGVwbG95ZWQgYQ0KPj4gPj4gPiBwcmV0dHkgYmFzaWMgVk0gKHVidW50dSAxNC4w NCBzZXJ2ZXIsIDRHQiBSQU0sIDQgQ1BVcywgMTVHQiBzdG9yYWdlKS4NCj4+ID4+DQo+PiA+PiBK dXN0IHNwaXRiYWxsaW5nIGhlcmU6IDE0LjA0IG9ubHk/IFRyaWVkIDE2LjA0LCBvciBhbnkgb3Ro ZXIgT1MgZm9yIHRoYXQgbWF0dGVyPyBGb3Igbm93LCBpdCBzb3VuZHMgbW9yZSBndWVzdCByZWxh dGVkIHJhdGhlciB0aGFuIG9WaXJ0Lg0KPj4gPj4NCj4+ID4+IC9LDQo+PiA+DQo+PiA+DQo+PiA+ IEkgdHJpZWQgYSB2YW5pbGxhIGNlbnRvcy03LjEgYXMgd2VsbCBhbmQgdGhlIHNhbWUgaGFwcGVu cy4gSSdtIG9mIHRoZSBzYW1lIG9waW5pb24gdGhhdCB0aGlzIGlzIG1vcmUgYSBndWVzdCByZWxh dGVkIGlzc3VlLCBpdCdzIGp1c3QgSSdkIGxpa2UgdG8gZmluZCBvdXQgd2h5IHRoaXMgb25seSBo YXBwZW5zIHdpdGggUVhMIGFuZCBub3Qgd2l0aCBDSVJSVVMuDQo+PiA+DQo+PiA+IFRoYW5rcy4N Cj4+DQo+PiBWZXJ5IGludGVyZXN0aW5nLiBBcmUgeW91ciBob3N0cyBhbGwgb2YgdGhlIHNhbWUg YXJjaGl0ZWN0dXJlKGZhbWlseSk/DQo+Pg0KPj4gL0sNCj4NCj4NCj4gQWN0dWFsbHkgd2UgaGF2 ZSBhIG5pY2UgbWl4dHVyZSBvZiBtYW51ZmFjdHVyZXJzLiBXZSBydW4gNyBob3N0cywgcGFpcmVk IDQtMi0xIGluIHJlbGF0aW9uIHRvIGFyY2hpdGVjdHVyZS4gQWxsIG9mIHRoZW0gaGF2ZSB0aGUg c2FtZSByZXNvdXJjZXMsIHRob3VnaCAoQ1BVcyArIFJBTSkuIEluIHRoaXMgY2FzZSwgSSBjYW4n dCB0ZXN0IHRoZSBWTSBvbiBkaWZmZXJlbnQgaG9zdHMgYmVjYXVzZSB3ZSd2ZSBzZXBhcmF0ZWQg b25lIG9mIHRoZW0gKG9uZSBvZiB0aGUgIjQiKSBvbiBhIHN0YW5kYWxvbmUgb1ZpcnQgZGF0YWNl bnRlciBhcyB3ZSdyZSBtYWtpbmcgdGVzdHMgb24gaXQsIGJ1dCBJIHJlbWVtYmVyIHRoaXMgaGFz IGFscmVhZHkgaGFwcGVuZWQgdG8gbWUgaW4gdGhlIHBhc3QgKEkgZGlkbid0IGhhdmUgdGhlIHRp bWUgdG8gZGVidWcgaXQgYXQgdGhhdCB0aW1lLCB0aG91Z2gpLg0KDQpBbmQgaXQgZG9lc24ndCBo YXBwZW4gd2l0aCBhIHNpbWlsYXIgVk0gaW4gdGhlIG90aGVyIGRhdGFjZW50ZXIsIG9uIHRoZSBz YW1lIGhhcmR3YXJlPw0KDQovSw0KDQo+DQo+PiA+DQo+PiA+PiA+IEVhY2ggdGltZSBJIGluc3Rh bGwgYW4gYWRkaXRpb25hbCBkZXNrdG9wIGVudmlyb25tZW50IChHbm9tZSwgS0RFLA0KPj4gPj4g PiB3aGF0ZXZlci4uLiksIENQVSB1c2FnZSByaXNlcyB0byAxMDAlIGFsbCB0aW1lIHRvIHRoZSBl eHRyZW1lIHRoYXQNCj4+ID4+ID4gaW50ZXJhY3Rpbmcgd2l0aCB0aGUgbWFjaGluZSBiZWNvbWVz IGltcG9zc2libGUgKG1heWJlIGEgbW91c2UgbW92ZW1lbnQNCj4+ID4+ID4gaXMgcHJvcGFnYXRl ZCAzIG1pbnV0ZXMgbGF0ZXIgb3Igc28uLi4pLg0KPj4gPj4gPg0KPj4gPj4gPiBUbyBkZWJ1ZyB0 aGlzLCBJIGluc3RhbGxlZCBMWERFLCB3aGljaCBpcyBhIGxpZ2h0d2VpZ2h0IGRlc2t0b3ANCj4+ ID4+ID4gZW52aXJvbm1lbnQgYmFzZWQgb24gWG9yZy4gSSBjb3VsZCBzZWUgdGhlcmUgaXMgYW4g WG9yZyBwcm9jZXNzDQo+PiA+PiA+IGNvbnN1bWluZyBvbmUgb2YgdGhlIENQVXMgYW5kIHRoZSBt YWNoaW5lIHN0b3BzIHJlc3BvbmRpbmcgYXMgZmFyIGFzIHRoZQ0KPj4gPj4gPiBkZXNrdG9wIGVu dmlyb25tZW50IGdvZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUNCj4+ID4+ ID4gY29uZmlndXJhdGlvbiBmaWxlLg0KPj4gPj4gPg0KPj4gPj4gPiBJIGNvdWxkIGFsc28gc2Vl IHRoaXMgb25seSBoYXBwZW5zIHdoZW4gUVhMIGlzIGNob3NlbiBhcyB0aGUgZGlzcGxheQ0KPj4g Pj4gPiBkcml2ZXIuIFdoZW4gQ0lSUlVTIGlzIGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9v dGhseSBhbmQgQ1BVIGlzDQo+PiA+PiA+IH4xMDAlIGlkbGUuIFRoZSBkb3duc2lkZSBpcyB0aGF0 IHdlIHdhbnQgdG8gdXNlIFNQSUNFIGFuZCBDSVJSVVMgd29uJ3QNCj4+ID4+ID4gYWxsb3cgaXQu DQo+PiA+PiA+DQo+PiA+PiA+IFdoeSBkb2VzIHRoaXMgaGFwcGVuPyBJcyB0aGlzIGFuIE9TLXNp ZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGludCBob3cgY2FuDQo+PiA+PiA+IGl0IGJlIGZpeGVkPw0K Pj4gPj4gPg0KPj4gPj4gPiBUaGFua3MuDQo+PiA+PiA+DQo+PiA+PiA+IE5pY29sw6FzDQo+PiA+ PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ PiA+IFVzZXJzIG1haWxpbmcgbGlzdA0KPj4gPj4gPiBVc2Vyc0BvdmlydC5vcmcNCj4+ID4+ID4g aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+PiA+DQo+PiA+ DQo+DQo+DQo= --_000_5534f35e19cb423287f13a0e5159163cexch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <FB71D56CC5642648899F4418B36F144C(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxOCBtYWogMjAxNiA3OjQ4IGVtIHNrcmV2IE5pY29sw6FzICZsdDtuaWNvbGFz QGRldmVscy5lcyZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBF bCAxOC8wNS8xNiBhIGxhcyAxODoxMSwgS2FybGkgU2rDtmJlcmcgZXNjcmliacOzOjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBEZW4gMTggbWFqIDIwMTYgNzowMyBl bSBza3JldiBOaWNvbMOhcyAmbHQ7bmljb2xhc0BkZXZlbHMuZXMmZ3Q7Ojxicj4NCiZndDsmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEhpIEthcmxpLDxicj4NCiZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7IEVsIDE4LzA1LzE2IGEgbGFzIDE2OjU5LCBLYXJsaSBTasO2YmVyZyBl c2NyaWJpw7M6PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IERlbiAxOCBtYWogMjAxNiA1OjQ5IGVtIHNrcmV2IE5pY29s w6FzICZsdDtuaWNvbGFzQGRldmVscy5lcyZndDs6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgSGksPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgUHJvYmFibHkgbm90IGFuIG9WaXJ0IGlz c3VlLCBidXQgbWF5YmUgc29tZW9uZSBjYW4gaGVscC4gSSd2ZSBkZXBsb3llZCBhIDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsgcHJldHR5IGJhc2ljIFZNICh1YnVudHUgMTQuMDQgc2VydmVy LCA0R0IgUkFNLCA0IENQVXMsIDE1R0Igc3RvcmFnZSkuPGJyPg0KJmd0OyZndDsgJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBKdXN0IHNwaXRiYWxsaW5nIGhlcmU6IDE0LjA0IG9ubHk/ IFRyaWVkIDE2LjA0LCBvciBhbnkgb3RoZXIgT1MgZm9yIHRoYXQgbWF0dGVyPyBGb3Igbm93LCBp dCBzb3VuZHMgbW9yZSBndWVzdCByZWxhdGVkIHJhdGhlciB0aGFuIG9WaXJ0Ljxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgL0s8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgSSB0cmllZCBhIHZhbmlsbGEg Y2VudG9zLTcuMSBhcyB3ZWxsIGFuZCB0aGUgc2FtZSBoYXBwZW5zLiBJJ20gb2YgdGhlIHNhbWUg b3BpbmlvbiB0aGF0IHRoaXMgaXMgbW9yZSBhIGd1ZXN0IHJlbGF0ZWQgaXNzdWUsIGl0J3MganVz dCBJJ2QgbGlrZSB0byBmaW5kIG91dCB3aHkgdGhpcyBvbmx5IGhhcHBlbnMgd2l0aCBRWEwgYW5k IG5vdCB3aXRoIENJUlJVUy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBU aGFua3MuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBWZXJ5IGludGVyZXN0aW5nLiBBcmUg eW91ciBob3N0cyBhbGwgb2YgdGhlIHNhbWUgYXJjaGl0ZWN0dXJlKGZhbWlseSk/PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAvSzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBY3R1 YWxseSB3ZSBoYXZlIGEgbmljZSBtaXh0dXJlIG9mIG1hbnVmYWN0dXJlcnMuIFdlIHJ1biA3IGhv c3RzLCBwYWlyZWQgNC0yLTEgaW4gcmVsYXRpb24gdG8gYXJjaGl0ZWN0dXJlLiBBbGwgb2YgdGhl bSBoYXZlIHRoZSBzYW1lIHJlc291cmNlcywgdGhvdWdoIChDUFVzICYjNDM7IFJBTSkuIEluIHRo aXMgY2FzZSwgSSBjYW4ndCB0ZXN0IHRoZSBWTSBvbiBkaWZmZXJlbnQgaG9zdHMgYmVjYXVzZSB3 ZSd2ZSBzZXBhcmF0ZWQgb25lIG9mIHRoZW0NCiAob25lIG9mIHRoZSAmcXVvdDs0JnF1b3Q7KSBv biBhIHN0YW5kYWxvbmUgb1ZpcnQgZGF0YWNlbnRlciBhcyB3ZSdyZSBtYWtpbmcgdGVzdHMgb24g aXQsIGJ1dCBJIHJlbWVtYmVyIHRoaXMgaGFzIGFscmVhZHkgaGFwcGVuZWQgdG8gbWUgaW4gdGhl IHBhc3QgKEkgZGlkbid0IGhhdmUgdGhlIHRpbWUgdG8gZGVidWcgaXQgYXQgdGhhdCB0aW1lLCB0 aG91Z2gpLjwvcD4NCjxwIGRpcj0ibHRyIj5BbmQgaXQgZG9lc24ndCBoYXBwZW4gd2l0aCBhIHNp bWlsYXIgVk0gaW4gdGhlIG90aGVyIGRhdGFjZW50ZXIsIG9uIHRoZSBzYW1lIGhhcmR3YXJlPzwv cD4NCjxwIGRpcj0ibHRyIj4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgRWFjaCB0aW1lIEkgaW5zdGFsbCBhbiBh ZGRpdGlvbmFsIGRlc2t0b3AgZW52aXJvbm1lbnQgKEdub21lLCBLREUsIDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsgd2hhdGV2ZXIuLi4pLCBDUFUgdXNhZ2UgcmlzZXMgdG8gMTAwJSBhbGwg dGltZSB0byB0aGUgZXh0cmVtZSB0aGF0IDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgaW50 ZXJhY3Rpbmcgd2l0aCB0aGUgbWFjaGluZSBiZWNvbWVzIGltcG9zc2libGUgKG1heWJlIGEgbW91 c2UgbW92ZW1lbnQgPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyBpcyBwcm9wYWdhdGVkIDMg bWludXRlcyBsYXRlciBvciBzby4uLikuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgVG8gZGVidWcgdGhpcywgSSBpbnN0YWxsZWQgTFhERSwg d2hpY2ggaXMgYSBsaWdodHdlaWdodCBkZXNrdG9wIDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsgZW52aXJvbm1lbnQgYmFzZWQgb24gWG9yZy4gSSBjb3VsZCBzZWUgdGhlcmUgaXMgYW4gWG9y ZyBwcm9jZXNzIDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgY29uc3VtaW5nIG9uZSBvZiB0 aGUgQ1BVcyBhbmQgdGhlIG1hY2hpbmUgc3RvcHMgcmVzcG9uZGluZyBhcyBmYXIgYXMgdGhlIDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgZGVza3RvcCBlbnZpcm9ubWVudCBnb2VzLiBJIGhh dmUgbm90IGNoYW5nZWQgYW55dGhpbmcgaW4gdGhlIDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsgY29uZmlndXJhdGlvbiBmaWxlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEkgY291bGQgYWxzbyBzZWUgdGhpcyBvbmx5IGhhcHBlbnMg d2hlbiBRWEwgaXMgY2hvc2VuIGFzIHRoZSBkaXNwbGF5IDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsgZHJpdmVyLiBXaGVuIENJUlJVUyBpcyBjaG9zZW4sIGV2ZXJ5dGhpbmcgd29ya3Mgc21v b3RobHkgYW5kIENQVSBpcyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IH4xMDAlIGlkbGUu IFRoZSBkb3duc2lkZSBpcyB0aGF0IHdlIHdhbnQgdG8gdXNlIFNQSUNFIGFuZCBDSVJSVVMgd29u J3QgPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyBhbGxvdyBpdC48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyBXaHkgZG9lcyB0aGlzIGhh cHBlbj8gSXMgdGhpcyBhbiBPUy1zaWRlIGRyaXZlciBpc3N1ZT8gQW55IGhpbnQgaG93IGNhbiA8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IGl0IGJlIGZpeGVkPzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFRoYW5rcy48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyBOaWNvbMOhczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFVzZXJzIG1haWxp bmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgVXNlcnNAb3ZpcnQub3JnPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlz dGluZm8vdXNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5534f35e19cb423287f13a0e5159163cexch24sluse_--

2 1

Linux guests vs. Spice/QXL?
by Uwe Laverenz 18 May '16

18 May '16

Hi all, I'm running some tests on OVirt (3.6.5.3) on CentOS 7 and almost everything works quite well so far. CentOS 6.x, Windows 7 and 2008R2 work fine with Spice/QXL, so my setup seems to be ok. Other Linux systems don't work: Debian 8, Fedora 23/24, CentOS 7.x, Kubuntu 16.04... CentOS 7.x even kills his X server every time the user logs out. X-) They all have in common that they show a fixed display resolution of 1024x768 pixels. This can not be changed manually and of course automatic display resizing doesn't work either. All machines have spice-vdagent and ovirt-guest-agent installed and running. Is this a local problem or is this known/expected behaviour? Is there anything I can do to improve this? thank you, Uwe

2 2

Re: [ovirt-users] 100% memory usage on desktop environments
by Karli Sjöberg 18 May '16

18 May '16

--_000_d37306c3c698445a8f4a6718ef2cc97eexch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTggbWFqIDIwMTYgNzowMyBlbSBza3JldiBOaWNvbMOhcyA8bmljb2xhc0BkZXZlbHMu ZXM+Og0KPg0KPiBIaSBLYXJsaSwNCj4NCj4gRWwgMTgvMDUvMTYgYSBsYXMgMTY6NTksIEthcmxp IFNqw7ZiZXJnIGVzY3JpYmnDszoNCj4+DQo+Pg0KPj4gRGVuIDE4IG1haiAyMDE2IDU6NDkgZW0g c2tyZXYgTmljb2zDoXMgPG5pY29sYXNAZGV2ZWxzLmVzPjoNCj4+ID4NCj4+ID4gSGksDQo+PiA+ DQo+PiA+IFByb2JhYmx5IG5vdCBhbiBvVmlydCBpc3N1ZSwgYnV0IG1heWJlIHNvbWVvbmUgY2Fu IGhlbHAuIEkndmUgZGVwbG95ZWQgYQ0KPj4gPiBwcmV0dHkgYmFzaWMgVk0gKHVidW50dSAxNC4w NCBzZXJ2ZXIsIDRHQiBSQU0sIDQgQ1BVcywgMTVHQiBzdG9yYWdlKS4NCj4+DQo+PiBKdXN0IHNw aXRiYWxsaW5nIGhlcmU6IDE0LjA0IG9ubHk/IFRyaWVkIDE2LjA0LCBvciBhbnkgb3RoZXIgT1Mg Zm9yIHRoYXQgbWF0dGVyPyBGb3Igbm93LCBpdCBzb3VuZHMgbW9yZSBndWVzdCByZWxhdGVkIHJh dGhlciB0aGFuIG9WaXJ0Lg0KPj4NCj4+IC9LDQo+DQo+DQo+IEkgdHJpZWQgYSB2YW5pbGxhIGNl bnRvcy03LjEgYXMgd2VsbCBhbmQgdGhlIHNhbWUgaGFwcGVucy4gSSdtIG9mIHRoZSBzYW1lIG9w aW5pb24gdGhhdCB0aGlzIGlzIG1vcmUgYSBndWVzdCByZWxhdGVkIGlzc3VlLCBpdCdzIGp1c3Qg SSdkIGxpa2UgdG8gZmluZCBvdXQgd2h5IHRoaXMgb25seSBoYXBwZW5zIHdpdGggUVhMIGFuZCBu b3Qgd2l0aCBDSVJSVVMuDQo+DQo+IFRoYW5rcy4NCg0KVmVyeSBpbnRlcmVzdGluZy4gQXJlIHlv dXIgaG9zdHMgYWxsIG9mIHRoZSBzYW1lIGFyY2hpdGVjdHVyZShmYW1pbHkpPw0KDQovSw0KDQo+ DQo+PiA+IEVhY2ggdGltZSBJIGluc3RhbGwgYW4gYWRkaXRpb25hbCBkZXNrdG9wIGVudmlyb25t ZW50IChHbm9tZSwgS0RFLA0KPj4gPiB3aGF0ZXZlci4uLiksIENQVSB1c2FnZSByaXNlcyB0byAx MDAlIGFsbCB0aW1lIHRvIHRoZSBleHRyZW1lIHRoYXQNCj4+ID4gaW50ZXJhY3Rpbmcgd2l0aCB0 aGUgbWFjaGluZSBiZWNvbWVzIGltcG9zc2libGUgKG1heWJlIGEgbW91c2UgbW92ZW1lbnQNCj4+ ID4gaXMgcHJvcGFnYXRlZCAzIG1pbnV0ZXMgbGF0ZXIgb3Igc28uLi4pLg0KPj4gPg0KPj4gPiBU byBkZWJ1ZyB0aGlzLCBJIGluc3RhbGxlZCBMWERFLCB3aGljaCBpcyBhIGxpZ2h0d2VpZ2h0IGRl c2t0b3ANCj4+ID4gZW52aXJvbm1lbnQgYmFzZWQgb24gWG9yZy4gSSBjb3VsZCBzZWUgdGhlcmUg aXMgYW4gWG9yZyBwcm9jZXNzDQo+PiA+IGNvbnN1bWluZyBvbmUgb2YgdGhlIENQVXMgYW5kIHRo ZSBtYWNoaW5lIHN0b3BzIHJlc3BvbmRpbmcgYXMgZmFyIGFzIHRoZQ0KPj4gPiBkZXNrdG9wIGVu dmlyb25tZW50IGdvZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUNCj4+ID4g Y29uZmlndXJhdGlvbiBmaWxlLg0KPj4gPg0KPj4gPiBJIGNvdWxkIGFsc28gc2VlIHRoaXMgb25s eSBoYXBwZW5zIHdoZW4gUVhMIGlzIGNob3NlbiBhcyB0aGUgZGlzcGxheQ0KPj4gPiBkcml2ZXIu IFdoZW4gQ0lSUlVTIGlzIGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9vdGhseSBhbmQgQ1BV IGlzDQo+PiA+IH4xMDAlIGlkbGUuIFRoZSBkb3duc2lkZSBpcyB0aGF0IHdlIHdhbnQgdG8gdXNl IFNQSUNFIGFuZCBDSVJSVVMgd29uJ3QNCj4+ID4gYWxsb3cgaXQuDQo+PiA+DQo+PiA+IFdoeSBk b2VzIHRoaXMgaGFwcGVuPyBJcyB0aGlzIGFuIE9TLXNpZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGlu dCBob3cgY2FuDQo+PiA+IGl0IGJlIGZpeGVkPw0KPj4gPg0KPj4gPiBUaGFua3MuDQo+PiA+DQo+ PiA+IE5pY29sw6FzDQo+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiA+IFVzZXJzIG1haWxpbmcgbGlzdA0KPj4gPiBVc2Vyc0BvdmlydC5vcmcN Cj4+ID4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+DQo+ DQo= --_000_d37306c3c698445a8f4a6718ef2cc97eexch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <00292E3F88DC80458009E189EFB6ABC9(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxOCBtYWogMjAxNiA3OjAzIGVtIHNrcmV2IE5pY29sw6FzICZsdDtuaWNvbGFz QGRldmVscy5lcyZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgS2FybGksPGJyPg0KJmd0Ozxi cj4NCiZndDsgRWwgMTgvMDUvMTYgYSBsYXMgMTY6NTksIEthcmxpIFNqw7ZiZXJnIGVzY3JpYmnD szo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRGVuIDE4IG1haiAy MDE2IDU6NDkgZW0gc2tyZXYgTmljb2zDoXMgJmx0O25pY29sYXNAZGV2ZWxzLmVzJmd0Ozo8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyBQcm9iYWJseSBub3QgYW4gb1ZpcnQgaXNzdWUsIGJ1dCBtYXli ZSBzb21lb25lIGNhbiBoZWxwLiBJJ3ZlIGRlcGxveWVkIGEgPGJyPg0KJmd0OyZndDsgJmd0OyBw cmV0dHkgYmFzaWMgVk0gKHVidW50dSAxNC4wNCBzZXJ2ZXIsIDRHQiBSQU0sIDQgQ1BVcywgMTVH QiBzdG9yYWdlKS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEp1c3Qgc3BpdGJhbGxpbmcg aGVyZTogMTQuMDQgb25seT8gVHJpZWQgMTYuMDQsIG9yIGFueSBvdGhlciBPUyBmb3IgdGhhdCBt YXR0ZXI/IEZvciBub3csIGl0IHNvdW5kcyBtb3JlIGd1ZXN0IHJlbGF0ZWQgcmF0aGVyIHRoYW4g b1ZpcnQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAvSzxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBJIHRyaWVkIGEgdmFuaWxsYSBjZW50b3MtNy4xIGFzIHdlbGwgYW5kIHRoZSBz YW1lIGhhcHBlbnMuIEknbSBvZiB0aGUgc2FtZSBvcGluaW9uIHRoYXQgdGhpcyBpcyBtb3JlIGEg Z3Vlc3QgcmVsYXRlZCBpc3N1ZSwgaXQncyBqdXN0IEknZCBsaWtlIHRvIGZpbmQgb3V0IHdoeSB0 aGlzIG9ubHkgaGFwcGVucyB3aXRoIFFYTCBhbmQgbm90IHdpdGggQ0lSUlVTLjxicj4NCiZndDs8 YnI+DQomZ3Q7IFRoYW5rcy48L3A+DQo8cCBkaXI9Imx0ciI+VmVyeSBpbnRlcmVzdGluZy4gQXJl IHlvdXIgaG9zdHMgYWxsIG9mIHRoZSBzYW1lIGFyY2hpdGVjdHVyZShmYW1pbHkpPzwvcD4NCjxw IGRpcj0ibHRyIj4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBF YWNoIHRpbWUgSSBpbnN0YWxsIGFuIGFkZGl0aW9uYWwgZGVza3RvcCBlbnZpcm9ubWVudCAoR25v bWUsIEtERSwgPGJyPg0KJmd0OyZndDsgJmd0OyB3aGF0ZXZlci4uLiksIENQVSB1c2FnZSByaXNl cyB0byAxMDAlIGFsbCB0aW1lIHRvIHRoZSBleHRyZW1lIHRoYXQgPGJyPg0KJmd0OyZndDsgJmd0 OyBpbnRlcmFjdGluZyB3aXRoIHRoZSBtYWNoaW5lIGJlY29tZXMgaW1wb3NzaWJsZSAobWF5YmUg YSBtb3VzZSBtb3ZlbWVudCA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGlzIHByb3BhZ2F0ZWQgMyBtaW51 dGVzIGxhdGVyIG9yIHNvLi4uKS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyBUbyBkZWJ1ZyB0aGlzLCBJIGluc3RhbGxlZCBMWERFLCB3aGljaCBpcyBhIGxpZ2h0d2VpZ2h0 IGRlc2t0b3AgPGJyPg0KJmd0OyZndDsgJmd0OyBlbnZpcm9ubWVudCBiYXNlZCBvbiBYb3JnLiBJ IGNvdWxkIHNlZSB0aGVyZSBpcyBhbiBYb3JnIHByb2Nlc3MgPGJyPg0KJmd0OyZndDsgJmd0OyBj b25zdW1pbmcgb25lIG9mIHRoZSBDUFVzIGFuZCB0aGUgbWFjaGluZSBzdG9wcyByZXNwb25kaW5n IGFzIGZhciBhcyB0aGUgPGJyPg0KJmd0OyZndDsgJmd0OyBkZXNrdG9wIGVudmlyb25tZW50IGdv ZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUgPGJyPg0KJmd0OyZndDsgJmd0 OyBjb25maWd1cmF0aW9uIGZpbGUuPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsgSSBjb3VsZCBhbHNvIHNlZSB0aGlzIG9ubHkgaGFwcGVucyB3aGVuIFFYTCBpcyBjaG9zZW4g YXMgdGhlIGRpc3BsYXkgPGJyPg0KJmd0OyZndDsgJmd0OyBkcml2ZXIuIFdoZW4gQ0lSUlVTIGlz IGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9vdGhseSBhbmQgQ1BVIGlzIDxicj4NCiZndDsm Z3Q7ICZndDsgfjEwMCUgaWRsZS4gVGhlIGRvd25zaWRlIGlzIHRoYXQgd2Ugd2FudCB0byB1c2Ug U1BJQ0UgYW5kIENJUlJVUyB3b24ndCA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGFsbG93IGl0Ljxicj4N CiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFdoeSBkb2VzIHRoaXMgaGFwcGVuPyBJ cyB0aGlzIGFuIE9TLXNpZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGludCBob3cgY2FuIDxicj4NCiZn dDsmZ3Q7ICZndDsgaXQgYmUgZml4ZWQ/PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsgVGhhbmtzLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IE5pY29s w6FzPGJyPg0KJmd0OyZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsgVXNlcnMgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyZndDsgJmd0OyBVc2Vyc0BvdmlydC5vcmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGh0dHA6Ly9s aXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vyczxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d37306c3c698445a8f4a6718ef2cc97eexch24sluse_--

2 1

Re: [ovirt-users] 100% memory usage on desktop environments
by Karli Sjöberg 18 May '16

18 May '16

--_000_848ff670f8084d3e8c04b813ead04977exch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTggbWFqIDIwMTYgNTo0OSBlbSBza3JldiBOaWNvbMOhcyA8bmljb2xhc0BkZXZlbHMu ZXM+Og0KPg0KPiBIaSwNCj4NCj4gUHJvYmFibHkgbm90IGFuIG9WaXJ0IGlzc3VlLCBidXQgbWF5 YmUgc29tZW9uZSBjYW4gaGVscC4gSSd2ZSBkZXBsb3llZCBhDQo+IHByZXR0eSBiYXNpYyBWTSAo dWJ1bnR1IDE0LjA0IHNlcnZlciwgNEdCIFJBTSwgNCBDUFVzLCAxNUdCIHN0b3JhZ2UpLg0KDQpK dXN0IHNwaXRiYWxsaW5nIGhlcmU6IDE0LjA0IG9ubHk/IFRyaWVkIDE2LjA0LCBvciBhbnkgb3Ro ZXIgT1MgZm9yIHRoYXQgbWF0dGVyPyBGb3Igbm93LCBpdCBzb3VuZHMgbW9yZSBndWVzdCByZWxh dGVkIHJhdGhlciB0aGFuIG9WaXJ0Lg0KDQovSw0KDQo+IEVhY2ggdGltZSBJIGluc3RhbGwgYW4g YWRkaXRpb25hbCBkZXNrdG9wIGVudmlyb25tZW50IChHbm9tZSwgS0RFLA0KPiB3aGF0ZXZlci4u LiksIENQVSB1c2FnZSByaXNlcyB0byAxMDAlIGFsbCB0aW1lIHRvIHRoZSBleHRyZW1lIHRoYXQN Cj4gaW50ZXJhY3Rpbmcgd2l0aCB0aGUgbWFjaGluZSBiZWNvbWVzIGltcG9zc2libGUgKG1heWJl IGEgbW91c2UgbW92ZW1lbnQNCj4gaXMgcHJvcGFnYXRlZCAzIG1pbnV0ZXMgbGF0ZXIgb3Igc28u Li4pLg0KPg0KPiBUbyBkZWJ1ZyB0aGlzLCBJIGluc3RhbGxlZCBMWERFLCB3aGljaCBpcyBhIGxp Z2h0d2VpZ2h0IGRlc2t0b3ANCj4gZW52aXJvbm1lbnQgYmFzZWQgb24gWG9yZy4gSSBjb3VsZCBz ZWUgdGhlcmUgaXMgYW4gWG9yZyBwcm9jZXNzDQo+IGNvbnN1bWluZyBvbmUgb2YgdGhlIENQVXMg YW5kIHRoZSBtYWNoaW5lIHN0b3BzIHJlc3BvbmRpbmcgYXMgZmFyIGFzIHRoZQ0KPiBkZXNrdG9w IGVudmlyb25tZW50IGdvZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUNCj4g Y29uZmlndXJhdGlvbiBmaWxlLg0KPg0KPiBJIGNvdWxkIGFsc28gc2VlIHRoaXMgb25seSBoYXBw ZW5zIHdoZW4gUVhMIGlzIGNob3NlbiBhcyB0aGUgZGlzcGxheQ0KPiBkcml2ZXIuIFdoZW4gQ0lS UlVTIGlzIGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9vdGhseSBhbmQgQ1BVIGlzDQo+IH4x MDAlIGlkbGUuIFRoZSBkb3duc2lkZSBpcyB0aGF0IHdlIHdhbnQgdG8gdXNlIFNQSUNFIGFuZCBD SVJSVVMgd29uJ3QNCj4gYWxsb3cgaXQuDQo+DQo+IFdoeSBkb2VzIHRoaXMgaGFwcGVuPyBJcyB0 aGlzIGFuIE9TLXNpZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGludCBob3cgY2FuDQo+IGl0IGJlIGZp eGVkPw0KPg0KPiBUaGFua3MuDQo+DQo+IE5pY29sw6FzDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFVzZXJzIG1haWxpbmcgbGlzdA0KPiBVc2Vy c0BvdmlydC5vcmcNCj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vz ZXJzDQo= --_000_848ff670f8084d3e8c04b813ead04977exch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <80D2291C8B282C4A8D7D4C59ED986272(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxOCBtYWogMjAxNiA1OjQ5IGVtIHNrcmV2IE5pY29sw6FzICZsdDtuaWNvbGFz QGRldmVscy5lcyZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGksPGJyPg0KJmd0Ozxicj4NCiZn dDsgUHJvYmFibHkgbm90IGFuIG9WaXJ0IGlzc3VlLCBidXQgbWF5YmUgc29tZW9uZSBjYW4gaGVs cC4gSSd2ZSBkZXBsb3llZCBhIDxicj4NCiZndDsgcHJldHR5IGJhc2ljIFZNICh1YnVudHUgMTQu MDQgc2VydmVyLCA0R0IgUkFNLCA0IENQVXMsIDE1R0Igc3RvcmFnZSkuIDwvcD4NCjxwIGRpcj0i bHRyIj5KdXN0IHNwaXRiYWxsaW5nIGhlcmU6IDE0LjA0IG9ubHk/IFRyaWVkIDE2LjA0LCBvciBh bnkgb3RoZXIgT1MgZm9yIHRoYXQgbWF0dGVyPyBGb3Igbm93LCBpdCBzb3VuZHMgbW9yZSBndWVz dCByZWxhdGVkIHJhdGhlciB0aGFuIG9WaXJ0LjwvcD4NCjxwIGRpcj0ibHRyIj4vSzwvcD4NCjxw IGRpcj0ibHRyIj4mZ3Q7IEVhY2ggdGltZSBJIGluc3RhbGwgYW4gYWRkaXRpb25hbCBkZXNrdG9w IGVudmlyb25tZW50IChHbm9tZSwgS0RFLA0KPGJyPg0KJmd0OyB3aGF0ZXZlci4uLiksIENQVSB1 c2FnZSByaXNlcyB0byAxMDAlIGFsbCB0aW1lIHRvIHRoZSBleHRyZW1lIHRoYXQgPGJyPg0KJmd0 OyBpbnRlcmFjdGluZyB3aXRoIHRoZSBtYWNoaW5lIGJlY29tZXMgaW1wb3NzaWJsZSAobWF5YmUg YSBtb3VzZSBtb3ZlbWVudCA8YnI+DQomZ3Q7IGlzIHByb3BhZ2F0ZWQgMyBtaW51dGVzIGxhdGVy IG9yIHNvLi4uKS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUbyBkZWJ1ZyB0aGlzLCBJIGluc3RhbGxl ZCBMWERFLCB3aGljaCBpcyBhIGxpZ2h0d2VpZ2h0IGRlc2t0b3AgPGJyPg0KJmd0OyBlbnZpcm9u bWVudCBiYXNlZCBvbiBYb3JnLiBJIGNvdWxkIHNlZSB0aGVyZSBpcyBhbiBYb3JnIHByb2Nlc3Mg PGJyPg0KJmd0OyBjb25zdW1pbmcgb25lIG9mIHRoZSBDUFVzIGFuZCB0aGUgbWFjaGluZSBzdG9w cyByZXNwb25kaW5nIGFzIGZhciBhcyB0aGUgPGJyPg0KJmd0OyBkZXNrdG9wIGVudmlyb25tZW50 IGdvZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUgPGJyPg0KJmd0OyBjb25m aWd1cmF0aW9uIGZpbGUuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBjb3VsZCBhbHNvIHNlZSB0aGlz IG9ubHkgaGFwcGVucyB3aGVuIFFYTCBpcyBjaG9zZW4gYXMgdGhlIGRpc3BsYXkgPGJyPg0KJmd0 OyBkcml2ZXIuIFdoZW4gQ0lSUlVTIGlzIGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9vdGhs eSBhbmQgQ1BVIGlzIDxicj4NCiZndDsgfjEwMCUgaWRsZS4gVGhlIGRvd25zaWRlIGlzIHRoYXQg d2Ugd2FudCB0byB1c2UgU1BJQ0UgYW5kIENJUlJVUyB3b24ndCA8YnI+DQomZ3Q7IGFsbG93IGl0 Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFdoeSBkb2VzIHRoaXMgaGFwcGVuPyBJcyB0aGlzIGFuIE9T LXNpZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGludCBob3cgY2FuIDxicj4NCiZndDsgaXQgYmUgZml4 ZWQ/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzLjxicj4NCiZndDs8YnI+DQomZ3Q7IE5pY29s w6FzPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgVXNlcnMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBVc2Vyc0BvdmlydC5v cmc8YnI+DQomZ3Q7IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vy czxicj4NCjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_848ff670f8084d3e8c04b813ead04977exch24sluse_--

2 1

Snapshot is "Locked" - Can't do anything with the VM
by Ivo Rütsche 18 May '16

18 May '16

Hi oVirt List We have the problem, that two of our VM's have "Locked" snapshots and we can't go forward. From 10 VM's which we move from one store to another, we have problems with 5 of them to delete the snapshots. But with a lot of luck, the snapshot was always on the dedicated Swap-Disk, so we just have to remove the whole disk and create it again as new. Because we replace all the filers, we have to move the VM's arround. The move itself runns fine, but deleting the snapshots doesn't work sometimes. I found a lot about our problem, but I can't find any solution, which works an our environment. Our setup: - 3 Solaris filer with NFS exports for the hosts for the vm-images - 8 hosts (oVirt 3.6 / Centos 7.2.1511) - The engine host is located outside of the DC, connected via VPN At the moment, one of the "problem-VM" is productive, the other should become productive in the next days, so we focus us to the 2nd VM, because we can play arround with them. The other one is startet up, but i have no idea, what happens, when i shut them down... This is the status today of VM, which is not productive at the moment: - VM Status: Down - Snapshots OK: 2 - Snapshots Locked: 1 - In the snapshot tab, everything is grayed out (Create, Preview, Commit, Undo etc.) - No active tasks are displayed Error message when i try to start the VM: "Cannot run VM. The VM is performing an operation on a Snapshot. Please wait for the operation to finish, and try again." Something about the history of this VM: 1. We start the disk move from filer1 to filer3, totaly 4 drives, everything was fine 2. Deleting snapshots, i think one or two runns fine 3. Deleting the 2nd or 3rd snapshot runs two days without an end 4. Rebooting the Engine 5. No task anymore in the Tasks list 6. The status of the snapshot is "Locked", die Disk of this snapshot becoms "Illegal" and red 7. Shutdown the VM - no luck, i can't start it again --> "Cannot run VM. The VM is performing an operation on a Snapshot. Please wait for the operation to finish, and try again." 8. We move the disk back from filer3 to the filer1 9. The status of the snapshot is "Locked", die Disk of this snapshot becoms "OK" and green ...but i can't delete the snapshot or starting the VM :( Today, i copy the image files to a dedicated KVM host, which is not involved in the oVirt environment and i merge the image manualy together: qemu-img convert -p -f qcow2 804ffcc3-446f-4c56-ba99-ab90c7951a6f -O raw Merged1 I mount the image and everything fine, all the changes from the last two days are now in a base image. I try to remove the whole disk in oVirt, but i still got the error message, that i have to wait. So for me, the next step is to create a new VM and migrate everything manualy, this will work, but can't be the solution for the other VM, which is productive and it have the same problem. Some information about: ***************** [root@lin-ovirt7 images]# vdsm-tool dump-volume-chains d6e6656d-7aaf-4c5b-bb93-cd6134ed9654 Images volume chains (base volume first) image: f3cfefd2-d467-41d5-a054-5b01f81a21b4 - a018521a-bd3a-4322-ac79-52d15e95639e status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL, type: SPARSE - 2e2f0b4a-b015-4b50-8d10-51726de460a9 status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE - 804ffcc3-446f-4c56-ba99-ab90c7951a6f status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE ***************** [root@lin-ovirt7 images]# ls -altrh f3cfefd2-d467-41d5-a054-5b01f81a21b4/ total 34G -rw-rw----+ 1 vdsm kvm 1.0M 2. Mai 21:03 a018521a-bd3a-4322-ac79-52d15e95639e.lease -rw-rw----+ 1 vdsm kvm 1.0M 2. Mai 21:03 2e2f0b4a-b015-4b50-8d10-51726de460a9.lease -rw-r--r--+ 1 vdsm kvm 260 2. Mai 21:03 804ffcc3-446f-4c56-ba99-ab90c7951a6f.meta -rw-rw----+ 1 vdsm kvm 1.0M 2. Mai 21:03 804ffcc3-446f-4c56-ba99-ab90c7951a6f.lease -rw-rw----+ 1 vdsm kvm 300G 2. Mai 22:26 a018521a-bd3a-4322-ac79-52d15e95639e -rw-rw----+ 1 vdsm kvm 77M 2. Mai 22:27 2e2f0b4a-b015-4b50-8d10-51726de460a9 -rw-rw----+ 1 vdsm kvm 3.5G 2. Mai 22:34 804ffcc3-446f-4c56-ba99-ab90c7951a6f -rw-r--r--+ 1 vdsm kvm 364 2. Mai 22:34 a018521a-bd3a-4322-ac79-52d15e95639e.meta -rw-r--r--+ 1 vdsm kvm 264 2. Mai 22:34 2e2f0b4a-b015-4b50-8d10-51726de460a9.meta drwxr-xr-x+ 2 vdsm kvm 11 2. Mai 22:34 . drwxr-xr-x+ 50 vdsm kvm 50 3. Mai 14:30 .. [root@lin-ovirt7 images]# ***************** I attach some line from the engine.log, maybe someone can help, if you need more information everything is here. gruss ivo

3 6

Re: [ovirt-users] oVirt hosted-engine setup stuck in final phase registering host to engine
by Ralf Schenk 18 May '16

18 May '16

Hello, of course. See attached File. Bye Am 18.05.2016 um 11:13 schrieb Simone Tiraboschi: > It looks, correct. > > Can you please share the whole log file? > > On Wed, May 18, 2016 at 11:03 AM, Ralf Schenk <rs(a)databay.de > <mailto:rs@databay.de>> wrote: > > Hello, > > from the last setup Log: > > 2016-05-11 18:19:31 DEBUG otopi.context > context.dumpEnvironment:510 ENV > OVEHOSTED_ENGINE/appHostName=str:'hosted_engine_1' > > > Am 18.05.2016 um 10:59 schrieb Simone Tiraboschi: >> >> >> On Wed, May 18, 2016 at 10:33 AM, Ralf Schenk <rs(a)databay.de >> <mailto:rs@databay.de>> wrote: >> >> Dear list, >> >> i'm working for days on a hosted-engine setup on glusterfs >> and 'm stuck in the last phase of hosted-engine --deploy see >> Text output (for two days now :-( ). I've only ovirtmgmt >> Bridge up and running and all DNS-Names seen in the >> screenshot are resolvable. It shouldn't be related to your >> problem regarding multiple nic's in the engine-vm. As seen >> the hosted-engine setup is already succsessfull, engine-vm >> running, but the setup fails in registering the host >> (microcloud21...) in the engine. >> >> >> [...] >> >> |- [ INFO ] Starting engine service >> |- [ INFO ] Restarting httpd >> |- [ INFO ] Restarting ovirt-vmconsole proxy service >> |- [ INFO ] Stage: Clean up >> |- Log file is located at >> /var/log/ovirt-engine/setup/ovirt-engine-setup-20160517222119-ndcyxn.log >> |- [ INFO ] Generating answer file >> '/var/lib/ovirt-engine/setup/answers/20160517223055-setup.conf' >> |- [ INFO ] Stage: Pre-termination >> |- [ INFO ] Stage: Termination >> |- [ INFO ] Execution of setup completed successfully >> |- HE_APPLIANCE_ENGINE_SETUP_SUCCESS >> [ INFO ] Engine-setup successfully completed >> [ INFO ] Engine is still unreachable >> [ INFO ] Engine is still not reachable, waiting... >> [ INFO ] Engine replied: DB Up!Welcome to Health Status! >> [ INFO ] Acquiring internal CA cert from the engine >> [ INFO ] The following CA certificate is going to be used, >> please immediately interrupt if not correct: >> [ INFO ] Issuer: C=US, O=rxmgmt.databay.de >> <http://rxmgmt.databay.de>, >> CN=engine-mcIII.rxmgmt.databay.de.77792, Subject: C=US, >> O=rxmgmt.databay.de <http://rxmgmt.databay.de>, >> CN=engine-mcIII.rxmgmt.databay.de.77792, Fingerprint (SHA-1): >> D71A5EA7C5C2C2450F1473523C3A1E022945430 >> [ INFO ] Connecting to the Engine >> [ ERROR ] Cannot automatically add the host to cluster >> Default: Host name must be formed of alphanumeric characters, >> numbers or "-_." >> >> >> Please check Engine VM configuration. >> >> Make a selection from the options below: >> (1) Continue setup - Engine VM configuration has >> been fixed >> (2) Abort setup >> >> (1, 2)[1]: 1 >> >> Checking for oVirt-Engine status at >> engine-mcIII.rxmgmt.databay.de... >> [ INFO ] Engine replied: DB Up!Welcome to Health Status! >> [ ERROR ] Cannot automatically add the host to cluster >> Default: Host name must be formed of alphanumeric characters, >> numbers or "-_." >> >> >> Please check Engine VM configuration. >> >> Make a selection from the options below: >> (1) Continue setup - Engine VM configuration has >> been fixed >> (2) Abort setup >> >> (1, 2)[1]: >> >> Additionally I can see the error in the eninge-vm in >> /var/log/ovirt-engine/engine.log: >> >> 2016-05-17 14:08:15,296 WARN >> [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] (default >> task-13) [9277b0a] CanDoAction of action 'AddVds' failed for >> user admin@internal. Reasons: >> VAR__ACTION__ADD,VAR__TYPE__HOST,$server >> microcloud21.rxmgmt.databay.de >> <http://microcloud21.rxmgmt.databay.de>,VALIDATION_VDS_NAME_INVALID >> 2016-05-17 14:08:15,360 ERROR >> [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] >> (default task-13) [] Operation Failed: [Host name must be >> formed of alphanumeric characters, numbers or "-_."] >> >> >> 'microcloud21.rxmgmt.databay.de >> <http://microcloud21.rxmgmt.databay.de>' is the host address, in >> oVirt the host has also a name. >> Can you please look for OVEHOSTED_ENGINE/appHostName in your >> hosted-engine-setup logs? >> >> >> >> The hostname that should be registered is the correct fqdn >> for the virtualization host that runs the engine-vm, points >> to the ip of the ovirtmgmt-Bridge and also the IP is >> reverse-resolvable to the hostname. >> I checked /etc/hostname of the host for non-printable >> characters and as you can see that is a valid hostname. >> >> All is running on Centos 7 Versions: >> ovirt-engine-appliance.noarch >> 3.6-20160420.1.el7.centos @ovirt-3.6 >> ovirt-engine-sdk-python.noarch >> 3.6.5.0-1.el7.centos @ovirt-3.6 >> ovirt-host-deploy.noarch >> 1.4.1-1.el7.centos @ovirt-3.6 >> ovirt-hosted-engine-ha.noarch >> 1.3.5.3-1.1.el7 @centos-ovirt36 >> ovirt-hosted-engine-setup.noarch >> 1.3.5.0-1.1.el7 @centos-ovirt36 >> ovirt-setup-lib.noarch >> 1.0.1-1.el7.centos @ovirt-3.6 >> ovirt-vmconsole.noarch >> 1.0.0-1.el7.centos @ovirt-3.6 >> ovirt-vmconsole-host.noarch >> 1.0.0-1.el7.centos @ovirt-3.6 >> >> Since I already repeated the setup for many times now, I need >> your help. >> -- >> >> >> *Ralf Schenk* >> fon +49 (0) 24 05 / 40 83 70 >> <tel:%2B49%20%280%29%2024%2005%20%2F%2040%2083%2070> >> fax +49 (0) 24 05 / 40 83 759 >> <tel:%2B49%20%280%29%2024%2005%20%2F%2040%2083%20759> >> mail *rs(a)databay.de* <mailto:rs@databay.de> >> >> *Databay AG* >> Jens-Otto-Krag-Straße 11 >> D-52146 Würselen >> *www.databay.de* <http://www.databay.de> >> >> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 >> Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, >> Dipl.-Kfm. Philipp Hermanns >> Aufsichtsratsvorsitzender: Klaus Scholzen (RA) >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/users >> >> > > -- > > > *Ralf Schenk* > fon +49 (0) 24 05 / 40 83 70 > <tel:%2B49%20%280%29%2024%2005%20%2F%2040%2083%2070> > fax +49 (0) 24 05 / 40 83 759 > <tel:%2B49%20%280%29%2024%2005%20%2F%2040%2083%20759> > mail *rs(a)databay.de* <mailto:rs@databay.de> > > *Databay AG* > Jens-Otto-Krag-Straße 11 > D-52146 Würselen > *www.databay.de* <http://www.databay.de> > > Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 > Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, > Dipl.-Kfm. Philipp Hermanns > Aufsichtsratsvorsitzender: Klaus Scholzen (RA) > > ------------------------------------------------------------------------ > > -- *Ralf Schenk* fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail *rs(a)databay.de* <mailto:rs@databay.de> *Databay AG* Jens-Otto-Krag-Straße 11 D-52146 Würselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) ------------------------------------------------------------------------

2 3

AAA LDAP timeout
by Dominique Taffin 18 May '16

18 May '16

Hello! We do have a rather large LDAP which does take some time to answer. Using oVirt and AAA LDAP extension, I do run into timeouts. running "ovirt-engine-extensions-tool --log-level=FINEST --log- file=tool.log aaa login-user --profile=abc --user-name=xxx" fails with: [...] LDAPSearchException(resultCode=85 (timeout), numEntries=0, numReferences=0, errorMessage='A client-side timeout was encountered while waiting 60000ms for a response to search request with message ID 3, base DN [...] ldapsearch itself takes approx 2 minutes. Can the timeout of 60000ms be configured somewhere? I could not find anything in the documentation... thank you and best, Dominique

2 2

RemoveDiskSnapshots error's on engine log
by Ivo Rütsche 18 May '16

18 May '16

Hi List At the moment, we replace a filer and we have to move the VM's to another filer. We have a lot of problems with it. Sometime we have to restart the engine, sometime we have to move the image arround and sometimes we don't have a chance to remove the snapshots. When the VM is running, most of the time the snapshot remove never starts. Now, i found these errors every second in the engine.log since today: 2016-05-11 23:25:29,102 ERROR [org.ovirt.engine.core.bll.CommandsFactory] (DefaultQuartzScheduler_Worker-90) [] Error in invocating CTOR of command 'RemoveDiskSnapshots': null 2016-05-11 23:25:29,102 ERROR [org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl] (DefaultQuartzScheduler_Worker-90) [] Failed to invoke scheduled method invokeCallbackMethods: null 2016-05-11 23:25:30,104 ERROR [org.ovirt.engine.core.bll.CommandsFactory] (DefaultQuartzScheduler_Worker-66) [] Error in invocating CTOR of command 'RemoveDiskSnapshots': null 2016-05-11 23:25:30,104 ERROR [org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl] (DefaultQuartzScheduler_Worker-66) [] Failed to invoke scheduled method invokeCallbackMethods: null 2016-05-11 23:25:31,105 ERROR [org.ovirt.engine.core.bll.CommandsFactory] (DefaultQuartzScheduler_Worker-76) [] Error in invocating CTOR of command 'RemoveDiskSnapshots': null 2016-05-11 23:25:31,105 ERROR [org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl] (DefaultQuartzScheduler_Worker-76) [] Failed to invoke scheduled method invokeCallbackMethods: null I try everything, but i can't find the problem. Anyone who have an idea, where i have to search? Thank's for help. Ivo

2 2

oVirt hosted-engine setup stuck in final phase registering host to engine
by Ralf Schenk 18 May '16

18 May '16

This is a multi-part message in MIME format. --------------B5233FE7196FCCD40BA3A0F3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Dear list, i'm working for days on a hosted-engine setup on glusterfs and 'm stuck in the last phase of hosted-engine --deploy see Text output (for two days now :-( ). I've only ovirtmgmt Bridge up and running and all DNS-Names seen in the screenshot are resolvable. It shouldn't be related to your problem regarding multiple nic's in the engine-vm. As seen the hosted-engine setup is already succsessfull, engine-vm running, but the setup fails in registering the host (microcloud21...) in the engine. [...] |- [ INFO ] Starting engine service |- [ INFO ] Restarting httpd |- [ INFO ] Restarting ovirt-vmconsole proxy service |- [ INFO ] Stage: Clean up |- Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20160517222119-ndcyxn.log |- [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20160517223055-setup.conf' |- [ INFO ] Stage: Pre-termination |- [ INFO ] Stage: Termination |- [ INFO ] Execution of setup completed successfully |- HE_APPLIANCE_ENGINE_SETUP_SUCCESS [ INFO ] Engine-setup successfully completed [ INFO ] Engine is still unreachable [ INFO ] Engine is still not reachable, waiting... [ INFO ] Engine replied: DB Up!Welcome to Health Status! [ INFO ] Acquiring internal CA cert from the engine [ INFO ] The following CA certificate is going to be used, please immediately interrupt if not correct: [ INFO ] Issuer: C=US, O=rxmgmt.databay.de, CN=engine-mcIII.rxmgmt.databay.de.77792, Subject: C=US, O=rxmgmt.databay.de, CN=engine-mcIII.rxmgmt.databay.de.77792, Fingerprint (SHA-1): D71A5EA7C5C2C2450F1473523C3A1E022945430 [ INFO ] Connecting to the Engine [ ERROR ] Cannot automatically add the host to cluster Default: Host name must be formed of alphanumeric characters, numbers or "-_." Please check Engine VM configuration. Make a selection from the options below: (1) Continue setup - Engine VM configuration has been fixed (2) Abort setup (1, 2)[1]: 1 Checking for oVirt-Engine status at engine-mcIII.rxmgmt.databay.de... [ INFO ] Engine replied: DB Up!Welcome to Health Status! [ ERROR ] Cannot automatically add the host to cluster Default: Host name must be formed of alphanumeric characters, numbers or "-_." Please check Engine VM configuration. Make a selection from the options below: (1) Continue setup - Engine VM configuration has been fixed (2) Abort setup (1, 2)[1]: Additionally I can see the error in the eninge-vm in /var/log/ovirt-engine/engine.log: 2016-05-17 14:08:15,296 WARN [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] (default task-13) [9277b0a] CanDoAction of action 'AddVds' failed for user admin@internal. Reasons: VAR__ACTION__ADD,VAR__TYPE__HOST,$server microcloud21.rxmgmt.databay.de,VALIDATION_VDS_NAME_INVALID 2016-05-17 14:08:15,360 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-13) [] Operation Failed: [Host name must be formed of alphanumeric characters, numbers or "-_."] The hostname that should be registered is the correct fqdn for the virtualization host that runs the engine-vm, points to the ip of the ovirtmgmt-Bridge and also the IP is reverse-resolvable to the hostname. I checked /etc/hostname of the host for non-printable characters and as you can see that is a valid hostname. All is running on Centos 7 Versions: ovirt-engine-appliance.noarch 3.6-20160420.1.el7.centos @ovirt-3.6 ovirt-engine-sdk-python.noarch 3.6.5.0-1.el7.centos @ovirt-3.6 ovirt-host-deploy.noarch 1.4.1-1.el7.centos @ovirt-3.6 ovirt-hosted-engine-ha.noarch 1.3.5.3-1.1.el7 @centos-ovirt36 ovirt-hosted-engine-setup.noarch 1.3.5.0-1.1.el7 @centos-ovirt36 ovirt-setup-lib.noarch 1.0.1-1.el7.centos @ovirt-3.6 ovirt-vmconsole.noarch 1.0.0-1.el7.centos @ovirt-3.6 ovirt-vmconsole-host.noarch 1.0.0-1.el7.centos @ovirt-3.6 Since I already repeated the setup for many times now, I need your help. -- *Ralf Schenk* fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail *rs(a)databay.de* <mailto:rs@databay.de> *Databay AG* Jens-Otto-Krag-Straße 11 D-52146 Würselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) ------------------------------------------------------------------------ --------------B5233FE7196FCCD40BA3A0F3 Content-Type: multipart/related; boundary="------------612A57C905DDB6834F2B6528" --------------612A57C905DDB6834F2B6528 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> <p>Dear list,</p> <p>i'm working for days on a hosted-engine setup on glusterfs and 'm stuck in the last phase of hosted-engine --deploy see Text output (for two days now :-( ). I've only ovirtmgmt Bridge up and running and all DNS-Names seen in the screenshot are resolvable. It shouldn't be related to your problem regarding multiple nic's in the engine-vm. As seen the hosted-engine setup is already succsessfull, engine-vm running, but the setup fails in registering the host (microcloud21...) in the engine.</p> <p><tt><br> </tt></p> <p><tt>[...]</tt></p> <p><tt> |- [ INFO ] Starting engine service</tt><tt><br> </tt><tt> |- [ INFO ] Restarting httpd</tt><tt><br> </tt><tt> |- [ INFO ] Restarting ovirt-vmconsole proxy service</tt><tt><br> </tt><tt> |- [ INFO ] Stage: Clean up</tt><tt><br> </tt><tt> |- Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20160517222119-ndcyxn.log</tt><tt><br> </tt><tt> |- [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20160517223055-setup.conf'</tt><tt><br> </tt><tt> |- [ INFO ] Stage: Pre-termination</tt><tt><br> </tt><tt> |- [ INFO ] Stage: Termination</tt><tt><br> </tt><tt> |- [ INFO ] Execution of setup completed successfully</tt><tt><br> </tt><tt> |- HE_APPLIANCE_ENGINE_SETUP_SUCCESS</tt><tt><br> </tt><tt>[ INFO ] Engine-setup successfully completed</tt><tt><br> </tt><tt>[ INFO ] Engine is still unreachable</tt><tt><br> </tt><tt>[ INFO ] Engine is still not reachable, waiting...</tt><tt><br> </tt><tt>[ INFO ] Engine replied: DB Up!Welcome to Health Status!</tt><tt><br> </tt><tt>[ INFO ] Acquiring internal CA cert from the engine</tt><tt><br> </tt><tt>[ INFO ] The following CA certificate is going to be used, please immediately interrupt if not correct:</tt><tt><br> </tt><tt>[ INFO ] Issuer: C=US, O=rxmgmt.databay.de, CN=engine-mcIII.rxmgmt.databay.de.77792, Subject: C=US, O=rxmgmt.databay.de, CN=engine-mcIII.rxmgmt.databay.de.77792, Fingerprint (SHA-1): D71A5EA7C5C2C2450F1473523C3A1E022945430</tt><tt><br> </tt><tt>[ INFO ] Connecting to the Engine</tt><tt><br> </tt><tt>[ ERROR ] Cannot automatically add the host to cluster Default: Host name must be formed of alphanumeric characters, numbers or "-_."</tt><tt><br> </tt><tt><br> </tt><tt><br> </tt><tt> Please check Engine VM configuration.</tt><tt><br> </tt><tt><br> </tt><tt> Make a selection from the options below:</tt><tt><br> </tt><tt> (1) Continue setup - Engine VM configuration has been fixed</tt><tt><br> </tt><tt> (2) Abort setup</tt><tt><br> </tt><tt><br> </tt><tt> (1, 2)[1]: 1</tt><tt><br> </tt><tt><br> </tt><tt> Checking for oVirt-Engine status at engine-mcIII.rxmgmt.databay.de...</tt><tt><br> </tt><tt>[ INFO ] Engine replied: DB Up!Welcome to Health Status!</tt><tt><br> </tt><tt>[ ERROR ] Cannot automatically add the host to cluster Default: Host name must be formed of alphanumeric characters, numbers or "-_."</tt><tt><br> </tt><tt><br> </tt><tt><br> </tt><tt> Please check Engine VM configuration.</tt><tt><br> </tt><tt><br> </tt><tt> Make a selection from the options below:</tt><tt><br> </tt><tt> (1) Continue setup - Engine VM configuration has been fixed</tt><tt><br> </tt><tt> (2) Abort setup</tt><tt><br> </tt><tt><br> </tt><tt> (1, 2)[1]:</tt><tt><br> </tt></p> <p>Additionally I can see the error in the eninge-vm in /var/log/ovirt-engine/engine.log:</p> <p><tt>2016-05-17 14:08:15,296 WARN [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] (default task-13) [9277b0a] CanDoAction of action 'AddVds' failed for user admin@internal. Reasons: VAR__ACTION__ADD,VAR__TYPE__HOST,$server microcloud21.rxmgmt.databay.de,VALIDATION_VDS_NAME_INVALID</tt><tt><br> </tt><tt>2016-05-17 14:08:15,360 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-13) [] Operation Failed: [Host name must be formed of alphanumeric characters, numbers or "-_."]</tt><br> </p> The hostname that should be registered is the correct fqdn for the virtualization host that runs the engine-vm, points to the ip of the ovirtmgmt-Bridge and also the IP is reverse-resolvable to the hostname. <br> I checked /etc/hostname of the host for non-printable characters and as you can see that is a valid hostname.<br> <br> All is running on Centos 7 Versions: <br> <tt>ovirt-engine-appliance.noarch 3.6-20160420.1.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>ovirt-engine-sdk-python.noarch 3.6.5.0-1.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>ovirt-host-deploy.noarch 1.4.1-1.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>ovirt-hosted-engine-ha.noarch 1.3.5.3-1.1.el7 @centos-ovirt36</tt><tt><br> </tt><tt>ovirt-hosted-engine-setup.noarch 1.3.5.0-1.1.el7 @centos-ovirt36</tt><tt><br> </tt><tt>ovirt-setup-lib.noarch 1.0.1-1.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>ovirt-vmconsole.noarch 1.0.0-1.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>ovirt-vmconsole-host.noarch 1.0.0-1.el7.centos @ovirt-3.6</tt><tt><br> </tt><br> Since I already repeated the setup for many times now, I need your help.<br> <div class="moz-signature">-- <br> <p> </p> <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td colspan="3"><img src="cid:part1.3F247D48.E0F6EE3B@databay.de" height="30" border="0" width="151"></td> </tr> <tr> <td valign="top"> <font face="Verdana, Arial, sans-serif" size="-1"><br> <b>Ralf Schenk</b><br> fon +49 (0) 24 05 / 40 83 70<br> fax +49 (0) 24 05 / 40 83 759<br> mail <a href="mailto:rs@databay.de"><font color="#FF0000"><b>rs(a)databay.de</b></font></a><br> </font> </td> <td width="30"> </td> <td valign="top"> <font face="Verdana, Arial, sans-serif" size="-1"><br> <b>Databay AG</b><br> Jens-Otto-Krag-Straße 11<br> D-52146 Würselen<br> <a href="http://www.databay.de"><font color="#FF0000"><b>www.databay.de</b></font></a> </font> </td> </tr> <tr> <td colspan="3" valign="top"> <font face="Verdana, Arial, sans-serif" size="1"><br> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202<br> Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns<br> Aufsichtsratsvorsitzender: Klaus Scholzen (RA) </font> </td> </tr> </tbody> </table> <hr color="#000000" noshade="noshade" size="1" width="100%"> </div> </body> </html> --------------612A57C905DDB6834F2B6528 Content-Type: image/gif; name="logo_databay_email.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.3F247D48.E0F6EE3B(a)databay.de> Content-Disposition: inline; filename="logo_databay_email.gif" R0lGODlhlwAeAMQAAObm5v9QVf/R0oKBgfDw8NfX105MTLi3t/r6+sfHx/+rrf98gC0sLP8L EhIQEKalpf/g4ZmYmHd2dmppaf8uNP/y8v8cIv+Ym//AwkE/P46NjRwbG11cXP8ABwUDA/// /yH5BAAAAAAALAAAAACXAB4AAAX/4CeOYnUJZKqubOu+cCzPNA0tVnfVfO//wGAKk+t0Ap+K QMFUYCDCqHRKJVUWDaPRUsFktZ1G4AKtms9o1gKsFVS+7I5ll67bpd647hPQawNld4KDMQJF bA07F35aFBiEkJEpfXEBjx8KjI0Vkp2DEIdaCySgFBShbEgrCQOtrq+uEQcALQewrQUjEbe8 rgkkD7y5KhMZB3drqSoVFQhdlHGXKQYe1dbX2BvHKwzY1RMiAN7j1xEjBeTmKeIeD3cYCxRf FigvChRxFJwkBBvk5A7cpZhAjgGCDwn+kfslgto4CSoSehh2BwEEBQvowDAUR0EKdArHZTg4 4oDCXBFC/3qj9SEluZEpHnjYQFIGgpo1KgSasYjNKBImrzF4NaFbNgIjCGRQeIyVKwneOLzS cLCAg38OWI4Y4GECgQcSOEwYcADnh6/FNjAwoGFYAQ0atI4AAFeEFwsLFLiJUQEfGH0kNGAD x8+oNQdIRQg+7NCaOhIgD8sVgYADNsPVGI5YWjRqzQTdHDDIYHRDLokaUhCglkFEJi0NKJhl 0RP2TsvXUg88KiLBVWsZrF6DmMKlNYMqglqTik1guN8OBgAgkGCpB+L9ugK4iSCBvwEfECw1 kILrBpa1jVCQIQBRvbP+rlEcQVAoSevWyv6uhpwE12uEkQAAZucpVw1xIsjkgf8B863mQVYt eQATCZYJZJ5WBfij2wfpHcEeHGG8Z+BMszVWDXkfKLhceJhBSAJ+1ThH32AfRFZNayNAtUFi wFSTSwEHJIYAAQU84IADwyjIEALU9MchG+vFgIF7W2GDI2T7HfjBgNcgKQKMHmwjgnCSpeCb ULRkdxhF1CDY40RjgmUAA/v1J5FAKW2gGSZscBFDMraNgJs1AYpAAGYP5jJoNQ4Y4Gh8jpFg HH9mgbmWo1l6oA4C3Ygp6UwEIFBfNRtkMIBlKMLnAXgAXLWhXXH85EIFqMhGGZgDEKArABGA ed0HI4bk5qgnprCYSt88B6dqS0FEEAMPJDCdCJYViur/B1BlwGMJqDTwnhqxJgUpo0ceOQ4D 0yEakpMm/jqCRMgWm2I1j824Y6vLvuuPjHnqOJkIgP6xzwp5sCFNsCFp88Gxh11lrjfDcNrc CEx64/CD3iAHlQcMUEQXvcA+qBkBB4Q2X1CusjBlJdKMYAKI6g28MbKN5hJsBAXknHOwutn4 oFYqkpqAzjnPbE0u1PxmwAQGXLWBbvhuIIEGEnRjlAHO4SvhbCNAkwoGzEBwgV9U0lfu2WiX OkDEGaCdKgl0nk2YkWdPOCDabvaGdkAftL1LlgwCM+7Tq11V71IO7LkM2XE0YAHMYMhqqK6U V165CpaHukLmiXFO8XSVzzakX+UH6TrmAajPNxfqByTQec41AeBPvSwIALkmAnuiexCsca3C BajgfsROuxcPA8kHQJX4DAIwjnsAvhsvfXHWKEwDAljg7sj03L9wwAQTxOWD2AE0YP75eCkw cPfs+xACADs= --------------612A57C905DDB6834F2B6528-- --------------B5233FE7196FCCD40BA3A0F3--

2 1

How to migrate un-migratable VMs?
by Nicolas Ecarnot 18 May '16

18 May '16

Hi, Some VMs are doing high guest-memory writes (mainly files and mail servers, but not only), so migrations are reproductively failing. I found some info here : https://bugzilla.redhat.com/show_bug.cgi?id=919201 that confirm what I was fearing. This BZ is aging from dinosaurs times, so I was wondering now we're in the 3.6.x age and 4.x coming, are there advices one may give to migrate those verbose VMs? I guess increasing the allowed page memory is not a correct answer as it will fill as before. Any thoughts? -- Nicolas ECARNOT

3 3

Do you use ovirt-engine-reports?
by Yedidyah Bar David 18 May '16

18 May '16

Hi all, We are considering dropping ovirt-engine-reports in 4.0. Some of its functionality will be added in a new feature called "Dashboards", see [1]. Do you use Reports? How important it is to your setup? [1] https://bugzilla.redhat.com/1324860 Best regards, -- Didi

2 2

During Hosted Engine Deployment. CPU Type not listed as compatible. No selection to choose from.
by Langley, Robert 17 May '16

17 May '16

--_000_BY1PR09MB08248A0A6DCAA1B83FCF920C87480BY1PR09MB0824namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Host is a Dell PowerEdge 2950 with an Intel Xeon 5160 (Woodcrest) processor= . I'm stuck at the prompt, "Please specify the CPU type to be used by the VM = []" during the deployment. There is nothing to select. No compatible CPU type is shown. The server is from 2008 and I'm needing to use these older servers to get s= tarted, before I can bring in the newer ones that are busy hosting VMs. The other Dell PE 2950 is from 2007 and I was able to bring up the engine o= n that one. It is a Conroe CPU. I won't get into my mistake with that deplo= yment. I'm working on recovering from that one. I wanted to post about this, because I was trying to add this one (2008) as= an additional host and it wouldn't add, due to the processor. So, one question (in addition to the problem above) is whether or not I can= use two hosts with two different processors for the hosted engine? Thanks --_000_BY1PR09MB08248A0A6DCAA1B83FCF920C87480BY1PR09MB0824namp_ 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-micr= osoft-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=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Host is a Dell PowerEdge 2950 with an Intel Xeon 516= 0 (Woodcrest) processor.<o:p></o:p></p> <p class=3D"MsoNormal">I’m stuck at the prompt, “Please specify= the CPU type to be used by the VM []” during the deployment.<o:p></o= :p></p> <p class=3D"MsoNormal">There is nothing to select. No compatible CPU type i= s shown.<o:p></o:p></p> <p class=3D"MsoNormal">The server is from 2008 and I’m needing to use= these older servers to get started, before I can bring in the newer ones t= hat are busy hosting VMs.<o:p></o:p></p> <p class=3D"MsoNormal">The other Dell PE 2950 is from 2007 and I was able t= o bring up the engine on that one. It is a Conroe CPU. I won’t get in= to my mistake with that deployment. I’m working on recovering from th= at one.<o:p></o:p></p> <p class=3D"MsoNormal">I wanted to post about this, because I was trying to= add this one (2008) as an additional host and it wouldn’t add, due t= o the processor.<o:p></o:p></p> <p class=3D"MsoNormal">So, one question (in addition to the problem above) = is whether or not I can use two hosts with two different processors for the= hosted engine?<o:p></o:p></p> <p class=3D"MsoNormal">Thanks<o:p></o:p></p> </div> </body> </html> --_000_BY1PR09MB08248A0A6DCAA1B83FCF920C87480BY1PR09MB0824namp_--

2 3

oVirt Node 3.6
by Anantha Raghava 17 May '16

17 May '16

This is a multi-part message in MIME format. --------------060807060005060205020501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I attempted to download the oVirt Node 3.6 from http://resources.ovirt.org/pub/ovirt-3.6-snapshot/iso/ovirt-node-iso/ and I also find there is another ovirt-node-ng. Which one should we download. I downloaded the one at http://resources.ovirt.org/pub/ovirt-3.6-snapshot/iso/ovirt-node-iso/, but this iso file seems to have an issue. Although it boots the server properly at around 66% into installation, the installer throws up an error - I/O error, file not found or some thing of this sort. Installation doesn't go forward at all. We have to power off the server, reboot with CentOS DVD install using yum local install command. Are these files proper? Which one should we use? -- Thanks & Regards, Anantha Raghava --------------060807060005060205020501 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <font face="Liberation Serif">Hi,<br> <br> I attempted to download the oVirt Node 3.6 from <a class="moz-txt-link-freetext" href="http://resources.ovirt.org/pub/ovirt-3.6-snapshot/iso/ovirt-node-iso/">http://resources.ovirt.org/pub/ovirt-3.6-snapshot/iso/ovirt-node-iso/</a> and I also find there is another ovirt-node-ng. Which one should we download.<br> <br> I downloaded the one at <a class="moz-txt-link-freetext" href="http://resources.ovirt.org/pub/ovirt-3.6-snapshot/iso/ovirt-node-iso/">http://resources.ovirt.org/pub/ovirt-3.6-snapshot/iso/ovirt-node-iso/</a>, but this iso file seems to have an issue. Although it boots the server properly at around 66% into installation, the installer throws up an error - I/O error, file not found or some thing of this sort. Installation doesn't go forward at all. We have to power off the server, reboot with CentOS DVD install using yum local install command. <br> <br> Are these files proper? Which one should we use?<br> </font> <div class="moz-signature">-- <p style="margin-bottom: 0cm; line-height: 100%"><font face="Times New Roman, serif">Thanks & Regards,</font></p> <p style="margin-bottom: 0cm; line-height: 100%"><br> </p> <address style="line-height: 100%"><font face="Times New Roman, serif">Anantha Raghava</font></address> <br clear="left"> <br> </div> </body> </html> --------------060807060005060205020501--

2 2

oVirt & gluster - which copy is written to?
by Bill Bill 17 May '16

17 May '16

--_000_SN1PR08MB1389E9AA24246B61EE308341A6730SN1PR08MB1389namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkxldOKAmXMgc2F5IEkgaGF2ZSBhIDUgbm9kZSBjb252ZXJnZWQgY2x1c3RlciBv ZiBvVmlydCAmIGdsdXN0ZXJGUyB3aXRoIGEgcmVwbGljYSBjb3VudCBvZiDigJwz4oCdLg0KDQpI b3N0MSAtIHJlcGxpY2ENCkhvc3QyIC0gcmVwbGljYQ0KSG9zdDMgLSByZXBsaWNhDQpIb3N0NA0K SG9zdDUNCg0KSWYgSSBzcGluIGEgVk0gdXAgb24gSG9zdDEg4oCTIGRvZXMgdGhlIGZpcnN0IHJl cGxpY2EgZ2V0IGNyZWF0ZWQgbG9jYWwgdG8gdGhhdCBzZXJ2ZXI/DQoNCkluIHRoZSBldmVudCBJ IG1vdmUgdGhlIFZNIHRvIGFub3RoZXIgaG9zdCwgZG9lcyB0aGUgcmVwbGljYSBvZiB0aGUgZGlz ayBmb2xsb3cgdGhlIFZNIHNvIGVzc2VudGlhbGx5IGl04oCZcyB3cml0aW5nIHRvIGEgbG9jYWwg Y29weSBmaXJzdCBvciBkb2VzIGl0IOKAnGFsd2F5c+KAnSB3cml0ZSBhY3Jvc3MgdGhlIG5ldHdv cmsuDQoNCkZvciBleGFtcGxlLCB3aXRoIFZNd2FyZSwgdGhlIGRpc2sgd2lsbCBmb2xsb3cgdGhl IFZNIHRvIHRoZSBoeXBlcnZpc29yIHlvdSBtb3ZlIGl0IHRvIHNvIHRoYXQgdGhlIHdyaXRlcyBh cmUgZXNzZW50aWFsbHkg4oCcbG9jYWzigJ0uDQoNCkkgaGF2ZSBub3QgYmVlbiBhYmxlIHRvIGZp bmQgYW55dGhpbmcgb24gdGhlIGludGVybmV0IG9yIGluIHRoZSBkb2N1bWVudGF0aW9uIHRoYXQg c3BlY2lmaWVzIGhvdyB0aGlzIHByb2Nlc3Mgd29ya3MuIElkZWFsbHksIHlvdSB3b3VsZG7igJl0 IHdhbnQgYSBWTSByZXNpZGluZyBvbiBIb3N0MSB0aGF0IGFjY2Vzc2VzIGl0cyBkaXNrIG9uIEhv c3QzLiBNdWx0aXBsZSB0aGF0IGJ5IGh1bmRyZWRzIG9mIFZN4oCZcyBhbmQgaXQgd291bGQgY3Jl YXRlIGEgdG9uIG9mIHVubmVjZXNzYXJ5IG5ldHdvcmsgY29uZ2VzdGlvbi4NCg0K --_000_SN1PR08MB1389E9AA24246B61EE308341A6730SN1PR08MB1389namp_ Content-Type: text/html; charset="utf-8" Content-ID: <7766EE5FA0193D41AFCE783FA42221BE(a)sct-15-1-485-2-msonline-outlook-1173a.templateTenant> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVs bG8sPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TGV04oCZcyBzYXkgSSBoYXZlIGEgNSBub2RlIGNvbnZlcmdlZCBjbHVzdGVyIG9mIG9W aXJ0ICZhbXA7IGdsdXN0ZXJGUyB3aXRoIGEgcmVwbGljYSBjb3VudCBvZiDigJwz4oCdLjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhv c3QxIC0gcmVwbGljYTwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvc3QyIC0gcmVwbGljYTwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvc3QzIC0gcmVwbGljYTwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhvc3Q0PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG9zdDU8L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPklmIEkgc3BpbiBhIFZNIHVw IG9uIEhvc3QxIOKAkyBkb2VzIHRoZSBmaXJzdCByZXBsaWNhIGdldCBjcmVhdGVkIGxvY2FsIHRv IHRoYXQgc2VydmVyPzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPkluIHRoZSBldmVudCBJIG1vdmUgdGhlIFZNIHRvIGFub3RoZXIgaG9zdCwg ZG9lcyB0aGUgcmVwbGljYSBvZiB0aGUgZGlzayBmb2xsb3cgdGhlIFZNIHNvIGVzc2VudGlhbGx5 IGl04oCZcyB3cml0aW5nIHRvIGEgbG9jYWwgY29weSBmaXJzdCBvciBkb2VzIGl0IOKAnGFsd2F5 c+KAnSB3cml0ZSBhY3Jvc3MNCiB0aGUgbmV0d29yay48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Gb3IgZXhhbXBsZSwgd2l0aCBWTXdhcmUs IHRoZSBkaXNrIHdpbGwgZm9sbG93IHRoZSBWTSB0byB0aGUgaHlwZXJ2aXNvciB5b3UgbW92ZSBp dCB0byBzbyB0aGF0IHRoZSB3cml0ZXMgYXJlIGVzc2VudGlhbGx5IOKAnGxvY2Fs4oCdLg0KPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7 PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SSBo YXZlIG5vdCBiZWVuIGFibGUgdG8gZmluZCBhbnl0aGluZyBvbiB0aGUgaW50ZXJuZXQgb3IgaW4g dGhlIGRvY3VtZW50YXRpb24gdGhhdCBzcGVjaWZpZXMgaG93IHRoaXMgcHJvY2VzcyB3b3Jrcy4g SWRlYWxseSwgeW91IHdvdWxkbuKAmXQgd2FudCBhIFZNIHJlc2lkaW5nIG9uIEhvc3QxIHRoYXQN CiBhY2Nlc3NlcyBpdHMgZGlzayBvbiBIb3N0My4gTXVsdGlwbGUgdGhhdCBieSBodW5kcmVkcyBv ZiBWTeKAmXMgYW5kIGl0IHdvdWxkIGNyZWF0ZSBhIHRvbiBvZiB1bm5lY2Vzc2FyeSBuZXR3b3Jr IGNvbmdlc3Rpb24uPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN1PR08MB1389E9AA24246B61EE308341A6730SN1PR08MB1389namp_--

3 2

IsolatedNetworks
by Winfried de Heiden 17 May '16

17 May '16

Hi All, As described on http://old.ovirt.org/Features/IsolatedNetworks, Isolated networks in one of proposed features of oVirt 4.0: "The current host networking api (up to ovirt-engine-3.6) requires a network to be configured on top of a network interface. In order to configure a local network on the host the user had to create a dummy interface to which the network was attached. The Isolated Networks feature aimed to configure a local host on the network which isn't connected to any network interface and allows vms which are connected to it to communicate with each other. Isolated Networks will be limited to VM networks only and only MTU should be relevant in that network definition for the created isolated network." Hence, I should be able to create a host-only network with an underlaying NIC; sounds nice for my @home Cloud... However, runing oVirt 4.0 it is still complaining a NIC is misssing. I might have configured something wrong. How to set create an isolated network? Is there already any documentation? Kind regards, Winny

2 1

VMs seems to be slow, while snapshot delete is happening
by SATHEESARAN 17 May '16

17 May '16

Hi All, I have created a VM with 60GB of disk space. I have started I/O inside the VM, after sometime when the disk was 4GB full, I took a snapshot of the disk from UI. I/O kept continuing and the new image file ( overlay file ) was 15GB in size. Now I deleted the snapshot. I think this would initiate block-merges. During this time, my I/O was were slower, till the snapshot delete is completed. Its not very slow, but slow. Is this a known behavior ? Advance thanks, Satheesaran S

2 2

Re: [ovirt-users] Adding another host to my cluster
by Charles Tassell 16 May '16

16 May '16

Hey Gervais, Try enabling NetworkManager and firewalld before doing the hosted-engine --deploy. I have run into problems with oVirt trying to perform tasks on hosts where firewalld is disabled, so maybe you are running into a similar problem. Also, I think the setup script will disable NetworkManager if it needs to. I know I didn't manually disable it on any of the boxes I installed on. On 16-05-12 04:49 PM, users-request(a)ovirt.org wrote: > Message: 1 > Date: Thu, 12 May 2016 14:22:12 -0300 > From: Gervais de Montbrun <gervais(a)demontbrun.com> > To: Wee Sritippho <wee.s(a)forest.go.th> > Cc: users <users(a)ovirt.org> > Subject: Re: [ovirt-users] Adding another host to my cluster > Message-ID: <28B7FC74-5C52-4F60-B9F3-39A36621A7CA(a)demontbrun.com> > Content-Type: text/plain; charset="utf-8" > > Hi Wee > (and others) > > Thanks for the reply. I tried what you suggested, but I am in the exact same state. :-( > > I don't want to completely remove my hosted engine setup as it is working on the two other hosts in my cluster. I did not run the rm -rf stes listed here (https://www.ovirt.org/documentation/how-to/hosted-engine/#recoving-from-fai… <https://www.ovirt.org/documentation/how-to/hosted-engine/#recoving-from-fai…>) that would wipe my hosted_engine nfs mount. If you know that this is 100% necessary, please let me know. > > I did: > hosted-engine --clean-metadata --force-cleanup --host-id=3 > run the bash script to remove all of the ovirt packages and config files > reinstalled ovirt-hosted-engine-setup > ran "hosted-engine --deploy" > > I'm back exactly where I started. Is there a way to run just the network configuration part of the deploy? > > Since the last attempt, I did upgrade my hosted engine and my cluster is now running oVirt 3.6.5. > > Cheers, > Gervais > > > >> On May 12, 2016, at 11:50 AM, Wee Sritippho <wee.s(a)forest.go.th> wrote: >> >> Hi, >> >> I used to have a similar problem where one of my host can't be deployed due to the absence of ovirtmgmt bridge. Simone said it's a bug ( https://bugzilla.redhat.com/1323465 <https://bugzilla.redhat.com/1323465> ) which would be fixed in 3.6.6. >> >> This is what I've done to solve it: >> >> 1. In the web UI, set the failed host to maintenance. >> 2. Remove it. >> 3. In that host, run a script from https://www.ovirt.org/documentation/how-to/hosted-engine/#recoving-from-fai… <https://www.ovirt.org/documentation/how-to/hosted-engine/#recoving-from-fai…> >> 4. Install ovirt-hosted-engine-setup again. >> 5. Redeploy again. >> >> Hope that helps >> >> On 11 ??????? 2016 22 ?????? 48 ???? 58 ?????? GMT+07:00, Gervais de Montbrun <gervais(a)demontbrun.com> wrote: >> Hi Folks, >> >> I hate to reply to my own message, but I'm really hoping someone can help me with my issue >> http://lists.ovirt.org/pipermail/users/2016-May/039690.html <http://lists.ovirt.org/pipermail/users/2016-May/039690.html> >> >> Does anyone have a suggestion for me? If there is any more information that I can provide that would help you to help me, please advise. >> >> Cheers, >> Gervais >> >> >> >>> On May 9, 2016, at 1:42 PM, Gervais de Montbrun <gervais(a)demontbrun.com <mailto:gervais@demontbrun.com>> wrote: >>> >>> Hi All, >>> >>> I'm trying to add a third host into my oVirt cluster. I have hosted engine setup on the first two. It's failing to finish the hosted-engine --deploy on this third host. I wiped the server and did a CentOS 7 minimum install and ran it again to have a clean machine. >>> >>> My setup: >>> CentOS 7 clean install >>> yum install -y http://resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm <http://resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm> >>> yum install -y ovirt-hosted-engine-setup >>> yum upgrade -y && reboot >>> systemctl disable NetworkManager ; systemctl stop NetworkManager ; systemctl disable firewalld ; systemctl stop firewalld >>> hosted-engine --deploy >>> >>> hosted-engine --deploy always throws an error: >>> [ ERROR ] The VDSM host was found in a failed state. Please check engine and bootstrap installation logs. >>> [ ERROR ] Unable to add Cultivar2 to the manager >>> and then echo's >>> [ INFO ] Waiting for VDSM hardware info >>> ... >>> [ ERROR ] Failed to execute stage 'Closing up': VDSM did not start within 120 seconds >>> [ INFO ] Stage: Clean up >>> [ INFO ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20160509131103.conf' >>> [ INFO ] Stage: Pre-termination >>> [ INFO ] Stage: Termination >>> [ ERROR ] Hosted Engine deployment failed: this system is not reliable, please check the issue, fix and redeploy >>> Log file is located at /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20160509130658-qb8ev0.log >>> >>> Full output of hosted-engine --deploy included in the attached zip file. >>> I've also included vdsm.log (There is more than one tries worth of tries in there). >>> You'll also find the ovirt-hosted-engine-setup-20160509130658-qb8ev0.log listed above. >>> >>> This is my "test" setup. Cultivar0 is my first host and my nfs server for storage. I have two hosts in the setup already and everything is working fine. The host does show up in the oVirt admin, but shows "Installed Failed" >>> <PastedGraphic-1.png> >>> >>> Trying to reinstall from within the interface just fails again. >>> >>> The ovirt bridge interface is not configured and there are no config files in /etc/sysconfi/network-scripts related to ovirt. >>> >>> OS: >>> [root@cultivar2 ovirt-hosted-engine-setup]# cat /etc/redhat-release >>> CentOS Linux release 7.2.1511 (Core) >>> >>> [root@cultivar2 ovirt-hosted-engine-setup]# uname -a >>> Linux cultivar2.grove.silverorange.com <http://cultivar2.grove.silverorange.com/> 3.10.0-327.13.1.el7.x86_64 #1 SMP Thu Mar 31 16:04:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux >>> >>> Versions: >>> [root@cultivar2 ovirt-hosted-engine-setup]# rpm -qa | grep -i ovirt >>> libgovirt-0.3.3-1.el7_2.1.x86_64 >>> ovirt-hosted-engine-setup-1.3.5.0-1.1.el7.noarch >>> ovirt-host-deploy-1.4.1-1.el7.centos.noarch >>> ovirt-vmconsole-1.0.0-1.el7.centos.noarch >>> ovirt-vmconsole-host-1.0.0-1.el7.centos.noarch >>> ovirt-release36-007-1.noarch >>> ovirt-engine-sdk-python-3.6.5.0-1.el7.centos.noarch >>> ovirt-setup-lib-1.0.1-1.el7.centos.noarch >>> ovirt-hosted-engine-ha-1.3.5.3-1.1.el7.noarch >>> [root@cultivar2 ovirt-hosted-engine-setup]# >>> [root@cultivar2 ovirt-hosted-engine-setup]# >>> [root@cultivar2 ovirt-hosted-engine-setup]# >>> [root@cultivar2 ovirt-hosted-engine-setup]# rpm -qa | grep -i virt >>> libvirt-daemon-driver-secret-1.2.17-13.el7_2.4.x86_64 >>> virt-viewer-2.0-6.el7.x86_64 >>> libgovirt-0.3.3-1.el7_2.1.x86_64 >>> libvirt-daemon-kvm-1.2.17-13.el7_2.4.x86_64 >>> ovirt-hosted-engine-setup-1.3.5.0-1.1.el7.noarch >>> fence-virt-0.3.2-2.el7.x86_64 >>> virt-what-1.13-6.el7.x86_64 >>> libvirt-python-1.2.17-2.el7.x86_64 >>> libvirt-daemon-1.2.17-13.el7_2.4.x86_64 >>> libvirt-daemon-config-nwfilter-1.2.17-13.el7_2.4.x86_64 >>> libvirt-lock-sanlock-1.2.17-13.el7_2.4.x86_64 >>> libvirt-daemon-driver-nodedev-1.2.17-13.el7_2.4.x86_64 >>> libvirt-daemon-driver-network-1.2.17-13.el7_2.4.x86_64 >>> libvirt-daemon-driver-storage-1.2.17-13.el7_2.4.x86_64 >>> ovirt-host-deploy-1.4.1-1.el7.centos.noarch >>> virt-v2v-1.28.1-1.55.el7.centos.2.x86_64 >>> ovirt-vmconsole-1.0.0-1.el7.centos.noarch >>> ovirt-vmconsole-host-1.0.0-1.el7.centos.noarch >>> libvirt-client-1.2.17-13.el7_2.4.x86_64 >>> libvirt-daemon-driver-nwfilter-1.2.17-13.el7_2.4.x86_64 >>> ovirt-release36-007-1.noarch >>> libvirt-daemon-driver-interface-1.2.17-13.el7_2.4.x86_64 >>> libvirt-daemon-driver-qemu-1.2.17-13.el7_2.4.x86_64 >>> ovirt-engine-sdk-python-3.6.5.0-1.el7.centos.noarch >>> ovirt-setup-lib-1.0.1-1.el7.centos.noarch >>> ovirt-hosted-engine-ha-1.3.5.3-1.1.el7.noarch >>> >>> I also have a series of stuck tasks that I can't clear related to the host that can't be added... This is a secondary issue and I don't want to get off track, but they look like this: >>> <PastedGraphic-2.png> >>> >>> I'd appreciate any help that can be offered. >>> >>> Cheers, >>> Gervais >>> >>> >>> Gervais de Montbrun >>> Systems Administrator / silverorange Inc. >>> >>> Phone +1 902 367 4532 ext. 104 <tel:+1 902 367 4532 ext. 104> >>> Mobile +1 902 978 0009 <tel:+1 902 978 0009> >>> >>> <hosted-engine--deploy-logs.zip> >> >> >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users <http://lists.ovirt.org/mailman/listinfo/users> >> >> -- >> Wee >

4 11

USB
by Brett I. Holcomb 16 May '16

16 May '16

How do I get a VM to see USB devices? If I understand it correctly I have to go to Edit VM -> Console and enable USB native. I have the console options set to use usb. However, I'm finding conflicting information. Supposedly libvirt will allow sharing of a USB device over a network but to start with I'd be happy just being able to connect a usb device to the host and having it detected. I have some programmable devices I'd like to program in Linux using my VM. Has anyone uses usbip and if so how well does it work?

3 3

Unable to install 3.6.5 under CentOS 6.7
by Tom Lambdin 16 May '16

16 May '16

--Apple-Mail=_08403896-EA5E-474D-91FC-4F685EBD9816 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Although the release note indicates that 3.6.5 is supported under = CentOS/RHEL 6.7, when we attempt to update to the the latest version = under CentOS 6.7, the highest version we can get from the repo is 3.6.3. If we spin up a brand new machine running CentOS 7.2, we do however = successfully get 3.6.5. Ideally we=E2=80=99d like to avoid having to = migrate our management host to CentOS 7 at this time. Is there something we=E2=80=99re missing here or is there a problem with = the repo configuration? Regards, -Tom Lambdin --Apple-Mail=_08403896-EA5E-474D-91FC-4F685EBD9816 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXOZngAAoJEHN9aBbFQxh53lQH/24JE/jH6N3NTanyJVAH49ul 7TUUZCySt1EMW4Gvqypld2IWsUKbh/JnORlqXU4jWmvBrjRcVWEj+mWLRPmFp0/o WbRCGK4OJvgDgYTxssmjWPe2wxWdEw0XCJsT1pmWyYSLjO4M0ZKWfXxKG9sFOihe 8KgNLYSLIHSbBCqrckb1S9GwjHpemxYGtupDJOhMpo10vXwFkmED6+maUGsYhK3W 7xcIIciKRZjVn52BRyQ+wE/9AYoaDpn37NSJG74JAx8abkC2zsSoPQf+W5raEPWe RA/zGCUUYEadQPjMoQkrgQenAMYzDeHs+6CB0qRzrGEVwMg2M+fgIx2PiFWriWE= =blJi -----END PGP SIGNATURE----- --Apple-Mail=_08403896-EA5E-474D-91FC-4F685EBD9816--

2 2

disk order in vm and disk order in export
by Fabrice Bacchella 16 May '16

16 May '16

--Apple-Mail=_0FD01BB4-6FFE-420A-805E-4CF6B336A6A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have a VM with the following disks (in the ordrer return by a get = query): =20 <Disk = href=3D"/api/vms/2ddfb8c3-d258-4d3e-9f65-fc247d0a03f6/disks/1180405d-699e-= 4594-bf73-8b1b170f38a9" id=3D"1180405d-699e-4594-bf73-8b1b170f38a9"> ... <name>vm_sys</name> <actual_size>17179869184</actual_size> <- 16GiB <interface>virtio_scsi</interface> <bootable>true</bootable> <storage_type>image</storage_type> </Disk> <Disk = href=3D"/api/vms/2ddfb8c3-d258-4d3e-9f65-fc247d0a03f6/disks/1fe74758-c521-= 40ed-b8e5-d02d80188088" id=3D"1fe74758-c521-40ed-b8e5-d02d80188088"> <name>vm_data</name> <interface>virtio_scsi</interface> <bootable>false</bootable> <lun_storage id=3D"3600c0ff00026285a2091355701000000"> <logical_unit id=3D"3600c0ff00026285a2091355701000000"> <size>1099511627776</size> <- 1 TiB. <paths>0</paths> </logical_unit> </lun_storage> <storage_type>lun</storage_type> </Disk> So the first one is a 16 GiB virtual disk, the second one a 1 iTB direct = access LUN that will contains data. But once booterd, I see: lsblk =20 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1T 0 disk=20 ... sdb 8:16 0 16G 0 disk=20 ... and : ls -l /dev/disk/by-*/* ... lrwxrwxrwx. 1 root root 9 May 16 09:03 = /dev/disk/by-path/pci-0000:00:04.0-scsi-0:0:0:0 -> ../../sda lrwxrwxrwx. 1 root root 9 May 16 09:03 = /dev/disk/by-path/pci-0000:00:04.0-scsi-0:0:0:1 -> ../../sdb So the first disk sda is the second non bootable disk. What set the disk order associated to a VM ? Is there a way to enforce = that the first disk is really the first disk ?= --Apple-Mail=_0FD01BB4-6FFE-420A-805E-4CF6B336A6A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div style=3D"margin: 0px 0px 0px 6px; font-family: = 'Helvetica Neue';" class=3D""><span style=3D"font-family: Helvetica;" = class=3D"">I have a VM with the following disks (in the ordrer return by = a get query):</span><div class=3D"" style=3D"font-family: = Helvetica;"> <div class=3D""><div class=3D"" style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;"><Disk = href=3D"/api/vms/2ddfb8c3-d258-4d3e-9f65-fc247d0a03f6/disks/1180405d-699e-= 4594-bf73-8b1b170f38a9" = id=3D"1180405d-699e-4594-bf73-8b1b170f38a9"></div><div class=3D"" = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;">  =   ...</div><div class=3D"" style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;">    = <name>vm_sys</name></div><div class=3D"" style=3D"margin: = 0px; font-size: 11px; font-family: Menlo;">    = <actual_size>17179869184</actual_size> <- 16GiB</div><div = class=3D"" style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;">    = <interface>virtio_scsi</interface></div><div class=3D"" = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;">  =   <bootable>true</bootable></div><div class=3D"" = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;">  =   <storage_type>image</storage_type></div><div class=3D""= style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;"></Disk></div><div class=3D"" style=3D"margin: 0px; = font-size: 11px; font-family: Menlo; min-height: 13px;"><br = class=3D""></div><div class=3D"" style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;"><Disk = href=3D"/api/vms/2ddfb8c3-d258-4d3e-9f65-fc247d0a03f6/disks/1fe74758-c521-= 40ed-b8e5-d02d80188088" = id=3D"1fe74758-c521-40ed-b8e5-d02d80188088"></div><div class=3D"" = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;">  =   <name>vm_data</name></div><div class=3D"" = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;">  =   <interface>virtio_scsi</interface></div><div class=3D""= style=3D"margin: 0px; font-size: 11px; font-family: Menlo;">  =   <bootable>false</bootable></div><div class=3D"" = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;">  =   <lun_storage = id=3D"3600c0ff00026285a2091355701000000"></div><div class=3D"" = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;">  =       <logical_unit = id=3D"3600c0ff00026285a2091355701000000"></div><div class=3D"" = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;">  =           = <size>1099511627776</size> <- 1 TiB.</div><div class=3D"" = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;">  =           = <paths>0</paths></div><div class=3D"" style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;">        = </logical_unit></div><div class=3D"" style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;">    = </lun_storage></div><div class=3D"" style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;">    = <storage_type>lun</storage_type></div><div class=3D"" = style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;"></Disk></div></div><div class=3D""><br class=3D""></div><div= class=3D"">So the first one is a 16 GiB virtual disk, the second one a = 1 iTB direct access LUN that will contains data.</div></div><div = class=3D"" style=3D"font-family: Helvetica;"><br class=3D""></div><div = class=3D"" style=3D"font-family: Helvetica;">But once booterd, I = see:</div><div class=3D"" style=3D"font-family: Helvetica;"><div = class=3D"">lsblk   </div><div class=3D"">NAME     =    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT</div><div = class=3D"">sda           8:0    0 =     1T  0 disk </div></div><div class=3D"" = style=3D"font-family: Helvetica;">...</div><div class=3D"" = style=3D"font-family: Helvetica;"><div class=3D"">sdb     =       8:16   0    16G  0 = disk </div></div><div class=3D"" style=3D"font-family: = Helvetica;">...</div><div class=3D"" style=3D"font-family: = Helvetica;"><br class=3D""></div><div class=3D"" style=3D"font-family: = Helvetica;">and :</div><div class=3D"" style=3D"font-family: = Helvetica;"><div class=3D"">ls -l /dev/disk/by-*/*</div></div><div = class=3D"" style=3D"font-family: Helvetica;">...</div><div class=3D"" = style=3D"font-family: Helvetica;"><div class=3D"">lrwxrwxrwx. 1 root = root  9 May 16 09:03 = /dev/disk/by-path/pci-0000:00:04.0-scsi-0:0:0:0 -> = ../../sda</div></div><div class=3D"" style=3D"font-family: = Helvetica;"><div class=3D"">lrwxrwxrwx. 1 root root  9 May 16 09:03 = /dev/disk/by-path/pci-0000:00:04.0-scsi-0:0:0:1 -> = ../../sdb</div></div><div class=3D"" style=3D"font-family: = Helvetica;"><br class=3D""></div><div class=3D"" style=3D"font-family: = Helvetica;">So the first disk sda is the second non bootable = disk.</div><div class=3D"" style=3D"font-family: Helvetica;">What set = the disk order associated to a VM ? Is there a way to enforce that the = first disk is really the first disk ?</div></div></body></html>= --Apple-Mail=_0FD01BB4-6FFE-420A-805E-4CF6B336A6A8--

1 0

ovirt-engine yum install
by Budur Nagaraju 15 May '16

15 May '16

Hi while doing yum install "yum -y install ovirt-engine" getting error which url not found,can you please help me on that ? http://pastebin.com/rX744rcW Thanks, Nagaraju

3 3

USB
by Brett I. Holcomb 15 May '16

15 May '16

How do I get a VM to see USB devices? If I understand it correctly I have to go to Edit VM -> Console and enable USB native. I have the console options set to use usb. However, I'm finding conflicting information. Supposedly libvirt will allow sharing of a USB device over a network but to start with I'd be happy just being able to connect a usb device to the host and having it detected. I have some programmable devices I'd like to program in Linux using my VM. Has anyone uses usbip and if so how well does it work?

1 0

Failed to activate Storage Domain infer (Data Center Default) by admin
by William Kwan 14 May '16

14 May '16

------=_Part_1857742_1292403466.1463201198840 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hi all, I still have the lock error which I need some help to resolve. I found some= posts used sanlock command. But I'm not sure if it fit in my case.=C2=A0Th= anks in advance.=C2=A0libvirtError: Failed to acquire lock: No space left o= n deviceThread-49::DEBUG::2016-05-13 22:02:49,693::vm::2779::vm.Vm::(setDow= nStatus) vmId=3D`bd48bba5-4109-4a58-ac89-832add1f4de4`::Changed state to Do= wn: Failed to acquire lock: No space left on device=C2=A0 I wasn't able to bring up the hosted-engine on Node1 and I got the above er= ror. =C2=A0I was able to run `hosted-engine --start-pool` on Node2, but not= Node1. #hosted-engine --start-poolConnecting Storage Pool Starting SPMf5f78fb8-42e3-46e5-93c2-6c3b00914048Activating Storage DomainRe= source timeout: () With the "Storage pool" up on Node2, I was able to start the hosted-engine.= =C2=A0But when I try to active the Master storage domain called 'infra' "Host cannot access the Storage Domain(s) <UNKNOWN> attached to the Data Ce= nter Default. Setting Host state to Non-Operational""Failed to connect Host= to Storage Pool Default" Tried again and I would get=C2=A0"Failed to activate Storage Domain infra (= Data Center Default)" ThanksW ------=_Part_1857742_1292403466.1463201198840 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body><div style=3D"color:#000; background-color:#fff; f= ont-family:Courier New, courier, monaco, monospace, sans-serif;font-size:13= px"><div id=3D"yui_3_16_0_ym19_1_1463183424286_23613"><font size=3D"2" id= =3D"yui_3_16_0_ym19_1_1463183424286_27097">hi all,</font></div><div id=3D"y= ui_3_16_0_ym19_1_1463183424286_23613"><font size=3D"2"><br></font></div><di= v id=3D"yui_3_16_0_ym19_1_1463183424286_23613" dir=3D"ltr"><font size=3D"2"= id=3D"yui_3_16_0_ym19_1_1463183424286_27250">I still have the lock error w= hich I need some help to resolve. I found some posts used sanlock command. = But I'm not sure if it fit in my case. </font><span style=3D"font-size= : small;">Thanks in advance.</span></div><div id=3D"yui_3_16_0_ym19_1_14631= 83424286_23613" dir=3D"ltr"><font size=3D"2" id=3D"yui_3_16_0_ym19_1_146318= 3424286_27109"> </font></div><div style=3D"margin-top: 0px; margin-bot= tom: 0px; line-height: normal;" id=3D"yui_3_16_0_ym19_1_1463183424286_26357= "><span id=3D"yui_3_16_0_ym19_1_1463183424286_26358"><font size=3D"2" id=3D= "yui_3_16_0_ym19_1_1463183424286_27151">libvirtError: Failed to acquire loc= k: No space left on device</font></span></div><div id=3D"yui_3_16_0_ym19_1_= 1463183424286_26359"></div><div style=3D"margin-top: 0px; margin-bottom: 0p= x; line-height: normal;" dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1463183424286_= 26360"><span id=3D"yui_3_16_0_ym19_1_1463183424286_26361"><font size=3D"2" = id=3D"yui_3_16_0_ym19_1_1463183424286_27149">Thread-49::DEBUG::2016-05-13 2= 2:02:49,693::vm::2779::vm.Vm::(setDownStatus) vmId=3D`bd48bba5-4109-4a58-ac= 89-832add1f4de4`::Changed state to Down: Failed to acquire lock: No space l= eft on device </font></span></div><div style=3D"margin-top: 0px; margi= n-bottom: 0px; line-height: normal;" dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_14= 63183424286_26360"><span><font size=3D"2"><br></font></span></div><div styl= e=3D"margin-top: 0px; margin-bottom: 0px; line-height: normal;" dir=3D"ltr"= id=3D"yui_3_16_0_ym19_1_1463183424286_26360"><span><font size=3D"2"><br></= font></span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; line-h= eight: normal;" dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1463183424286_26360"><s= pan id=3D"yui_3_16_0_ym19_1_1463183424286_26372"><font size=3D"2" id=3D"yui= _3_16_0_ym19_1_1463183424286_27110">I wasn't able to bring up the hosted-en= gine on Node1 and I got the above error.  I was able to run `hosted-en= gine --start-pool` on Node2, but not Node1.</font></span></div><div style= =3D"margin-top: 0px; margin-bottom: 0px; line-height: normal;" dir=3D"ltr" = id=3D"yui_3_16_0_ym19_1_1463183424286_26360"><div style=3D"margin-top: 0px;= margin-bottom: 0px; line-height: normal;" id=3D"yui_3_16_0_ym19_1_14631834= 24286_26491"><div style=3D"line-height: normal;" id=3D"yui_3_16_0_ym19_1_14= 63183424286_26541"><span style=3D"font-variant-ligatures: no-common-ligatur= es"><font size=3D"2"><br></font></span></div><div style=3D"line-height: nor= mal;" id=3D"yui_3_16_0_ym19_1_1463183424286_26541"><span style=3D"font-vari= ant-ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_2= 6542"><font size=3D"2" id=3D"yui_3_16_0_ym19_1_1463183424286_27154">#hosted= -engine --start-pool</font></span></div> <div style=3D"line-height: normal;" id=3D"yui_3_16_0_ym19_1_1463183424286_2= 6543"><span style=3D"font-variant-ligatures: no-common-ligatures" id=3D"yui= _3_16_0_ym19_1_1463183424286_26544"><font size=3D"2" id=3D"yui_3_16_0_ym19_= 1_1463183424286_27120">Connecting Storage Pool</font></span></div> <div style=3D"line-height: normal; min-height: 14px;" id=3D"yui_3_16_0_ym19= _1_1463183424286_26545"><font size=3D"2"><span style=3D"font-variant-ligatu= res: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_26546"></sp= an><br id=3D"yui_3_16_0_ym19_1_1463183424286_26547"></font></div> <div style=3D"line-height: normal;" id=3D"yui_3_16_0_ym19_1_1463183424286_2= 6548"><span style=3D"font-variant-ligatures: no-common-ligatures" id=3D"yui= _3_16_0_ym19_1_1463183424286_26549"><font size=3D"2" id=3D"yui_3_16_0_ym19_= 1_1463183424286_27112">Starting SPM</font></span></div> <div style=3D"line-height: normal;" id=3D"yui_3_16_0_ym19_1_1463183424286_2= 6550"><span style=3D"font-variant-ligatures: no-common-ligatures" id=3D"yui= _3_16_0_ym19_1_1463183424286_26551"><font size=3D"2">f5f78fb8-42e3-46e5-93c= 2-6c3b00914048</font></span></div> <div style=3D"line-height: normal;" id=3D"yui_3_16_0_ym19_1_1463183424286_2= 6552"><span style=3D"font-variant-ligatures: no-common-ligatures" id=3D"yui= _3_16_0_ym19_1_1463183424286_26553"><font size=3D"2">Activating Storage Dom= ain</font></span></div> <div style=3D"line-height: normal;" id=3D"yui_3_16_0_ym19_1_1463183424286_2= 6554"><span style=3D"font-variant-ligatures: no-common-ligatures" id=3D"yui= _3_16_0_ym19_1_1463183424286_26555"><font size=3D"2" id=3D"yui_3_16_0_ym19_= 1_1463183424286_27114">Resource timeout: ()</font></span></div><div dir=3D"= ltr" id=3D"yui_3_16_0_ym19_1_1463183424286_26556"><span style=3D"font-varia= nt-ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_26= 557"><font size=3D"2"><br id=3D"yui_3_16_0_ym19_1_1463183424286_26558"></fo= nt></span></div><div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1463183424286_2655= 6"><span style=3D"font-variant-ligatures: no-common-ligatures"><font size= =3D"2"><br></font></span></div><div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_146= 3183424286_26556"><span style=3D"font-variant-ligatures: no-common-ligature= s"><font size=3D"2"><br></font></span></div><div dir=3D"ltr" id=3D"yui_3_16= _0_ym19_1_1463183424286_26556"><span style=3D"font-variant-ligatures: no-co= mmon-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_26626"><font size=3D"= 2" id=3D"yui_3_16_0_ym19_1_1463183424286_27106">With the "Storage pool" up = on Node2, I was able to start the hosted-engine.  But when I try to ac= tive the Master storage domain called 'infra'</font></span></div><div dir= =3D"ltr" id=3D"yui_3_16_0_ym19_1_1463183424286_26556"><span style=3D"font-v= ariant-ligatures: no-common-ligatures"><font size=3D"2"><br></font></span><= /div><div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1463183424286_26556"><div sty= le=3D"line-height: normal;" id=3D"yui_3_16_0_ym19_1_1463183424286_26737" di= r=3D"ltr"><font size=3D"2" id=3D"yui_3_16_0_ym19_1_1463183424286_27104">"Ho= st cannot access the Storage Domain(s) <UNKNOWN> attached to the Data= Center Default. Setting Host state to Non-Operational"</font></div><div st= yle=3D"line-height: normal;" id=3D"yui_3_16_0_ym19_1_1463183424286_26737" d= ir=3D"ltr"><font size=3D"2" id=3D"yui_3_16_0_ym19_1_1463183424286_27116">"F= ailed to connect Host to Storage Pool Default"</font></div><div style=3D"li= ne-height: normal;" id=3D"yui_3_16_0_ym19_1_1463183424286_26737" dir=3D"ltr= "><font size=3D"2"><br></font></div><div style=3D"line-height: normal;" id= =3D"yui_3_16_0_ym19_1_1463183424286_26737" dir=3D"ltr"><font size=3D"2" id= =3D"yui_3_16_0_ym19_1_1463183424286_27102">Tried again and I would get&nbsp= ;</font></div><div style=3D"line-height: normal;" id=3D"yui_3_16_0_ym19_1_1= 463183424286_26737" dir=3D"ltr"><font size=3D"2" id=3D"yui_3_16_0_ym19_1_14= 63183424286_27100">"Failed to activate Storage Domain infra (Data Center De= fault)"</font></div><div style=3D"line-height: normal;" id=3D"yui_3_16_0_ym= 19_1_1463183424286_26737" dir=3D"ltr"><font size=3D"2"><br></font></div><di= v style=3D"line-height: normal;" id=3D"yui_3_16_0_ym19_1_1463183424286_2673= 7" dir=3D"ltr"><font size=3D"2"><br></font></div><div style=3D"line-height:= normal;" id=3D"yui_3_16_0_ym19_1_1463183424286_26737" dir=3D"ltr"><font si= ze=3D"2">Thanks</font></div><div style=3D"line-height: normal;" id=3D"yui_3= _16_0_ym19_1_1463183424286_26737" dir=3D"ltr"><font size=3D"2" id=3D"yui_3_= 16_0_ym19_1_1463183424286_27099">W</font></div></div></div></div></div></bo= dy></html> ------=_Part_1857742_1292403466.1463201198840--

1 0

no network with matching name 'vdsm-ovirtmgmt'
by William Kwan 14 May '16

14 May '16

------=_Part_1779680_195441767.1463183776452 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable HI all, I have a problem with my 3.5 setup with hosted-engine. =C2=A0After reboot, = I can get things started. =C2=A0When i try to start vdsm manually, it says = "no network with matching name 'vdsm-ovirtmgmt' The bridge "ovirtmgmt" is up with underlying bond0 are good. =C2=A0I'm not = sure where to start. =C2=A0Can anyone shed some light on where to start to = fix this? =C2=A0Much appreciated. ThanksWill # /etc/init.d/vdsmd startinitctl: Job is already running: libvirtdvdsm: Run= ning mkdirsvdsm: Running configure_coredumpvdsm: Running configure_vdsm_log= svdsm: Running run_init_hooksvdsm: Running upgraded_version_checkvdsm: Runn= ing check_is_configuredlibvirt is already configured for vdsmvdsm: Running = validate_configurationSUCCESS: ssl configured to true. No conflictsvdsm: Ru= nning prepare_transient_repositoryvdsm: Running syslog_availablevdsm: Runni= ng nwfiltervdsm: Running dummybrvdsm: Running load_needed_modulesvdsm: Runn= ing tune_systemvdsm: Running test_spacevdsm: Running test_lovdsm: Running u= nified_network_persistence_upgradevdsm: Running restore_netslibvirt: Networ= k Driver error : Network not found: no network with matching name 'vdsm-ovi= rtmgmt'Traceback (most recent call last):=C2=A0 File "/usr/share/vdsm/vdsm-= restore-net-config", line 137, in <module>=C2=A0 =C2=A0 restore()=C2=A0 Fil= e "/usr/share/vdsm/vdsm-restore-net-config", line 123, in restore=C2=A0 =C2= =A0 unified_restoration()=C2=A0 File "/usr/share/vdsm/vdsm-restore-net-conf= ig", line 69, in unified_restoration=C2=A0 =C2=A0 setupNetworks(nets, bonds= , connectivityCheck=3DFalse, _inRollback=3DTrue)=C2=A0 File "/usr/share/vds= m/network/api.py", line 680, in setupNetworks=C2=A0 =C2=A0 implicitBonding= =3DTrue, _netinfo=3D_netinfo, **d)=C2=A0 File "/usr/share/vdsm/network/api.= py", line 226, in wrapped=C2=A0 =C2=A0 ret =3D func(**attrs)=C2=A0 File "/u= sr/share/vdsm/network/api.py", line 315, in addNetwork=C2=A0 =C2=A0 netEnt.= configure(**options)=C2=A0 File "/usr/share/vdsm/network/models.py", line 1= 69, in configure=C2=A0 =C2=A0 self.configurator.configureBridge(self, **opt= s)=C2=A0 File "/usr/share/vdsm/network/configurators/ifcfg.py", line 88, in= configureBridge=C2=A0 =C2=A0 ifup(bridge.name, bridge.ipConfig.async)=C2= =A0 File "/usr/share/vdsm/network/configurators/ifcfg.py", line 819, in ifu= p=C2=A0 =C2=A0 rc, out, err =3D _ifup(iface)=C2=A0 File "/usr/share/vdsm/ne= twork/configurators/ifcfg.py", line 808, in _ifup=C2=A0 =C2=A0 raise Config= NetworkError(ERR_FAILED_IFUP, out[-1] if out else '')network.errors.ConfigN= etworkError: (29, 'Determining IP information for DMZ... failed.')vdsm: sto= pped during execute restore_nets task (task returned with error code 1).vds= m start =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [FAILED] ------=_Part_1779680_195441767.1463183776452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body><div style=3D"color:#000; background-color:#fff; f= ont-family:Courier New, courier, monaco, monospace, sans-serif;font-size:13= px"><div id=3D"yui_3_16_0_ym19_1_1463183424286_3052">HI all,</div><div id= =3D"yui_3_16_0_ym19_1_1463183424286_3052"><br></div><div id=3D"yui_3_16_0_y= m19_1_1463183424286_3052" dir=3D"ltr">I have a problem with my 3.5 setup wi= th hosted-engine.  After reboot, I can get things started.  When = i try to start vdsm manually, it says "<span style=3D"font-family: Menlo; f= ont-size: 12px;" id=3D"yui_3_16_0_ym19_1_1463183424286_3161">no network wit= h matching name 'vdsm-ovirtmgmt'</span></div><div id=3D"yui_3_16_0_ym19_1_1= 463183424286_3052" dir=3D"ltr"><span style=3D"font-family: Menlo; font-size= : 12px;"><br></span></div><div id=3D"yui_3_16_0_ym19_1_1463183424286_3052" = dir=3D"ltr"><span style=3D"font-family: Menlo; font-size: 12px;" id=3D"yui_= 3_16_0_ym19_1_1463183424286_3500">The bridge "ovirtmgmt" is up with underly= ing bond0 are good.  I'm not sure where to start.  Can anyone she= d some light on where to start to fix this?  Much appreciated.</span><= /div><div id=3D"yui_3_16_0_ym19_1_1463183424286_3052" dir=3D"ltr"><span sty= le=3D"font-family: Menlo; font-size: 12px;"><br></span></div><div id=3D"yui= _3_16_0_ym19_1_1463183424286_3052" dir=3D"ltr"><span style=3D"font-family: = Menlo; font-size: 12px;" id=3D"yui_3_16_0_ym19_1_1463183424286_3501">Thanks= </span></div><div id=3D"yui_3_16_0_ym19_1_1463183424286_3052" dir=3D"ltr"><= span style=3D"font-family: Menlo; font-size: 12px;" id=3D"yui_3_16_0_ym19_1= _1463183424286_3522">Will</span></div><div id=3D"yui_3_16_0_ym19_1_14631834= 24286_3052" dir=3D"ltr"><br></div><div style=3D"margin-top: 0px; margin-bot= tom: 0px; font-size: 12px; line-height: normal; font-family: Menlo;" id=3D"= yui_3_16_0_ym19_1_1463183424286_3400"><span style=3D"font-variant-ligatures= : no-common-ligatures;" id=3D"yui_3_16_0_ym19_1_1463183424286_3401"># /etc/= init.d/vdsmd start</span></div><div style=3D"margin-top: 0px; margin-bottom= : 0px; font-size: 12px; line-height: normal; font-family: Menlo;" id=3D"yui= _3_16_0_ym19_1_1463183424286_3402"><span style=3D"font-variant-ligatures: n= o-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3403">initctl: Jo= b is already running: libvirtd</span></div><div style=3D"margin-top: 0px; m= argin-bottom: 0px; font-size: 12px; line-height: normal; font-family: Menlo= ;" id=3D"yui_3_16_0_ym19_1_1463183424286_3404"><span style=3D"font-variant-= ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3405"= >vdsm: Running mkdirs</span></div><div style=3D"margin-top: 0px; margin-bot= tom: 0px; font-size: 12px; line-height: normal; font-family: Menlo;" id=3D"= yui_3_16_0_ym19_1_1463183424286_3406"><span style=3D"font-variant-ligatures= : no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3407">vdsm: Ru= nning configure_coredump</span></div><div style=3D"margin-top: 0px; margin-= bottom: 0px; font-size: 12px; line-height: normal; font-family: Menlo;" id= =3D"yui_3_16_0_ym19_1_1463183424286_3408"><span style=3D"font-variant-ligat= ures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3409">vdsm= : Running configure_vdsm_logs</span></div><div style=3D"margin-top: 0px; ma= rgin-bottom: 0px; font-size: 12px; line-height: normal; font-family: Menlo;= " id=3D"yui_3_16_0_ym19_1_1463183424286_3410"><span style=3D"font-variant-l= igatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3411">= vdsm: Running run_init_hooks</span></div><div style=3D"margin-top: 0px; mar= gin-bottom: 0px; font-size: 12px; line-height: normal; font-family: Menlo;"= id=3D"yui_3_16_0_ym19_1_1463183424286_3412"><span style=3D"font-variant-li= gatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3413">v= dsm: Running upgraded_version_check</span></div><div style=3D"margin-top: 0= px; margin-bottom: 0px; font-size: 12px; line-height: normal; font-family: = Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_3414"><span style=3D"font-var= iant-ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_= 3415">vdsm: Running check_is_configured</span></div><div style=3D"margin-to= p: 0px; margin-bottom: 0px; font-size: 12px; line-height: normal; font-fami= ly: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_3416"><span style=3D"font= -variant-ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424= 286_3417">libvirt is already configured for vdsm</span></div><div style=3D"= margin-top: 0px; margin-bottom: 0px; font-size: 12px; line-height: normal; = font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_3418"><span styl= e=3D"font-variant-ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1= 463183424286_3419">vdsm: Running validate_configuration</span></div><div st= yle=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px; line-height: n= ormal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_3420"><sp= an style=3D"font-variant-ligatures: no-common-ligatures" id=3D"yui_3_16_0_y= m19_1_1463183424286_3421">SUCCESS: ssl configured to true. No conflicts</sp= an></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px= ; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183= 424286_3422"><span style=3D"font-variant-ligatures: no-common-ligatures" id= =3D"yui_3_16_0_ym19_1_1463183424286_3423">vdsm: Running prepare_transient_r= epository</span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; fo= nt-size: 12px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_y= m19_1_1463183424286_3424"><span style=3D"font-variant-ligatures: no-common-= ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3425">vdsm: Running syslog= _available</span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; f= ont-size: 12px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_= ym19_1_1463183424286_3426"><span style=3D"font-variant-ligatures: no-common= -ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3427">vdsm: Running nwfil= ter</span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-siz= e: 12px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_= 1463183424286_3428"><span style=3D"font-variant-ligatures: no-common-ligatu= res" id=3D"yui_3_16_0_ym19_1_1463183424286_3429">vdsm: Running dummybr</spa= n></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px;= line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_14631834= 24286_3430"><span style=3D"font-variant-ligatures: no-common-ligatures" id= =3D"yui_3_16_0_ym19_1_1463183424286_3431">vdsm: Running load_needed_modules= </span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: = 12px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_146= 3183424286_3432"><span style=3D"font-variant-ligatures: no-common-ligatures= " id=3D"yui_3_16_0_ym19_1_1463183424286_3433">vdsm: Running tune_system</sp= an></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px= ; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183= 424286_3434"><span style=3D"font-variant-ligatures: no-common-ligatures" id= =3D"yui_3_16_0_ym19_1_1463183424286_3435">vdsm: Running test_space</span></= div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px; lin= e-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_146318342428= 6_3436"><span style=3D"font-variant-ligatures: no-common-ligatures" id=3D"y= ui_3_16_0_ym19_1_1463183424286_3437">vdsm: Running test_lo</span></div><div= style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px; line-height= : normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_3438">= <span style=3D"font-variant-ligatures: no-common-ligatures" id=3D"yui_3_16_= 0_ym19_1_1463183424286_3439">vdsm: Running unified_network_persistence_upgr= ade</span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-siz= e: 12px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_= 1463183424286_3440"><span style=3D"font-variant-ligatures: no-common-ligatu= res" id=3D"yui_3_16_0_ym19_1_1463183424286_3441">vdsm: Running restore_nets= </span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: = 12px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_146= 3183424286_3442"><span style=3D"font-variant-ligatures: no-common-ligatures= " id=3D"yui_3_16_0_ym19_1_1463183424286_3443">libvirt: Network Driver error= : Network not found: no network with matching name 'vdsm-ovirtmgmt'</span>= </div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px; l= ine-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424= 286_3444"><span style=3D"font-variant-ligatures: no-common-ligatures" id=3D= "yui_3_16_0_ym19_1_1463183424286_3445">Traceback (most recent call last):</= span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12= px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_14631= 83424286_3446"><span style=3D"font-variant-ligatures: no-common-ligatures" = id=3D"yui_3_16_0_ym19_1_1463183424286_3447">  File "/usr/share/vdsm/vd= sm-restore-net-config", line 137, in <module></span></div><div style= =3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px; line-height: norm= al; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_3448"><span = style=3D"font-variant-ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym19= _1_1463183424286_3449">    restore()</span></div><div style=3D"ma= rgin-top: 0px; margin-bottom: 0px; font-size: 12px; line-height: normal; fo= nt-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_3450"><span style= =3D"font-variant-ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_14= 63183424286_3451">  File "/usr/share/vdsm/vdsm-restore-net-config", li= ne 123, in restore</span></div><div style=3D"margin-top: 0px; margin-bottom= : 0px; font-size: 12px; line-height: normal; font-family: Menlo;" id=3D"yui= _3_16_0_ym19_1_1463183424286_3452"><span style=3D"font-variant-ligatures: n= o-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3453">  &nbs= p; unified_restoration()</span></div><div style=3D"margin-top: 0px; margin-= bottom: 0px; font-size: 12px; line-height: normal; font-family: Menlo;" id= =3D"yui_3_16_0_ym19_1_1463183424286_3454"><span style=3D"font-variant-ligat= ures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3455">&nbs= p; File "/usr/share/vdsm/vdsm-restore-net-config", line 69, in unified_rest= oration</span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font= -size: 12px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym1= 9_1_1463183424286_3456"><span style=3D"font-variant-ligatures: no-common-li= gatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3457">    setupNet= works(nets, bonds, connectivityCheck=3DFalse, _inRollback=3DTrue)</span></d= iv><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px; line= -height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286= _3458"><span style=3D"font-variant-ligatures: no-common-ligatures" id=3D"yu= i_3_16_0_ym19_1_1463183424286_3459">  File "/usr/share/vdsm/network/ap= i.py", line 680, in setupNetworks</span></div><div style=3D"margin-top: 0px= ; margin-bottom: 0px; font-size: 12px; line-height: normal; font-family: Me= nlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_3460"><span style=3D"font-varia= nt-ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_34= 61">    implicitBonding=3DTrue, _netinfo=3D_netinfo, **d)</span><= /div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px; li= ne-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_14631834242= 86_3462"><span style=3D"font-variant-ligatures: no-common-ligatures" id=3D"= yui_3_16_0_ym19_1_1463183424286_3463">  File "/usr/share/vdsm/network/= api.py", line 226, in wrapped</span></div><div style=3D"margin-top: 0px; ma= rgin-bottom: 0px; font-size: 12px; line-height: normal; font-family: Menlo;= " id=3D"yui_3_16_0_ym19_1_1463183424286_3464"><span style=3D"font-variant-l= igatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3465">=     ret =3D func(**attrs)</span></div><div style=3D"margin-top: 0= px; margin-bottom: 0px; font-size: 12px; line-height: normal; font-family: = Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_3466"><span style=3D"font-var= iant-ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_= 3467">  File "/usr/share/vdsm/network/api.py", line 315, in addNetwork= </span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: = 12px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_146= 3183424286_3468"><span style=3D"font-variant-ligatures: no-common-ligatures= " id=3D"yui_3_16_0_ym19_1_1463183424286_3469">    netEnt.configur= e(**options)</span></div><div style=3D"margin-top: 0px; margin-bottom: 0px;= font-size: 12px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_= 0_ym19_1_1463183424286_3470"><span style=3D"font-variant-ligatures: no-comm= on-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3471">  File "/usr= /share/vdsm/network/models.py", line 169, in configure</span></div><div sty= le=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px; line-height: no= rmal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_3472"><spa= n style=3D"font-variant-ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym= 19_1_1463183424286_3473">    self.configurator.configureBridge(se= lf, **opts)</span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; = font-size: 12px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0= _ym19_1_1463183424286_3474"><span style=3D"font-variant-ligatures: no-commo= n-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3475">  File "/usr/= share/vdsm/network/configurators/ifcfg.py", line 88, in configureBridge</sp= an></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px= ; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183= 424286_3476"><span style=3D"font-variant-ligatures: no-common-ligatures" id= =3D"yui_3_16_0_ym19_1_1463183424286_3477">    ifup(bridge.name, b= ridge.ipConfig.async)</span></div><div style=3D"margin-top: 0px; margin-bot= tom: 0px; font-size: 12px; line-height: normal; font-family: Menlo;" id=3D"= yui_3_16_0_ym19_1_1463183424286_3478"><span style=3D"font-variant-ligatures= : no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3479">  F= ile "/usr/share/vdsm/network/configurators/ifcfg.py", line 819, in ifup</sp= an></div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px= ; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183= 424286_3480"><span style=3D"font-variant-ligatures: no-common-ligatures" id= =3D"yui_3_16_0_ym19_1_1463183424286_3481">    rc, out, err =3D _i= fup(iface)</span></div><div style=3D"margin-top: 0px; margin-bottom: 0px; f= ont-size: 12px; line-height: normal; font-family: Menlo;" id=3D"yui_3_16_0_= ym19_1_1463183424286_3482"><span style=3D"font-variant-ligatures: no-common= -ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3483">  File "/usr/s= hare/vdsm/network/configurators/ifcfg.py", line 808, in _ifup</span></div><= div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px; line-hei= ght: normal; font-family: Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_348= 4"><span style=3D"font-variant-ligatures: no-common-ligatures" id=3D"yui_3_= 16_0_ym19_1_1463183424286_3485">    raise ConfigNetworkError(ERR_= FAILED_IFUP, out[-1] if out else '')</span></div><div style=3D"margin-top: = 0px; margin-bottom: 0px; font-size: 12px; line-height: normal; font-family:= Menlo;" id=3D"yui_3_16_0_ym19_1_1463183424286_3486"><span style=3D"font-va= riant-ligatures: no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286= _3487">network.errors.ConfigNetworkError: (29, 'Determining IP information = for DMZ... failed.')</span></div><div style=3D"margin-top: 0px; margin-bott= om: 0px; font-size: 12px; line-height: normal; font-family: Menlo;" id=3D"y= ui_3_16_0_ym19_1_1463183424286_3488"><span style=3D"font-variant-ligatures:= no-common-ligatures" id=3D"yui_3_16_0_ym19_1_1463183424286_3489">vdsm: sto= pped during execute restore_nets task (task returned with error code 1).</s= pan></div><div id=3D"yui_3_16_0_ym19_1_1463183424286_3052" dir=3D"ltr"> </div><div style=3D"margin-top: 0px; margin-bottom: 0px; font-size: 12px; l= ine-height: normal; font-family: Menlo;" dir=3D"ltr" id=3D"yui_3_16_0_ym19_= 1_1463183424286_3490"><span style=3D"font-variant-ligatures: no-common-liga= tures;" id=3D"yui_3_16_0_ym19_1_1463183424286_3491">vdsm start   &nbsp= ;                     &nb= sp;                     &= nbsp; [</span><span style=3D"font-variant-ligatures: no-common-ligatures;" = id=3D"yui_3_16_0_ym19_1_1463183424286_3492">FAILED</span><span style=3D"fon= t-variant-ligatures: no-common-ligatures;" id=3D"yui_3_16_0_ym19_1_14631834= 24286_3493">]</span></div></div></body></html> ------=_Part_1779680_195441767.1463183776452--

1 2

Hosted Engine Appliance hostname causing issues in production environment
by Langley, Robert 14 May '16

14 May '16

--_000_BY1PR09MB082435A552E5222B006CC6ED87730BY1PR09MB0824namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello; I discovered, the hard way, that the appliance is configured with the hostn= ame of localhost.localdomain.localdomain It seems that something did not go well with the hosted-engine -deploy I can go into the engine VM and edit the hostname, but if for any reason I = need to poweroff the engine VM, I get in trouble. Because, then the hostnam= e goes back to localhost.localdomain.localdomain and both DHCP & DNS within= our enterprise/production environment ends up assuming that for the hostna= me to IP address reference or record. And it seems that other linux systems= (not the ones I administer; none of my almost 50 systems are effected. Of = those, I have about 5 linux/UNIX based systems attached to the production n= etwork) are going offline because of this. I assume they do not have their HOSTS file configured correctly, but they (= the other administrators) are not listening to me. I have already told them= what to look for, in order to fix the issue on their own systems, but they= 've ended up with this now for the third time. This is because I work for a local government and we have various administr= ators for the various agencies within our County government. I have unplugged my initial physical host from our County network and I thi= nk I'm going to end up bringing up a physical engine host, then work on con= verting that to a VM for a hosted engine. I hope that is going to work. I t= ried bringing up the OVA of the appliance within VirtualBox, but that doesn= 't work. Is there another virtual software I can bring up within a Windows = PC to simply edit the hostname, then export the appliance again? I think the appliance for download needs to be changed to have something ot= her than "localhost.localdomain.localdomain" as the hostname in the hosted-= engine appliance. I downloaded the OVA file from the Jenkins.ovirt.org site= . Sincerely, -Robert --_000_BY1PR09MB082435A552E5222B006CC6ED87730BY1PR09MB0824namp_ 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-micr= osoft-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=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Hello;<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I discovered, the hard way, that the appliance is co= nfigured with the hostname of localhost.localdomain.localdomain<o:p></o:p><= /p> <p class=3D"MsoNormal">It seems that something did not go well with the hos= ted-engine –deploy<o:p></o:p></p> <p class=3D"MsoNormal">I can go into the engine VM and edit the hostname, b= ut if for any reason I need to poweroff the engine VM, I get in trouble. Be= cause, then the hostname goes back to localhost.localdomain.localdomain and= both DHCP & DNS within our enterprise/production environment ends up assuming that for the hostname to IP address reference= or record. And it seems that other linux systems (not the ones I administe= r; none of my almost 50 systems are effected. Of those, I have about 5 linu= x/UNIX based systems attached to the production network) are going offline because of this.<o:p></o:p></p> <p class=3D"MsoNormal">I assume they do not have their HOSTS file configure= d correctly, but they (the other administrators) are not listening to me. I= have already told them what to look for, in order to fix the issue on thei= r own systems, but they’ve ended up with this now for the third time.<o:p></o:p></p> <p class=3D"MsoNormal">This is because I work for a local government and we= have various administrators for the various agencies within our County gov= ernment.<o:p></o:p></p> <p class=3D"MsoNormal">I have unplugged my initial physical host from our C= ounty network and I think I’m going to end up bringing up a physical = engine host, then work on converting that to a VM for a hosted engine. I ho= pe that is going to work. I tried bringing up the OVA of the appliance within VirtualBox, but that doesn’t work= . Is there another virtual software I can bring up within a Windows PC to s= imply edit the hostname, then export the appliance again?<o:p></o:p></p> <p class=3D"MsoNormal">I think the appliance for download needs to be chang= ed to have something other than “localhost.localdomain.localdomain&#8= 221; as the hostname in the hosted-engine appliance. I downloaded the OVA f= ile from the Jenkins.ovirt.org site.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Sincerely,<o:p></o:p></p> <p class=3D"MsoNormal">-Robert<o:p></o:p></p> </div> </body> </html> --_000_BY1PR09MB082435A552E5222B006CC6ED87730BY1PR09MB0824namp_--

2 2

creation of lun disks
by Fabrice Bacchella 14 May '16

14 May '16

--Apple-Mail=_86495AA0-19B5-42EB-9515-670209434AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm trying to generated a lun disk, using the python SDK. My code can be found at = https://github.com/fbacchella/ovirtcmd/blob/master/ovlib/disks/__init__.py= If a try to see the content of a existing disk and test with : print disk.get_type() print disk.get_storage_type() I'm getting : None lun Now I try to create another LUN disk with kwargs['storage_type'] =3D 'lun' kwargs['type_'] =3D 'system' I'm getting: > POST /api/disks HTTP/1.1 > <disk> > <type>system</type> > <interface>virtio-scsi</interface> > <lun_storage> > <logical_unit id=3D"3600c0ff00026285aed8f355701000000"/> > </lun_storage> > <storage_type>lun</storage_type> > </disk> ... < <fault> < <reason>Incomplete parameters</reason> < <detail>Storage [type] required for invoke0</detail> < </fault> changing to=20 kwargs['type_'] =3D None=20 change nothing, I'm still getting the same error message. > POST /api/disks HTTP/1.1 > <disk> > <interface>virtio-scsi</interface> > <lun_storage> > <logical_unit id=3D"3600c0ff00026285aed8f355701000000"/> > </lun_storage> > <storage_type>lun</storage_type> > </disk> ... < <fault> < <reason>Incomplete parameters</reason> < <detail>Storage [type] required for invoke0</detail> < </fault> What did I do wrong ? There is nothing about that in the logs --Apple-Mail=_86495AA0-19B5-42EB-9515-670209434AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space;" class=3D"">I'm trying to = generated a lun disk, using the python SDK.<br class=3D""><br = class=3D"">My code can be found at <a = href=3D"https://github.com/fbacchella/ovirtcmd/blob/master/ovlib/disks/__i= nit__.py" = class=3D"">https://github.com/fbacchella/ovirtcmd/blob/master/ovlib/disks/= __init__.py</a><br class=3D""><br class=3D"">If a try to see the content = of a existing disk and test with :<br = class=3D"">print disk.get_type()<br = class=3D"">print disk.get_storage_type()<br class=3D""><br = class=3D"">I'm getting :<br class=3D"">None<br class=3D"">lun<br = class=3D""><br class=3D"">Now I try to create another LUN disk with<br = class=3D"">kwargs['storage_type'] =3D 'lun'<br = class=3D"">kwargs['type_'] =3D 'system'<br class=3D""><br = class=3D"">I'm getting:<div class=3D""><br class=3D""><font face=3D"Menlo"= class=3D"">> POST /api/disks HTTP/1.1<br class=3D"">> = <disk><br class=3D"">>   =   <type>system</type><br class=3D"">>  =   <interface>virtio-scsi</interface><br = class=3D"">>     <lun_storage><br = class=3D"">>         <logical_unit = id=3D"3600c0ff00026285aed8f355701000000"/><br = class=3D"">>     </lun_storage><br = class=3D"">>   =   <storage_type>lun</storage_type><br = class=3D"">> </disk><br class=3D"">...<br class=3D"">< = <fault><br class=3D""><   =   <reason>Incomplete parameters</reason><br = class=3D""><     <detail>Storage [type] = required for invoke0</detail><br class=3D"">< </fault><br = class=3D""></font><div class=3D""><br class=3D""></div><div = class=3D"">changing to </div><div class=3D""><font face=3D"Menlo" = class=3D"">    kwargs['type_'] =3D None </font></div><div = class=3D"">change nothing, I'm still getting the same error = message.</div><div class=3D""><br class=3D""></div><font face=3D"Menlo" = class=3D"">> POST /api/disks HTTP/1.1<br class=3D"">> = <disk><br class=3D"">>   =   <interface>virtio-scsi</interface><br = class=3D"">>     <lun_storage><br = class=3D"">>         <logical_unit = id=3D"3600c0ff00026285aed8f355701000000"/><br = class=3D"">>     </lun_storage><br = class=3D"">>   =   <storage_type>lun</storage_type><br = class=3D"">> </disk><br class=3D"">...<br class=3D"">< = <fault><br class=3D""><   =   <reason>Incomplete parameters</reason><br = class=3D""><     <detail>Storage [type] = required for invoke0</detail><br class=3D"">< </fault><br = class=3D""><br class=3D""></font><div class=3D""><br class=3D""></div><div= class=3D""> What did I do wrong ? There is nothing about that in = the logs</div><br class=3D"Apple-interchange-newline"><br class=3D""><br = class=3D""><br class=3D""></div></body></html>= --Apple-Mail=_86495AA0-19B5-42EB-9515-670209434AA3--

2 2

Problem remove snapshot
by Marcelo Leandro 13 May '16

13 May '16

hello, i have problem for delete one snapshot. i see the error: Due to partial snapshot removal, Snapshot 'Backup the VM' of VM 'vmname' now contains only the following disks: 'vmdiskname'. Failed to delete snapshot 'Backup the VM' for VM 'vmname'. information in db : imagestatus | storage_pool_id | storage_domain_id | image_group_id | im age_guid | parentid -------------+--------------------------------------+--------------------------------------+--------------------------------------+---------------- ----------------------+-------------------------------------- 1 | 77e24b20-9d21-4952-a089-3c5c592b4e6d | 6e5cce71-3438-4045-9d54-607123e0557e | bfb1e6b5-7a06-41e4-b8b4-2e237ed0c7ab | 1bb7bd08-5ee8-4 a3b-8978-c15e15d1c5e4 | 6008671c-2f9d-48de-94f3-cc7d6273de31 4 | 77e24b20-9d21-4952-a089-3c5c592b4e6d | 6e5cce71-3438-4045-9d54-607123e0557e | bfb1e6b5-7a06-41e4-b8b4-2e237ed0c7ab | 6008671c-2f9d-4 8de-94f3-cc7d6273de31 | 00000000-0000-0000-0000-000000000000 output the script vm-disk-info.py Disk bfb1e6b5-7a06-41e4-b8b4-2e237ed0c7ab (sd:6e5cce71-3438-4045-9d54-607123e0557e) Warning: volume 1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4 is in chain but illegal Volumes: 6008671c-2f9d-48de-94f3-cc7d6273de31 1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4 output the command md5sum : volume : 1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4 4c05c8258ed5746da6ac2cdb80c8974e 1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4 ec74d4d8189a5ea24720349868ff7ab7 1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4 the volume change output the command md5sum : volume: 6008671c-2f9d-48de-94f3-cc7d6273de31 86daf229ad0b65fb8be3a3de6b0ee840 6008671c-2f9d-48de-94f3-cc7d6273de31 86daf229ad0b65fb8be3a3de6b0ee840 6008671c-2f9d-48de-94f3-cc7d6273de31 the volume not change Thanks.

2 5

Trying to understand the mixed storage configuration options.
by Jason Ziemba 13 May '16

13 May '16

I'm fairly new to oVirt (coming from ProxMox) and trying to wrap my head around the mixed (local/NAS) data domain options that are available. I'm trying to configure a set of systems to have local storage, as their primary data storage domain, though also want to have the ability to have a NAS based data domain for guests that are 'mobile' between hosts. Currently I'm able to do one or the other, but not both (so it seems). When I put all of the systems in to a single cluster (or single data-center) I'm able to have the shared data domain, though have only found the ability to configure one system for local storage (not all of them). When I split them out in to separate data centers, they all have their local data domain working, but only a single dc is able to access the shared data domain at a time. Am I missing something along the way (probably fairly obvious) that does exactly what I'm outlining, or is this functionality not available by design? Any assistance/guidance is greatly appreciated.

4 5

[moVirt] Add several datacenters
by Nicolas Ecarnot 13 May '16

13 May '16

Hello, I finally was able to correctly connect to one of our DC with moVirt, so I can show off and it is so cool. But I find no way to add several datacenters. May someone help please? -- Nicolas ECARNOT

2 1

Changing of master storage domain
by Roman A. Chukov 13 May '16

13 May '16

Hello there, I have a question about the algorithm of changing of master storage domain. I have a fresh installation of oVirt 3.6 on 2 hardware nodes, using a number of NFS shares as storage domains, and one of them was a master. When I was adding the second node into cluster, master storage domain had been changed by oVirt. Actually it didn't bring any harmful consequences at that point but it was unexpected for me. So, could anybody please explain such behavior of oVirt and also explain whether I could change master storage domain back to the previous? -- Thanks in advance, Roman Chukov.

3 4

Failed to migrate a VMware through virt-v2v included in oVirt 3.6
by Julián Tete 13 May '16

13 May '16

My oVirt DataCenter Cluster CPU Type: Intel SandyBridge Family Emulated Machine: pc-i440fx-rhel7.2.0

3 7

volume_utilization_chunk_mb not working
by Grundmann, Christian 13 May '16

13 May '16

--_000_6A17C71B52524C408E7AAF69103E9E490F72FF7Cfabamailserverf_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I create a lot of Thin Disk VMs from templates every day, and get "paused d= ue to no storage space error" and "paused due to unknown storage error" on = a few of them. Sometimes the VMs are resumed a few seconds later but sometime not, but I c= an resume them myself. I tried to set volume_utilization_percent=3D15 volume_utilization_chunk_mb=3D4048 in /etc/vdsm/vdsm.conf on every Host But the Initial Size of the Disk is always 1GB and then increments to 2GB 4GB would be the maximum Size I need before I destroy the VM. So if the ini= tial Size would be 4GB the pausing shouldn't happen anymore Thx a lot for your help Christian --_000_6A17C71B52524C408E7AAF69103E9E490F72FF7Cfabamailserverf_ 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-micr= osoft-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=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"DE-AT" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hi<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">I create a lot of Thin Disk VMs= from templates every day, and get „paused due to no storage space er= ror“ and „paused due to unknown storage error“ on a few o= f them.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Sometimes the VMs are resumed a= few seconds later but sometime not, but I can resume them myself.<o:p></o:= p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">I tried to set<o:p></o:p></span= ></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">volume_utilization_percent=3D15= <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">volume_utilization_chunk_mb=3D4= 048<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">in /etc/vdsm/vdsm.conf on every= Host<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">But the Initial Size of the Dis= k is always 1GB and then increments to 2GB<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">4GB would be the maximum Size I= need before I destroy the VM. So if the initial Size would be 4GB the paus= ing shouldn’t happen anymore<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Thx a lot for your help<o:p></o= :p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Christian<o:p></o:p></span></p> </div> </body> </html> --_000_6A17C71B52524C408E7AAF69103E9E490F72FF7Cfabamailserverf_--

2 7

oVirt 4.0 hosted-engine deploy exits without messages or logs
by Gianluca Cecchi 13 May '16

13 May '16

Hello, trying to have an insight at 4.0 alpha1, using CentOS 7.2 and hosted engine. Installed packages after configuring repo at http://plain.resources.ovirt.org/pub/ovirt-4.0_alpha1/rpm/el7/noarch/ovirt-… are ovirt-hosted-engine-setup-2.0.0-0.0.master.20160325145108.gita9a3495.el7.centos.noarch ovirt-engine-appliance-4.0-20160405.1.el7.centos.noarch otopi-1.5.0-0.0.master.20160403070351.gitfa92bb0.el7.noarch but [root@ovirtita ~]# hosted-engine --deploy [root@ovirtita ~]# echo $? 1 [root@ovirtita ~]# ls /var/log anaconda chrony dmesg.old libvirt ovirt-hosted-engine-ha secure vdsm audit core glusterfs maillog ovirt-hosted-engine-setup spooler wpa_supplicant.log boot.log cron grubby messages ppp tallylog wtmp btmp dmesg lastlog ntpstats sa tuned yum.log [root@ovirtita ~]# ls /var/log/ovirt-hosted-engine-* /var/log/ovirt-hosted-engine-ha: /var/log/ovirt-hosted-engine-setup: [root@ovirtita ~]# [root@ovirtita log]# ll /var/log/vdsm/ total 0 drwxr-xr-x. 2 vdsm kvm 6 Apr 4 19:15 backup -rw-r--r--. 1 vdsm kvm 0 May 12 14:29 connectivity.log -rw-r--r--. 1 vdsm kvm 0 May 12 14:29 mom.log -rw-r--r--. 1 root root 0 May 12 14:29 supervdsm.log -rw-r--r--. 1 vdsm kvm 0 May 12 14:29 vdsm.log [root@ovirtita log]# ll /var/log/vdsm/backup/ total 0 [root@ovirtita log]# ?

2 2

Re: [ovirt-users] vms in paused state
by Michal Skrivanek 13 May '16

13 May '16

--Apple-Mail=_FC29514C-FC8B-44E8-A9D8-B78C0939837D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Apr 2016, at 19:40, Bill James <bill.james(a)j2.com> wrote: >=20 > thank you for response. > I bold-ed the ones that are listed as "paused". >=20 >=20 > [root@ovirt1 test vdsm]# virsh -r list --all > Id Name State > ---------------------------------------------------- > 2 puppet.test.j2noc.com running > 4 sftp2.test.j2noc.com running > 5 oct.test.j2noc.com running > 6 sftp2.dev.j2noc.com running > 10 darmaster1.test.j2noc.com running > 14 api1.test.j2noc.com running > 25 ftp1.frb.test.j2noc.com running > 26 auto7.test.j2noc.com running > 32 epaymv02.j2noc.com running > 34 media2.frb.test.j2noc.com running > 36 auto2.j2noc.com running > 44 nfs.testhvy2.colo.j2noc.com running > 53 billapp-zuma1.dev.j2noc.com running > 54 billing-ci.dev.j2noc.com running > 60 log2.test.j2noc.com running > 63 log1.test.j2noc.com running > 69 sonar.dev.j2noc.com running > 73 billapp-ui1.dev.j2noc.com running > 74 billappvm01.dev.j2noc.com running > 75 db2.frb.test.j2noc.com running > 83 billapp-ui1.test.j2noc.com running > 84 epayvm01.test.j2noc.com running > 87 billappvm01.test.j2noc.com running > 89 etapi1.test.j2noc.com running > 93 billapp-zuma2.test.j2noc.com running > 94 git.dev.j2noc.com running >=20 > Yes I did "systemctl restart libvirtd" which apparently also restart = vdsm? yes, it does.=20 >=20 >=20 > Looks like problem started around 2016-04-17 20:19:34,822, based on = engine.log attached. yes, that time looks correct. Any idea what might have been a trigger? = Anything interesting happened at that time (power outage of some host, = some maintenance action, anything)?=20 logs indicate a problem when vdsm talks to libvirt(all those "monitor = become unresponsive=E2=80=9D) It does seem that at that time you started to have some storage = connectivity issues - first one at 2016-04-17 20:06:53,929. And it = doesn=E2=80=99t look temporary because such errors are still there = couple hours later(in your most recent file you attached I can see at = 23:00:54) When I/O gets blocked the VMs may experience issues (then VM gets = Paused), or their qemu process gets stuck(resulting in libvirt either = reporting error or getting stuck as well -> resulting in what vdsm sees = as =E2=80=9Cmonitor unresponsive=E2=80=9D) Since you now bounced libvirtd - did it help? Do you still see wrong = status for those VMs and still those "monitor unresponsive" errors in = vdsm.log? If not=E2=80=A6then I would suspect the =E2=80=9Cvm recovery=E2=80=9D = code not working correctly. Milan is looking at that. Thanks, michal > There's a lot of vdsm logs! >=20 > fyi, the storage domain for these Vms is a "local" nfs share, = 7e566f55-e060-47b7-bfa4-ac3c48d70dda. >=20 > attached more logs. >=20 >=20 > On 04/28/2016 12:53 AM, Michal Skrivanek wrote: >>> On 27 Apr 2016, at 19:16, Bill James <bill.james(a)j2.com> = <mailto:bill.james@j2.com> wrote: >>>=20 >>> virsh # list --all >>> error: failed to connect to the hypervisor >>> error: no valid connection >>> error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': = No such file or directory >>>=20 >> you need to run virsh in read-only mode >> virsh -r list =E2=80=94all >>=20 >>> [root@ovirt1 test vdsm]# systemctl status libvirtd >>> =E2=97=8F libvirtd.service - Virtualization daemon >>> Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; = vendor preset: enabled) >>> Drop-In: /etc/systemd/system/libvirtd.service.d >>> =E2=94=94=E2=94=80unlimited-core.conf >>> Active: active (running) since Thu 2016-04-21 16:00:03 PDT; 5 days = ago >>>=20 >>>=20 >>> tried systemctl restart libvirtd. >>> No change. >>>=20 >>> Attached vdsm.log and supervdsm.log. >>>=20 >>>=20 >>> [root@ovirt1 test vdsm]# systemctl status vdsmd >>> =E2=97=8F vdsmd.service - Virtual Desktop Server Manager >>> Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; = vendor preset: enabled) >>> Active: active (running) since Wed 2016-04-27 10:09:14 PDT; 3min = 46s ago >>>=20 >>>=20 >>> vdsm-4.17.18-0.el7.centos.noarch >> the vdsm.log attach is good, but it=E2=80=99s too short interval, it = only shows recovery(vdsm restart) phase when the VMs are identified as = paused=E2=80=A6.can you add earlier logs? Did you restart vdsm yourself = or did it crash? >>=20 >>=20 >>> libvirt-daemon-1.2.17-13.el7_2.4.x86_64 >>>=20 >>>=20 >>> Thanks. >>>=20 >>>=20 >>> On 04/26/2016 11:35 PM, Michal Skrivanek wrote: >>>>> On 27 Apr 2016, at 02:04, Nir Soffer <nsoffer(a)redhat.com> = <mailto:nsoffer@redhat.com> wrote: >>>>>=20 >>>>> jjOn Wed, Apr 27, 2016 at 2:03 AM, Bill James <bill.james(a)j2.com> = <mailto:bill.james@j2.com> wrote: >>>>>> I have a hardware node that has 26 VMs. >>>>>> 9 are listed as "running", 17 are listed as "paused". >>>>>>=20 >>>>>> In truth all VMs are up and running fine. >>>>>>=20 >>>>>> I tried telling the db they are up: >>>>>>=20 >>>>>> engine=3D> update vm_dynamic set status =3D 1 where vm_guid = =3D(select >>>>>> vm_guid from vm_static where vm_name =3D 'api1.test.j2noc.com'); >>>>>>=20 >>>>>> GUI then shows it up for a short while, >>>>>>=20 >>>>>> then puts it back in paused state. >>>>>>=20 >>>>>> 2016-04-26 15:16:46,095 INFO = [org.ovirt.engine.core.vdsbroker.VmAnalyzer] >>>>>> (DefaultQuartzScheduler_Worker-16) [157cc21e] VM = '242ca0af-4ab2-4dd6-b515-5 >>>>>> d435e6452c4'(api1.test.j2noc.com) moved from 'Up' --> 'Paused' >>>>>> 2016-04-26 15:16:46,221 INFO = [org.ovirt.engine.core.dal.dbbroker.auditlogh >>>>>> andling.AuditLogDirector] (DefaultQuartzScheduler_Worker-16) = [157cc21e] Cor >>>>>> relation ID: null, Call Stack: null, Custom Event ID: -1, = Message: VM api1. >>>>>> test.j2noc.com has been paused. >>>>>>=20 >>>>>>=20 >>>>>> Why does the engine think the VMs are paused? >>>>>> Attached engine.log. >>>>>>=20 >>>>>> I can fix the problem by powering off the VM then starting it = back up. >>>>>> But the VM is working fine! How do I get ovirt to realize that? >>>>> If this is an issue in engine, restarting engine may fix this. >>>>> but having this problem only with one node, I don't think this is = the issue. >>>>>=20 >>>>> If this is an issue in vdsm, restarting vdsm may fix this. >>>>>=20 >>>>> If this does not help, maybe this is libvirt issue? did you try to = check vm >>>>> status using virsh? >>>> this looks more likely as it seems such status is being reported >>>> logs would help, vdsm.log at the very least. >>>>=20 >>>>> If virsh thinks that the vms are paused, you can try to restart = libvirtd. >>>>>=20 >>>>> Please file a bug about this in any case with engine and vdsm = logs. >>>>>=20 >>>>> Adding Michal in case he has better idea how to proceed. >>>>>=20 >>>>> Nir >>>=20 >>> Cloud Services for Business www.j2.com <http://www.j2.com/> >>> j2 | eFax | eVoice | FuseMail | Campaigner | KeepItSafe | Onebox >>>=20 >>>=20 >>> This email, its contents and attachments contain information from j2 = Global, Inc. and/or its affiliates which may be privileged, confidential = or otherwise protected from disclosure. The information is intended to = be for the addressee(s) only. If you are not an addressee, any = disclosure, copy, distribution, or use of the contents of this message = is prohibited. If you have received this email in error please notify = the sender by reply e-mail and delete the original message and any = copies. (c) 2015 j2 Global, Inc. All rights reserved. eFax, eVoice, = Campaigner, FuseMail, KeepItSafe, and Onebox are registered trademarks = of j2 Global, Inc. and its affiliates. >>> = <supervdsm.log.gz><vdsm.log.gz>___________________________________________= ____ >>> Users mailing list >>> Users(a)ovirt.org <mailto:Users@ovirt.org> >>> http://lists.ovirt.org/mailman/listinfo/users = <http://lists.ovirt.org/mailman/listinfo/users> >=20 > <engine.log-20160421.gz><vdsm.logs.tar.gz> --Apple-Mail=_FC29514C-FC8B-44E8-A9D8-B78C0939837D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 28 Apr 2016, at 19:40, Bill James <<a = href=3D"mailto:bill.james@j2.com" class=3D"">bill.james(a)j2.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""> =20 <meta content=3D"text/html; charset=3DUTF-8" = http-equiv=3D"Content-Type" class=3D""> =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> thank you for response.<br class=3D""> I bold-ed the ones that are listed as "paused".<br class=3D""> <br class=3D""> <br class=3D""> [root@ovirt1 test vdsm]# virsh -r list --all<br class=3D"">  Id    = Name           &nbs= p;            =    State<br class=3D""> ----------------------------------------------------<br class=3D""> <b class=3D""> 2     <a = href=3D"http://puppet.test.j2noc.com" = class=3D"">puppet.test.j2noc.com</a>      &n= bsp;   running</b><br class=3D""> <b class=3D""> 4     <a = href=3D"http://sftp2.test.j2noc.com" = class=3D"">sftp2.test.j2noc.com</a>      &nb= sp;    running</b><br class=3D""> <b class=3D""> 5     <a = href=3D"http://oct.test.j2noc.com" = class=3D"">oct.test.j2noc.com</a>      &nbsp= ;      running</b><br class=3D""> <b class=3D""> 6     <a = href=3D"http://sftp2.dev.j2noc.com" = class=3D"">sftp2.dev.j2noc.com</a>      &nbs= p;     running</b><br class=3D""> <b class=3D""> 10    <a = href=3D"http://darmaster1.test.j2noc.com" = class=3D"">darmaster1.test.j2noc.com</a>      = running</b><br class=3D""> <b class=3D""> 14    <a = href=3D"http://api1.test.j2noc.com" = class=3D"">api1.test.j2noc.com</a>      &nbs= p;     running</b><br class=3D"">  25    <a href=3D"http://ftp1.frb.test.j2noc.com" = class=3D"">ftp1.frb.test.j2noc.com</a>      =   running<br class=3D"">  26    <a href=3D"http://auto7.test.j2noc.com" = class=3D"">auto7.test.j2noc.com</a>      &nb= sp;    running<br class=3D""> <b class=3D""> 32    <a = href=3D"http://epaymv02.j2noc.com" = class=3D"">epaymv02.j2noc.com</a>      &nbsp= ;      running</b><br class=3D"">  34    <a = href=3D"http://media2.frb.test.j2noc.com" = class=3D"">media2.frb.test.j2noc.com</a>      = running<br class=3D"">  36    <a href=3D"http://auto2.j2noc.com" = class=3D"">auto2.j2noc.com</a>       &n= bsp;        running<br class=3D"">  44    <a = href=3D"http://nfs.testhvy2.colo.j2noc.com" = class=3D"">nfs.testhvy2.colo.j2noc.com</a>    running<br = class=3D""> <b class=3D""> 53    <a = href=3D"http://billapp-zuma1.dev.j2noc.com" = class=3D"">billapp-zuma1.dev.j2noc.com</a>    = running</b><br class=3D""> <b class=3D""> 54    <a = href=3D"http://billing-ci.dev.j2noc.com" = class=3D"">billing-ci.dev.j2noc.com</a>     &nbsp= ; running</b><br class=3D"">  60    <a href=3D"http://log2.test.j2noc.com" = class=3D"">log2.test.j2noc.com</a>      &nbs= p;     running<br class=3D"">  63    <a href=3D"http://log1.test.j2noc.com" = class=3D"">log1.test.j2noc.com</a>      &nbs= p;     running<br class=3D""> <b class=3D""> 69    <a = href=3D"http://sonar.dev.j2noc.com" = class=3D"">sonar.dev.j2noc.com</a>      &nbs= p;     running</b><br class=3D""> <b class=3D""> 73    <a = href=3D"http://billapp-ui1.dev.j2noc.com" = class=3D"">billapp-ui1.dev.j2noc.com</a>      = running</b><br class=3D""> <b class=3D""> 74    <a = href=3D"http://billappvm01.dev.j2noc.com" = class=3D"">billappvm01.dev.j2noc.com</a>      = running</b><br class=3D"">  75    <a href=3D"http://db2.frb.test.j2noc.com" = class=3D"">db2.frb.test.j2noc.com</a>      &= nbsp;  running<br class=3D"">  83    <a = href=3D"http://billapp-ui1.test.j2noc.com" = class=3D"">billapp-ui1.test.j2noc.com</a>     = running<br class=3D""> <b class=3D""> 84    <a = href=3D"http://epayvm01.test.j2noc.com" = class=3D"">epayvm01.test.j2noc.com</a>      =   running</b><br class=3D""> <b class=3D""> 87    <a = href=3D"http://billappvm01.test.j2noc.com" = class=3D"">billappvm01.test.j2noc.com</a>     = running</b><br class=3D""> <b class=3D""> 89    <a = href=3D"http://etapi1.test.j2noc.com" = class=3D"">etapi1.test.j2noc.com</a>      &n= bsp;   running</b><br class=3D""> <b class=3D""> 93    <a = href=3D"http://billapp-zuma2.test.j2noc.com" = class=3D"">billapp-zuma2.test.j2noc.com</a>   running</b><br = class=3D""> <b class=3D""> 94    <a = href=3D"http://git.dev.j2noc.com" = class=3D"">git.dev.j2noc.com</a>       =        running</b><br class=3D""> <br class=3D""> Yes I did "systemctl restart libvirtd" which apparently also restart vdsm?<br class=3D""></div></div></blockquote><div><br = class=3D""></div>yes, it does. </div><div><br = class=3D""></div><div><blockquote type=3D"cite" class=3D""><div = class=3D""><div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> <br class=3D""> <br class=3D""> Looks like problem started around 2016-04-17 20:19:34,822, based on engine.log attached.<br class=3D""></div></div></blockquote><div><br = class=3D""></div><div>yes, that time looks correct. Any idea what might = have been a trigger? Anything interesting happened at that time (power = outage of some host, some maintenance action, = anything)? </div><div>logs indicate a problem when vdsm talks to = libvirt(all those "monitor become unresponsive=E2=80=9D)</div><div><br = class=3D""></div><div>It does seem that at that time you started to have = some storage connectivity issues - first one at 2016-04-17 = 20:06:53,929. And it doesn=E2=80=99t look temporary because such errors = are still there couple hours later(in your most recent file you attached = I can see at 23:00:54)</div><div>When I/O gets blocked the VMs may = experience issues (then VM gets Paused), or their qemu process gets = stuck(resulting in libvirt either reporting error or getting stuck as = well -> resulting in what vdsm sees as =E2=80=9Cmonitor = unresponsive=E2=80=9D)</div><div><br class=3D""></div><div>Since you now = bounced libvirtd - did it help? Do you still see wrong status for those = VMs and still those "monitor unresponsive" errors in = vdsm.log?</div><div>If not=E2=80=A6then I would suspect the =E2=80=9Cvm = recovery=E2=80=9D code not working correctly. Milan is looking at = that.</div><div><br = class=3D""></div><div>Thanks,</div><div>michal</div><div><div><br = class=3D""></div></div><div class=3D""><br class=3D""></div><blockquote = type=3D"cite" class=3D""><div class=3D""><div bgcolor=3D"#FFFFFF" = text=3D"#000000" class=3D""> There's a lot of vdsm logs!<br class=3D""> <br class=3D""> fyi, the storage domain for these Vms is a "local" nfs share, 7e566f55-e060-47b7-bfa4-ac3c48d70dda.<br class=3D""> <br class=3D""> attached more logs.<br class=3D""> <br class=3D""> <br class=3D""> <div class=3D"moz-cite-prefix">On 04/28/2016 12:53 AM, Michal Skrivanek wrote:<br class=3D""> </div> <blockquote = cite=3D"mid:28BF55E6-3A90-4BB7-90B9-1EE0A82FC460@redhat.com" type=3D"cite"= class=3D""> <pre wrap=3D"" class=3D""></pre> <blockquote type=3D"cite" class=3D""> <pre wrap=3D"" class=3D"">On 27 Apr 2016, at 19:16, Bill James = <a class=3D"moz-txt-link-rfc2396E" = href=3D"mailto:bill.james@j2.com"><bill.james(a)j2.com></a> wrote: virsh # list --all error: failed to connect to the hypervisor error: no valid connection error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No = such file or directory </pre> </blockquote> <pre wrap=3D"" class=3D"">you need to run virsh in read-only mode virsh -r list =E2=80=94all </pre> <blockquote type=3D"cite" class=3D""> <pre wrap=3D"" class=3D"">[root@ovirt1 test vdsm]# systemctl = status libvirtd =E2=97=8F libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; = vendor preset: enabled) Drop-In: /etc/systemd/system/libvirtd.service.d =E2=94=94=E2=94=80unlimited-core.conf Active: active (running) since Thu 2016-04-21 16:00:03 PDT; 5 days ago tried systemctl restart libvirtd. No change. Attached vdsm.log and supervdsm.log. [root@ovirt1 test vdsm]# systemctl status vdsmd =E2=97=8F vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor = preset: enabled) Active: active (running) since Wed 2016-04-27 10:09:14 PDT; 3min 46s = ago vdsm-4.17.18-0.el7.centos.noarch </pre> </blockquote> <pre wrap=3D"" class=3D"">the vdsm.log attach is good, but it=E2=80=99= s too short interval, it only shows recovery(vdsm restart) phase when = the VMs are identified as paused=E2=80=A6.can you add earlier logs? Did = you restart vdsm yourself or did it crash? </pre> <blockquote type=3D"cite" class=3D""> <pre wrap=3D"" class=3D"">libvirt-daemon-1.2.17-13.el7_2.4.x86_64 Thanks. On 04/26/2016 11:35 PM, Michal Skrivanek wrote: </pre> <blockquote type=3D"cite" class=3D""> <blockquote type=3D"cite" class=3D""> <pre wrap=3D"" class=3D"">On 27 Apr 2016, at 02:04, Nir = Soffer <a class=3D"moz-txt-link-rfc2396E" = href=3D"mailto:nsoffer@redhat.com"><nsoffer(a)redhat.com></a> wrote: jjOn Wed, Apr 27, 2016 at 2:03 AM, Bill James <a = class=3D"moz-txt-link-rfc2396E" = href=3D"mailto:bill.james@j2.com"><bill.james(a)j2.com></a> wrote: </pre> <blockquote type=3D"cite" class=3D""> <pre wrap=3D"" class=3D"">I have a hardware node that has = 26 VMs. 9 are listed as "running", 17 are listed as "paused". In truth all VMs are up and running fine. I tried telling the db they are up: engine=3D> update vm_dynamic set status =3D 1 where vm_guid =3D(select vm_guid from vm_static where vm_name =3D '<a = href=3D"http://api1.test.j2noc.com" class=3D"">api1.test.j2noc.com</a>'); GUI then shows it up for a short while, then puts it back in paused state. 2016-04-26 15:16:46,095 INFO = [org.ovirt.engine.core.vdsbroker.VmAnalyzer] (DefaultQuartzScheduler_Worker-16) [157cc21e] VM = '242ca0af-4ab2-4dd6-b515-5 d435e6452c4'(<a href=3D"http://api1.test.j2noc.com" = class=3D"">api1.test.j2noc.com</a>) moved from 'Up' --> 'Paused' 2016-04-26 15:16:46,221 INFO = [org.ovirt.engine.core.dal.dbbroker.auditlogh andling.AuditLogDirector] (DefaultQuartzScheduler_Worker-16) [157cc21e] = Cor relation ID: null, Call Stack: null, Custom Event ID: -1, Message: VM = api1. <a href=3D"http://test.j2noc.com" class=3D"">test.j2noc.com</a> has been = paused. Why does the engine think the VMs are paused? Attached engine.log. I can fix the problem by powering off the VM then starting it back up. But the VM is working fine! How do I get ovirt to realize that? </pre> </blockquote> <pre wrap=3D"" class=3D"">If this is an issue in engine, = restarting engine may fix this. but having this problem only with one node, I don't think this is the = issue. If this is an issue in vdsm, restarting vdsm may fix this. If this does not help, maybe this is libvirt issue? did you try to check = vm status using virsh? </pre> </blockquote> <pre wrap=3D"" class=3D"">this looks more likely as it seems = such status is being reported logs would help, vdsm.log at the very least. </pre> <blockquote type=3D"cite" class=3D""> <pre wrap=3D"" class=3D"">If virsh thinks that the vms are = paused, you can try to restart libvirtd. Please file a bug about this in any case with engine and vdsm logs. Adding Michal in case he has better idea how to proceed. Nir </pre> </blockquote> </blockquote> <pre wrap=3D"" class=3D""> Cloud Services for Business <a class=3D"moz-txt-link-abbreviated" = href=3D"http://www.j2.com/">www.j2.com</a> j2 | eFax | eVoice | FuseMail | Campaigner | KeepItSafe | Onebox This email, its contents and attachments contain information from j2 = Global, Inc. and/or its affiliates which may be privileged, confidential = or otherwise protected from disclosure. The information is intended to = be for the addressee(s) only. If you are not an addressee, any = disclosure, copy, distribution, or use of the contents of this message = is prohibited. If you have received this email in error please notify = the sender by reply e-mail and delete the original message and any = copies. (c) 2015 j2 Global, Inc. All rights reserved. eFax, eVoice, = Campaigner, FuseMail, KeepItSafe, and Onebox are registered trademarks = of j2 Global, Inc. and its affiliates. = <supervdsm.log.gz><vdsm.log.gz>_______________________________= ________________ Users mailing list <a class=3D"moz-txt-link-abbreviated" = href=3D"mailto:Users@ovirt.org">Users(a)ovirt.org</a> <a class=3D"moz-txt-link-freetext" = href=3D"http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.= org/mailman/listinfo/users</a> </pre> </blockquote> <pre wrap=3D"" class=3D""></pre> </blockquote> <br class=3D""> </div> <span = id=3D"cid:EB02B488-C070-46FA-9938-DC7D6DF5BEED@brq.redhat.com"><engine.= log-20160421.gz></span><span = id=3D"cid:52E27023-A602-4DB0-B69A-18237CC048A3@brq.redhat.com"><vdsm.lo= gs.tar.gz></span></div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_FC29514C-FC8B-44E8-A9D8-B78C0939837D--

4 7

Re: [ovirt-users] ovirt 4.0 alpha web login error
by Martin Perina 13 May '16

13 May '16

Hi, there is no way how to disable SSO in oVirt 4.0. And IMO there's no need to do that, because the change from previous login mechanism (separated logins for webadmin, userportal and restapi) should be fully transparent. The only way necessary is to set proper FQDN during engine-setup and use always this FQDN always when accessing engine. But please bear in mind, that you are using alpha version so there may be bugs ... If ovirt-engine-rename doesn't works for you, then you may be hit by https://bugzilla.redhat.com/show_bug.cgi?id=1330168 which fixed in beta release ... Thanks Martin Perina On Fri, May 13, 2016 at 3:20 AM, like.ma(a)cs2c.com.cn <like.ma(a)cs2c.com.cn> wrote: > Hi, Martin > > I saw your comment on bug 1325746( > https://bugzilla.redhat.com/show_bug.cgi?id=1325746) > Is there anyway to disable SSO login for web portal? Make it just like the > old versions of ovirt(3.4, 3.5, 3.6 ... ). > Or is there any document about how to use SSO method to access ovirt web > portal? > > Thanks > > ------------------------------ > like.ma(a)cs2c.com.cn > > > *From:* like.ma(a)cs2c.com.cn > *Date:* 2016-05-12 16:31 > *To:* users <users(a)ovirt.org> > *Subject:* [ovirt-users] ovirt 4.0 alpha web login error > Hi! > > I installed ovirt 4.0 alpha(4.0.0-0.0.master.20160404161620.git4ffd5a4) on > RHEL7.2. > During engine-setup, i use ovirtManager.com as the host name(i add > ip/hostname in the /etc/hosts). > After engine-setup succeed, i try to access webadmin portal from another > computer. > In the client computer i use Chrome browser. And the url is > https://ovirtManager.com(ovirtManager.com can be resolved in /etc/hosts). > But i got following error when i access this url: > The client is not authorized to request an authorization. It's required to > access the system using FQDN. > > So, what should i do to access the webadmin portal? > > Many thanks for any advise > > > ------------------------------ > like.ma(a)cs2c.com.cn > > >

1 0

Re: [ovirt-users] Domain Change
by Jack Greene 12 May '16

12 May '16

----_com.android.email_19001378574001720 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhhbmtzIE1hcnRpbiwgSSdsbCBnaXZlIGl0IGEgdHJ5wqAKSmFja8KgCgotLS0tLS0tLSBPcmln aW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206IE1hcnRpbiBQZXJpbmEgPG1wZXJpbmFAcmVkaGF0 LmNvbT4gCkRhdGU6IDA1LzEyLzIwMTYgIDEyOjQ5IFBNICAoR01ULTA4OjAwKSAKVG86IEphY2sg R3JlZW5lIDxqYWNrQHNkaGVscC5jb20+IApDYzogdXNlcnMgPHVzZXJzQG92aXJ0Lm9yZz4gClN1 YmplY3Q6IFJlOiBbb3ZpcnQtdXNlcnNdIERvbWFpbiBDaGFuZ2UgCgpIaSwKCnRvIGNoYW5nZSBl bmdpbmUgRlFETiBwbGVhc2UgdXNlIG92aXJ0LWVuZ2luZS1yZW5hbWUgdG9vbDoKCi91c3Ivc2hh cmUvb3ZpcnQtZW5naW5lL3NldHVwL2Jpbi9vdmlydC1lbmdpbmUtcmVuYW1lIC0tbmV3bmFtZT08 TkVXX0ZRRE4+CgoKTWFydGluIFBlcmluYQoKCk9uIFRodSwgTWF5IDEyLCAyMDE2IGF0IDQ6NTIg UE0sIEphY2sgR3JlZW5lIDxqYWNrQHNkaGVscC5jb20+IHdyb3RlOgpTbyBteSBsYWIgaXMgcmVh ZHkgZm9yIGRlcGxveW1lbnQgaW4gdGhlIG1hc3RlciBkb21haW4uwqAgSXMgdGhlcmUgYW4gZWFz eSB3YXkgb2YgY2hhbmdpbmcgdGhlIEZRRE4gb2YgdGhlIGVuZ2luZS9ob3N0cyBvciB3aWxsIEkg aGF2ZSB0byByZWRlcGxveSB0aGUgZW5naW5lP8KgVGhhbmtzIApfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKVXNlcnMgbWFpbGluZyBsaXN0CgpVc2Vyc0Bv dmlydC5vcmcKCmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycwoK CgoK ----_com.android.email_19001378574001720 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5UaGFua3MgTWFydGluLCBJJ2xsIGdp dmUgaXQgYSB0cnkmbmJzcDs8ZGl2Pjxicj48L2Rpdj48ZGl2PkphY2smbmJzcDs8L2Rpdj48YnI+ PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+RnJvbTogTWFydGluIFBl cmluYSAmbHQ7bXBlcmluYUByZWRoYXQuY29tJmd0OyA8YnI+RGF0ZTogMDUvMTIvMjAxNiAgMTI6 NDkgUE0gIChHTVQtMDg6MDApIDxicj5UbzogSmFjayBHcmVlbmUgJmx0O2phY2tAc2RoZWxwLmNv bSZndDsgPGJyPkNjOiB1c2VycyAmbHQ7dXNlcnNAb3ZpcnQub3JnJmd0OyA8YnI+U3ViamVjdDog UmU6IFtvdmlydC11c2Vyc10gRG9tYWluIENoYW5nZSA8YnI+PGJyPjxkaXYgZGlyPSJsdHIiPjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZiI+SGksPGJyPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0 IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPnRvIGNoYW5n ZSBlbmdpbmUgRlFETiBwbGVhc2UgdXNlIG92aXJ0LWVuZ2luZS1yZW5hbWUgdG9vbDo8YnI+PGJy PjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+L3Vzci9zaGFyZS9vdmlydC1lbmdpbmUvc2V0dXAvYmlu L292aXJ0LWVuZ2luZS1yZW5hbWUgLS1uZXduYW1lPSZsdDtORVdfRlFETiZndDs8YnI+PGJyPjxi cj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPk1hcnRpbiBQZXJpbmE8YnI+PGJyPjwvZGl2PjwvZGl2 PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9u IFRodSwgTWF5IDEyLCAyMDE2IGF0IDQ6NTIgUE0sIEphY2sgR3JlZW5lIDxzcGFuIGRpcj0ibHRy Ij4mbHQ7PGEgaHJlZj0ibWFpbHRvOmphY2tAc2RoZWxwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmph Y2tAc2RoZWxwLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1 NEY3MiIgbGFuZz0iRU4tVVMiPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gbXkgbGFiIGlz IHJlYWR5IGZvciBkZXBsb3ltZW50IGluIHRoZSBtYXN0ZXIgZG9tYWluLiZuYnNwOyBJcyB0aGVy ZSBhbiBlYXN5IHdheSBvZiBjaGFuZ2luZyB0aGUgRlFETiBvZiB0aGUgZW5naW5lL2hvc3RzIG9y IHdpbGwgSSBoYXZlIHRvIHJlZGVwbG95IHRoZSBlbmdpbmU/PHU+PC91Pjx1PjwvdT48L3A+PHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzIDx1PjwvdT48dT48L3U+PC9wPjwvZGl2PjwvZGl2Pjxicj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KVXNlcnMgbWFpbGluZyBs aXN0PGJyPgo8YSBocmVmPSJtYWlsdG86VXNlcnNAb3ZpcnQub3JnIj5Vc2Vyc0BvdmlydC5vcmc8 L2E+PGJyPgo8YSBocmVmPSJodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8v dXNlcnMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9saXN0cy5vdmly dC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VyczwvYT48YnI+Cjxicj48L2Jsb2NrcXVvdGU+PC9k aXY+PGJyPjwvZGl2Pgo8L2JvZHk+PC9odG1sPg== ----_com.android.email_19001378574001720--

1 0

Domain Change
by Jack Greene 12 May '16

12 May '16

This is a multipart message in MIME format. ------=_NextPart_000_0018_01D1AC23.3F35AC50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So my lab is ready for deployment in the master domain. Is there an easy way of changing the FQDN of the engine/hosts or will I have to redeploy the engine? Thanks ------=_NextPart_000_0018_01D1AC23.3F35AC50 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 15 = (filtered medium)"><style></style></head><body lang=3DEN-US = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1><p = class=3DMsoNormal>So my lab is ready for deployment in the master = domain.  Is there an easy way of changing the FQDN of the = engine/hosts or will I have to redeploy the engine?<o:p></o:p></p><p = class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Thanks = <o:p></o:p></p></div></body></html> ------=_NextPart_000_0018_01D1AC23.3F35AC50--

2 1