- Users - oVirt List Archives

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