January 2018 - Devel - oVirt List Archives

Terraform provider for oVirt
by Sandro Bonazzola 15 May '18

15 May '18

Hi, just following up from twitter[1], if any developer within oVirt knows about Terraform, there's interest on their side for collaboration developing a provider. For more info, see the github issue: https://github.com/hashicorp/terraform/issues/16150 [1] https://twitter.com/jepeltw/status/955647436931858432 -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

3 7

Mailing-Lists upgrade
by Marc Dequènes (Duck) 28 Apr '18

28 Apr '18

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq Content-Type: multipart/mixed; boundary="AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv"; protected-headers="v1" From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck(a)redhat.com> To: oVirt Infra <infra(a)ovirt.org>, users <users(a)ovirt.org>, devel <devel(a)ovirt.org> Message-ID: <c5c71fce-0290-e97a-ddd0-eab0e6fccea4(a)redhat.com> Subject: Mailing-Lists upgrade --AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Quack, On behalf of the oVirt infra team, I'd like to announce the current Mailing-Lists system is going to be upgraded to a brand new Mailman 3 installation on Monday during the slot 11:00-12:00 JST. It should not take a full hour to migrate as we already made incremental synchronization with the current system but better keep some margin. The system will then take over delivery of the mails but might be a bit slow at first as it needs to reindex all the archived mails (which might take a few hours). To manage your subscriptions and delivery settings you can do this easily on the much nicer web interface (https://lists.ovirt.org) There is a notion of account so you don't need to login separately for each ML.= You can Sign In using Fedora, GitHub or Google or create a local account if you prefer. Please keep in mind signing in with a different method would create separate accounts (which cannot be merged at the moment). But you can easily link your account to other authentication methods in your settings (click on you name in the up-right corner -> Account -> Account Connections). As for the original mail archives, because the previous system did not have stable URLs, we cannot create mappings to the new pages. We decided to keep the old archives around on the same URL (/pipermail), so the Internet links would still work fine. Hope you'd be happy with the new system. \_o< --AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv-- --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcpcqg+UmRT3yiF+BVen596wcRD8FAlmwx0MACgkQVen596wc RD9LTQ/+LtUncsq9K8D/LX8wqUTd6VyPwAD5UnAk5c3H/2tmyVA0u7FIfhEyPsXs Z//LE9FEneTDqDVRi1Dw9I54K0ZwxPBemi71dXfwgBI7Ay0ezkbLWrA168Mt9spE tHAODEuxPt2to2aqaS4ujogrkp/gvEP8ILoxPEqoTPCJ/eDTPAu/I1a2JzjMPK3n 2BBS6D8z0TLAf7w1n72TsgX2QzJW57ig/0HELyjvat2/K8V3HSrkwiKlsdULQDWe zB+aMde7r6UoyVKHqlu4asTl2tU/lGZ+e31Hd9Bnx1/oZOJdzslGOhEo9Qoz6763 AHWU9LKiK4NtxYHj2UQTWhndr8PiTtTmR73eIDmkb0cuRXxzjl9VQbwYJ0Kbrmfp attTqpc2CnEojTNXUUNSmNxotZoYXZiX8ZvjPfSgRVr15TUYujzlOfG+lUynbQMV 9rQ9/m58wgwYUymMpOIsRGaIcAKzjm+WpuuVnO+bS2AfmcBkGMQRoIhfV+3SkS8q kT9cDXgcDZOzVFcnZZB4EjbycMcPgZDcoHxU88VdYH+jFJYvvb21esgswVF/wJ2Z uEI/chp4+ADaQhl8ehZNWMSZq125v6SeirPhBNgLG7zFVZI1S9Tm/6qFmH+ajQY7 nCk1X9HZlB1ubex1X+HibRz9QKOilkMgkADyJ4yMDckwYj93sx0= =l6uN -----END PGP SIGNATURE----- --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq--

2 4

[vdsm][RFC] reconsidering branching out ovirt-4.2
by Francesco Romani 06 Feb '18

06 Feb '18

Hi all, It is time again to reconsider branching out the 4.2 stable branch. So far we decided to *not* branch out, and we are taking tags for ovirt 4.2 releases from master branch. This means we are merging safe and/or stabilization patches only in master. I think it is time to reconsider this decision and branch out for 4.2, because of two reasons: 1. it sends a clearer signal that 4.2 is going in stabilization mode 2. we have requests from virt team, which wants to start working on the next cycle features. If we decide to branch out, I'd start the new branch on monday, February 5 (1 week from now). The discussion is open, please share your acks/nacks for branching out, and for the branching date. I for myself I'm inclined to branch out, so if noone chimes in (!!) I'll execute the above plan. -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

5 5

[ACTION-REQUIRED] Making accurate CI for oVirt 4.2
by Barak Korren 06 Feb '18

06 Feb '18

Hi, This message is aimed for project maintainers. Other developers may also find it interesting to have a glimpse at the oVirt-wide test and composition processes. TL;DR: To get accurate CI for oVirt 4.2, most projects need to add 4.2 jobs in YAML. Before I can explain what the current issue is and which action is required, I'm need to provide a brief overview into how oVirt CI works. oVirt CI has two major components to it: 1. The STDCI component which is used to build and test individual projects. Most developers interact with this on a daily basis as it is responding on GitHub and Gerrit events. 2. The "change-queue" (CQ) component which is used to automatically compose the whole of oVirt from its sub projects and run system tests (OST) on it. This component is used to gather the information that is used by the infra team to compose the "OST failure report" you can occasionally see being sent to this list. The change queue is also used to automatically maintain the 'tested' and '*-snapshot' (AKA nightly) repositories. The way the CQ composes oVirt is by looking at the post-merge STDCI 'build-artifacts' jobs, and collecting together artifacts built by jobs that target a specific oVirt version into that version's change queue. Essentially the '*_master_build-artifacts-*' jobs go into the 'ovirt-master' change queue, the '*_4.1_build-artifacts-*' jobs go into the 'ovirt-4.1' change queue etc. Over the course of the oVirt 4.2 development, most project used their 'master' branch, which is typically mapped to '*_master_*' jobs, for developing 4.2 code. So the 'ovirt-master' CQ provided good indication of the state of 4.2 code. As projects started addeing 4.2 branches, we have created an 'ovirt-4.2' CQ to gather them. We did so under the assumption that most projects will branch soon after. The assumption turned up to be wrong as most projects did not yet fork and may not do so in the near future. As some projects did fork, the end result is that currently: ___there is no accurate representation of oVirt 4.2 in CI___ 'ovirt-master' CQ no longer represents oVirt 4.2 as some projects already have some 4.3 code in their 'master' branches. 'ovirt-4.2' CQ does not represent oVirt 4.2 as most projects do not push artifacts into it. To get any benefit from CI, we need to have it represent what we are going to release. This means that at this point we need all projects to have '*_4.2_build-artifacts-*' jobs that map to the code that is intended to be included in oVirt 4.2. Projects can either: 1. Create 4.2 branches and map the new jobs to them. 2. Keep 4.2 development in 'master' and create '4.2' jobs that map to it. Taking route #2 means a commitment to not adding any 4.3 code to the 'master' branch. Please keep it, as rolling back "too new" builds from the various repos and caches we have is very difficult. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

7 15

[IOPROCESS] New release for Fedora
by Nir Soffer 04 Feb '18

04 Feb '18

Hi all, I released ioprocess 1.0.0 for Fedora 27 and 28. If you are using Fedora, please install the new version from the updates-testing and test it. Please share your feedback here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbe8141dd2 This version will be available soon from oVirt repositories. Thanks, Nir

1 1

Re: [ovirt-devel] [RFC] reconsidering branching out ovirt-4.2
by Tal Nisan 31 Jan '18

31 Jan '18

For alignment purposes between the projects we should consider branch ovirt-engine as well. At this point in time I'm for it, would like to hear any acks/nacks so we can decide how we proceeed On Mon, Jan 29, 2018 at 9:02 AM, Dan Kenigsberg <danken(a)redhat.com> wrote: > On Mon, Jan 29, 2018 at 9:39 AM, Francesco Romani <fromani(a)redhat.com> > wrote: > > Hi all, > > > > > > It is time again to reconsider branching out the 4.2 stable branch. > > > > So far we decided to *not* branch out, and we are taking tags for ovirt > > 4.2 releases from master branch. > > > > This means we are merging safe and/or stabilization patches only in > master. > > > > > > I think it is time to reconsider this decision and branch out for 4.2, > > because of two reasons: > > > > 1. it sends a clearer signal that 4.2 is going in stabilization mode > > > > 2. we have requests from virt team, which wants to start working on the > > next cycle features. > > > > > > If we decide to branch out, I'd start the new branch on monday, February > > 5 (1 week from now). > > > > > > The discussion is open, please share your acks/nacks for branching out, > > and for the branching date. > > > > > > I for myself I'm inclined to branch out, so if noone chimes in (!!) I'll > > execute the above plan. > > For network we don't see a lot of pending 4.2 work - except for the > requirement to support el7.5. On the other hand, we too have already a > patch for 4.3. Thus I'm fine with branching next week. > > When you do branch, please make sure to follow Barak Korren's request on > the > [ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2 > thread. > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >

6 6

Fix for: "The CPU type of the cluster is unknown"
by Arik Hadas 30 Jan '18

30 Jan '18

Hi all, Last week we merged a patch that may reset the cluster's CPU and therefore could cause the following error to happen when trying to run a VM: "The CPU type of the cluster is unknown. ..." A fix is now posted. In the meantime, this can be resolved by refreshing the capabilities of one of your hosts. Arik

1 0

What does SDM.merge's param "base_generation" in subchain_info means?
by pengyixiang 30 Jan '18

30 Jan '18

------=_Part_140011_191578780.1517228861952 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 aGVsbG8sIGV2ZXJ5b25lIQogICAgIFdoZW4gd2UgY2FsbCAiU0RNLm1lcmdlIiwgd2UgbmVlZCBh IHBhcmFtICJiYXNlX2dlbmVyYXRpb24iIGluIFsxXSwgYW5kIEkga25vdyBbMl0gd2lsbCBiZSBj YWxsZWQgYW5kICJiYXNlX2dlbmVyYXRpb24iIGlzIHRyYW5zbGF0ZWQgdG8gInJlcXVlc3RlZF9n ZW4iLCB0aGF0IG1lYW5zICJHRU4iIGluIGRpc2sgbWV0YWRhdGE/CklmIHNvLCBob3cgZGlkIHRo aXMgIkdFTiIgd29ya2VkIGFuZCBzZXRlZD8gSSBzZWUgbWFueSAqLm1ldGEgaXMgIkdFTj0wIiwg YW5kIHNvbWUgaXMgIkdFTj0xIiBpbiBbM10uIAoKCgoKSG9wZSB0byBnZXQgeW91ciByZXBseSwg VGhhbmsgeW91IQoKCgoKWzFdICB7J3N1YmNoYWluX2luZm8nOiB7J2ltZ19pZCc6ICc5MTgzNzUy NS04NTBkLTRlNzQtOWE3ZS1jODliNzkzZDBlNWInLCAnc2RfaWQnOiAnOTNiOGEyYzktZjUyNy00 ZWIzLWFjZmItYWY3NmFiMjRmYmJlJywgJ3RvcF9pZCc6ICc0ZTUxZDRlNS05NjMwLTQ1YTYtOTgy OS0wMTI0NjBlN2Q2N2EnLCAnYmFzZV9pZCc6ICdmZGY0NzU4NC0yMWFhLTQ1YjItOTkyNS0xNTdm ZjU0ZjVlN2UnLCAnYmFzZV9nZW5lcmF0aW9uJzogMH0sICdqb2JfaWQnOiAnNzY2YTMwNTAtNDc2 Yy00OGFlLTk0NzAtM2JlYzc4NjdhNmNkJ30KCgpbMl0gIGh0dHBzOi8vZ2l0aHViLmNvbS9vVmly dC92ZHNtL2Jsb2IvMDdkMDUyODdhYzE0OTZhZDQ5OTE1ZTAyNmQzNGUyOWNhNGRhNjM1Yi9saWIv dmRzbS9zdG9yYWdlL3ZvbHVtZS5weSNMNjAyCgoKWzNdIApET01BSU49OTNiOGEyYzktZjUyNy00 ZWIzLWFjZmItYWY3NmFiMjRmYmJlIENUSU1FPTE1MTYwOTA0NTQgRk9STUFUPUNPVyBESVNLVFlQ RT0yIExFR0FMSVRZPUxFR0FMIFNJWkU9MTY3NzcyMTYwIFZPTFRZUEU9SU5URVJOQUwgREVTQ1JJ UFRJT049IElNQUdFPWY4ODJlN2NjLWY1N2UtNDhmZi05Yjg3LWJiYTM1MzMxZTk4MyBQVVVJRD05 MDUwZjk1Ni02ODM2LTRmY2UtOGQyNy02OWRmMTNjNGY4NWMgTVRJTUU9MCBQT09MX1VVSUQ9IFRZ UEU9U1BBUlNFIEdFTj0xIEVPRg== ------=_Part_140011_191578780.1517228861952 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+aGVsbG8sIGV2ZXJ5b25lITwvZGl2PjxkaXY+Jm5ic3A7 ICZuYnNwOyAmbmJzcDtXaGVuIHdlIGNhbGwgIlNETS5tZXJnZSIsIHdlIG5lZWQgYSBwYXJhbSZu YnNwOyJiYXNlX2dlbmVyYXRpb24iIGluIFsxXSwgYW5kIEkga25vdyBbMl0gd2lsbCBiZSBjYWxs ZWQgYW5kICJiYXNlX2dlbmVyYXRpb24iIGlzIHRyYW5zbGF0ZWQgdG8gIjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTEsIDIyMSk7IGNvbG9yOiByZ2IoMzYsIDQxLCA0 Nik7IGZvbnQtZmFtaWx5OiBTRk1vbm8tUmVndWxhciwgQ29uc29sYXMsICZxdW90O0xpYmVyYXRp b24gTW9ubyZxdW90OywgTWVubG8sIENvdXJpZXIsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4 OyB3aGl0ZS1zcGFjZTogcHJlOyI+cmVxdWVzdGVkX2dlbjwvc3Bhbj4iLCB0aGF0IG1lYW5zICJH RU4iIGluIGRpc2sgbWV0YWRhdGE/PC9kaXY+PGRpdj5JZiBzbywgaG93IGRpZCB0aGlzICJHRU4i IHdvcmtlZCBhbmQgc2V0ZWQ/IEkgc2VlIG1hbnkgKi5tZXRhIGlzICI8c3BhbiBzdHlsZT0iY29s b3I6IHJnYigzNiwgNDEsIDQ2KTsgZm9udC1mYW1pbHk6IFNGTW9uby1SZWd1bGFyLCBDb25zb2xh cywgJnF1b3Q7TGliZXJhdGlvbiBNb25vJnF1b3Q7LCBNZW5sbywgQ291cmllciwgbW9ub3NwYWNl OyBmb250LXNpemU6IDEycHg7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPkdFTj0wPC9zcGFuPiIs IGFuZCBzb21lIGlzICI8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzNiwgNDEsIDQ2KTsgZm9udC1m YW1pbHk6IFNGTW9uby1SZWd1bGFyLCBDb25zb2xhcywgJnF1b3Q7TGliZXJhdGlvbiBNb25vJnF1 b3Q7LCBNZW5sbywgQ291cmllciwgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7IHdoaXRlLXNw YWNlOiBwcmUtd3JhcDsiPkdFTj0xPC9zcGFuPiIgaW4gWzNdLiZuYnNwOzwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUx LCA1MSk7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxMy45MXB4OyI+SG9wZSB0byBn ZXQgeW91ciByZXBseSwgVGhhbmsgeW91ITwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlsxXSZuYnNwOyZuYnNwO3snc3ViY2hhaW5faW5mbyc6IHsnaW1nX2lk JzogJzkxODM3NTI1LTg1MGQtNGU3NC05YTdlLWM4OWI3OTNkMGU1YicsICdzZF9pZCc6ICc5M2I4 YTJjOS1mNTI3LTRlYjMtYWNmYi1hZjc2YWIyNGZiYmUnLCAndG9wX2lkJzogJzRlNTFkNGU1LTk2 MzAtNDVhNi05ODI5LTAxMjQ2MGU3ZDY3YScsICdiYXNlX2lkJzogJ2ZkZjQ3NTg0LTIxYWEtNDVi Mi05OTI1LTE1N2ZmNTRmNWU3ZScsICc8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyNTUsIDAsIDAp OyI+YmFzZV9nZW5lcmF0aW9uPC9zcGFuPic6IDB9LCAnam9iX2lkJzogJzc2NmEzMDUwLTQ3NmMt NDhhZS05NDcwLTNiZWM3ODY3YTZjZCd9PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5bMl0mbmJz cDsmbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzNiwgNDEsIDQ2KTsgZm9udC1mYW1pbHk6 IFNGTW9uby1SZWd1bGFyLCBDb25zb2xhcywgJnF1b3Q7TGliZXJhdGlvbiBNb25vJnF1b3Q7LCBN ZW5sbywgQ291cmllciwgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7IHdoaXRlLXNwYWNlOiBw cmUtd3JhcDsiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9vVmlydC92ZHNtL2Jsb2IvMDdk MDUyODdhYzE0OTZhZDQ5OTE1ZTAyNmQzNGUyOWNhNGRhNjM1Yi9saWIvdmRzbS9zdG9yYWdlL3Zv bHVtZS5weSNMNjAyIiBfc3JjPSJodHRwczovL2dpdGh1Yi5jb20vb1ZpcnQvdmRzbS9ibG9iLzA3 ZDA1Mjg3YWMxNDk2YWQ0OTkxNWUwMjZkMzRlMjljYTRkYTYzNWIvbGliL3Zkc20vc3RvcmFnZS92 b2x1bWUucHkjTDYwMiI+aHR0cHM6Ly9naXRodWIuY29tL29WaXJ0L3Zkc20vYmxvYi8wN2QwNTI4 N2FjMTQ5NmFkNDk5MTVlMDI2ZDM0ZTI5Y2E0ZGE2MzViL2xpYi92ZHNtL3N0b3JhZ2Uvdm9sdW1l LnB5I0w2MDI8L2E+PC9zcGFuPjwvZGl2PjxkaXY+PGZvbnQgY29sb3I9IiMyNDI5MmUiIGZhY2U9 IlNGTW9uby1SZWd1bGFyLCBDb25zb2xhcywgTGliZXJhdGlvbiBNb25vLCBNZW5sbywgQ291cmll ciwgbW9ub3NwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyB3aGl0ZS1zcGFjZTog cHJlLXdyYXA7Ij48YnI+PC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2PlszXSZuYnNwOzwvZGl2Pjxk aXY+PGZvbnQgY29sb3I9IiMyNDI5MmUiIGZhY2U9IlNGTW9uby1SZWd1bGFyLCBDb25zb2xhcywg TGliZXJhdGlvbiBNb25vLCBNZW5sbywgQ291cmllciwgbW9ub3NwYWNlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMnB4OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5ET01BSU49OTNiOGEyYzkt ZjUyNy00ZWIzLWFjZmItYWY3NmFiMjRmYmJlCkNUSU1FPTE1MTYwOTA0NTQKRk9STUFUPUNPVwpE SVNLVFlQRT0yCkxFR0FMSVRZPUxFR0FMClNJWkU9MTY3NzcyMTYwClZPTFRZUEU9SU5URVJOQUwK REVTQ1JJUFRJT049CklNQUdFPWY4ODJlN2NjLWY1N2UtNDhmZi05Yjg3LWJiYTM1MzMxZTk4MwpQ VVVJRD05MDUwZjk1Ni02ODM2LTRmY2UtOGQyNy02OWRmMTNjNGY4NWMKTVRJTUU9MApQT09MX1VV SUQ9ClRZUEU9U1BBUlNFCkdFTj0xCkVPRjwvc3Bhbj48L2ZvbnQ+PC9kaXY+PC9kaXY+PGJyPjxi cj48c3BhbiB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHA+Jm5ic3A7PC9wPjwvc3Bhbj4= ------=_Part_140011_191578780.1517228861952--

1 0

PHX planned maintenance 29.01.2018 @19:00 GMT
by Evgheni Dereveanchin 29 Jan '18

29 Jan '18

Hi everyone, Planned works are going to be performed in the PHX data center today. They are related to core networking hardware upgrades and may cause short connectivity loss to services hosted by the oVirt project, including: * Jenkins CI * Package repositories * project website * mailing lists The maintenance window starts at 19:00 GMT and has a duration of one hour. I will pause CI job execution before the maintenance window so builds will be queued and executed after network upgrades are implemented to decrease the possibility of false positives. I will follow up with any further updates. -- Regards, Evgheni Dereveanchin

1 1

Error while setting up disk in ovirt-engine.
by Avinash Dasoundhi 29 Jan '18

29 Jan '18

Hello Everyone I have set up ovirt-engine for testing purpose and, I am using ovirt-vdsmfake[1] to provision host and vms on that ovirt-engine. But I am facing an error while creating a disk. I have provision 10 hosts, all are up with their own local storage. And when I am trying to add a disk to the disk section, error popups like "*Error while executing action Add Disk to VM: General Exception*". I saw the logs, thought of some permission error, checked that but still this error is coming. Can somebody provide some details on it? I am attaching the engine.log with this mail. Thank You -- AVINASH DASOUNDHI ASSOCIATE SOFTWARE ENGINEER IN ENG PERF R&D, RHCSA Red Hat BLR <https://www.redhat.com/> IRC - tenstormavi adasound(a)redhat.com M: +91-8653245552 <https://red.ht/sig>

3 2