- Devel - oVirt List Archives

[Lago] [HC] Hosted engine deploy fails on master
by Sahina Bose 26 Jun '17

26 Jun '17

hosted-engine --deploy fails with ["***L:ERROR Internal error: No module named M2Crypto"] Known issue? On Fri, Jun 23, 2017 at 7:22 PM, <jenkins(a)jenkins.phx.ovirt.org> wrote: > Project: http://jenkins.ovirt.org/job/ovirt_master_hc-system-tests/ > Build: http://jenkins.ovirt.org/job/ovirt_master_hc-system-tests/144/ > Build Number: 144 > Build Status: Still Failing > Triggered By: Started by user Sandro Bonazzola > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #141 > [Shani Leviim] Remove 'provisioned_size' disk parameter > > [Shirly Radco] ovirt-engine-metrics: add build-on-demand job > > > Changes for Build #142 > [Shani Leviim] Changed some parameters on 004_basic_sanity#add_disk test > > [Gil Shinar] Separate JJB deploy to project and template > > [Gil Shinar] Added upstream-source-collector to jjb deploy job > > > Changes for Build #143 > [Yaniv Kaul] Move disks to be ext4 based instead of XFS > > [Evgheni Dereveanchin] OVIRT-1451 - Add a CI mirror for Gluster 3.10 > > [Juan Hernandez] Fix branches of metamodel jobs > > [Eyal Edri] reduce experimental history to 14 > > > Changes for Build #144 > [Yaniv Kaul] Move disks to be ext4 based instead of XFS > > > > > ----------------- > Failed Tests: > ----------------- > 1 tests failed. > FAILED: 002_bootstrap.py.junit.xml.[empty] > > Error Message: > > > Stack Trace: > Test report file /home/jenkins/workspace/ovirt_master_hc-system-tests/ > exported-artifacts/002_bootstrap.py.junit.xml was length 0

3 2

[ovirt-engine] Question about engine-rename
by Tasdik Rahman 22 Jun '17

22 Jun '17

--_000_ED4D349FCF414C8AB4DCC4B7E6F60549outlookcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgd2FzIGdvaW5nIHRocm91Z2ggaHR0cHM6Ly93d3cub3ZpcnQub3JnL2RvY3Vt ZW50YXRpb24vaG93LXRvL25ldHdvcmtpbmcvY2hhbmdpbmctZW5naW5lLWhvc3RuYW1lLyBhbmQg d2FzIGdvaW5nIHRoZSB1dGlsaXR5IGNvbW1hbmQgd2hpY2ggaGVscHMgdG8gY2hhbmdlIHRoZSBl bmdpbmUtbmFtZS4gSSB3YXMgd29uZGVyaW5nIHdoYXQgdGhlIHBhcmFtZXRlcnMNCg0KDQotLW90 b3BpLWVudmlyb25tZW50PSJPU0VUVVBfUkVOQU1FL2ZvcmNlSWdub3JlQUlBSW5DQT1ib29sOidU cnVlJyBcDQogICAgIE9WRVNFVFVQX0NPUkUvZW5naW5lU3RvcD1ib29sOidUcnVlJyBcDQogICAg IE9TRVRVUF9SRU5BTUUvY29uZmlybUZvcmNlT3ZlcndyaXRlPWJvb2w6J0ZhbHNlJyINCg0KdG8g dGhlIHBvc2l0aW9uYWwgYXJndW1lbnQg4oCUb3RvcGktZW52aXJvbm1lbnQgd291bGQgbWVhbi4N Cg0KUmVnYXJkcywNClRhc2RpayBSYWhtYW4NCmh0dHA6Ly90YXNkaWtyYWhtYW4ubWUvDQoNCg0K DQo= --_000_ED4D349FCF414C8AB4DCC4B7E6F60549outlookcom_ Content-Type: text/html; charset="utf-8" Content-ID: <A897B103CEFF1D4AAF8908B72744D9D9(a)apcprd02.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8sJm5ic3A7DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHdhcyBnb2luZyB0 aHJvdWdoJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cub3ZpcnQub3JnL2RvY3VtZW50YXRpb24v aG93LXRvL25ldHdvcmtpbmcvY2hhbmdpbmctZW5naW5lLWhvc3RuYW1lLyIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cub3ZpcnQub3JnL2RvY3VtZW50YXRpb24vaG93LXRvL25ldHdvcmtpbmcvY2hhbmdp bmctZW5naW5lLWhvc3RuYW1lLzwvYT4mbmJzcDthbmQgd2FzIGdvaW5nIHRoZSB1dGlsaXR5IGNv bW1hbmQgd2hpY2gNCiBoZWxwcyB0byBjaGFuZ2UgdGhlIGVuZ2luZS1uYW1lLiBJIHdhcyB3b25k ZXJpbmcgd2hhdCB0aGUgcGFyYW1ldGVycyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJoaWdobGlnaHQg cGxhaW50ZXh0IiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgb3ZlcmZsb3c6IGF1dG87 IGZvbnQtZmFtaWx5OiBNZW5sbywgTW9uYWNvLCBDb25zb2xhcywgJ0NvdXJpZXIgTmV3JywgbW9u b3NwYWNlOyBmb250LXNpemU6IDExcHQ7IHBhZGRpbmc6IDhwdDsgbWFyZ2luLXRvcDogMHB4OyBt YXJnaW4tYm90dG9tOiA4LjVwdDsgbGluZS1oZWlnaHQ6IDEuNDI4NTc7IHdvcmQtYnJlYWs6IGJy ZWFrLWFsbDsgd29yZC13cmFwOiBicmVhay13b3JkOyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7IGJvcmRlcjogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLXRvcC1sZWZ0LXJhZGl1czogNHB4OyBib3JkZXItdG9w LXJpZ2h0LXJhZGl1czogNHB4OyBib3JkZXItYm90dG9tLXJpZ2h0LXJhZGl1czogNHB4OyBib3Jk ZXItYm90dG9tLWxlZnQtcmFkaXVzOiA0cHg7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1h bDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+PGNvZGUgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRl ci1ib3g7IGZvbnQtZmFtaWx5OiBNZW5sbywgTW9uYWNvLCBDb25zb2xhcywgJnF1b3Q7Q291cmll ciBOZXcmcXVvdDssIG1vbm9zcGFjZTsgZm9udC1zaXplOiBpbmhlcml0OyBwYWRkaW5nOiAwcHg7 IGNvbG9yOiBpbmhlcml0OyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgYm9yZGVyLXJh ZGl1czogMHB4OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IiBjbGFzcz0iIj4tLW90b3BpLWVudmly b25tZW50PSZxdW90O09TRVRVUF9SRU5BTUUvZm9yY2VJZ25vcmVBSUFJbkNBPWJvb2w6J1RydWUn Jm5ic3A7XA0KICAmbmJzcDsmbmJzcDsmbmJzcDtPVkVTRVRVUF9DT1JFL2VuZ2luZVN0b3A9Ym9v bDonVHJ1ZScmbmJzcDtcDQogICZuYnNwOyZuYnNwOyZuYnNwO09TRVRVUF9SRU5BTUUvY29uZmly bUZvcmNlT3ZlcndyaXRlPWJvb2w6J0ZhbHNlJyZxdW90OzwvY29kZT48L3ByZT4NCjxkaXYgY2xh c3M9IiI+dG8gdGhlIHBvc2l0aW9uYWwgYXJndW1lbnQg4oCUb3RvcGktZW52aXJvbm1lbnQgd291 bGQgbWVhbi4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NClJlZ2FyZHMsJm5ic3A7PC9kaXY+ DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiPg0KVGFzZGlrIFJhaG1hbjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 Ij4NCjxhIGhyZWY9Imh0dHA6Ly90YXNkaWtyYWhtYW4ubWUvIiBjbGFzcz0iIj5odHRwOi8vdGFz ZGlrcmFobWFuLm1lLzwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ED4D349FCF414C8AB4DCC4B7E6F60549outlookcom_--

2 1

Snapshots & clone support from datastore
by Deepak Jagtap 22 Jun '17

22 Jun '17

--_000_MWHPR11MB166305908F1E2918F9B3FE4AEDCB0MWHPR11MB1663namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey Guys, I am newbie to ovirt, and wanted to confirm whats the best way to leverage = snapshot, clone features provided by the datastore filesystem. I have a btrfs datastore exported and wanted use btrfs snapshots for vm sna= pshot & clones. Does ovirt offers any hooks/APIs so that image snapshots are created by the= filesystem? Thanks & Regards, Deepak --_000_MWHPR11MB166305908F1E2918F9B3FE4AEDCB0MWHPR11MB1663namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font= -family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr"> <p>Hey Guys,</p> <p><br> </p> <p>I am newbie to ovirt, and wanted to confirm whats the best way to levera= ge snapshot, clone features </p> <p>provided by the datastore filesystem.</p> <p>I have a btrfs datastore exported and wanted use btrfs snapshots fo= r vm snapshot & clones.</p> <p>Does ovirt offers any hooks/APIs so that image snapshots are created by = the filesystem?</p> <p><br> </p> <p>Thanks & Regards,</p> <p>Deepak</p> <p> </p> </div> </body> </html> --_000_MWHPR11MB166305908F1E2918F9B3FE4AEDCB0MWHPR11MB1663namp_--

5 10

rounding microseconds in vm conf update
by Valentina Makarova 22 Jun '17

22 Jun '17

Hello! Ovirt sdk process updating of vm template with rounding of microseconds in creation_time. And vm is marked as vm which has a newer configuration because of this, but there is not a new configuration, all difference between current configuration and next_run configuration is creation_time. It is not correct. For example, diff between curl get-request for this state of vm and next_run state is: [ovirt-system-tests]$ diff current_state.txt next_state.txt 55c55 < <creation_time>2017-06-14T06:18:03*.987*-04:00</creation_time> --- > <creation_time>2017-06-14T06:18:03*.000*-04:00</creation_time> 76a77 And example how to request update for reach rounding is a test in ovirt_system_test: @ovirtlago.testlib.with_ovirt_api def update_round(api): vm = api.vms.get('vm0') #there vm.creation_time.isoformat() is a real datetime with microseconds vm.update() #after this vm.creation_time.isoformat() contains a real datetime with microseconds, #but vm becames vm with newer configuration and # next_run creation time becomes rounded to seconds Does anyone have idea how to fix this? Sincerely, Valentina Makarova

2 1

Re: [ovirt-devel] help with building a package with Copr
by Eyal Edri 22 Jun '17

22 Jun '17

Adding also devel list, I think there are some maintainers who build in copr. On Thu, Jun 22, 2017 at 6:23 AM, Marc Dequènes (Duck) <duck(a)redhat.com> wrote: > Quack, > > So my project is here: > https://copr.fedorainfracloud.org/coprs/duck/PostSRSd/build/568647/ > In the SCM URL I've got the spec file. > > I built this package on a CentOS 7.3 VM successfully and it currently > works well in production. > > On Copr I've got this error: > > https://copr-be.cloud.fedoraproject.org/results/ > duck/PostSRSd/epel-7-x86_64/00568647-postsrsd/build.log.gz > > So I made a small change (second commit) to try to make things simpler > just in case but it does not work better. > > So I'm at a loss. Could someone give a hand please? > \_o< > > > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > > -- Eyal edri ASSOCIATE MANAGER RHV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

2 1

Lowering the bar for wiki contribution?
by Roy Golan 22 Jun '17

22 Jun '17

I'm getting the feeling I'm not alone in this, authoring and publishing a wiki page isn't as used to be for long time. I want to suggest a bit lighter workflow: 1. Everyone can merge their page - (it's a wiki) Same as with (public and open) code, no one has the motivation to publish a badly written wiki page under their name. True, it can have an impact, but not as with broken code 2. Use Page-Status marker The author first merges the draft. Its now out there and should be updated as time goes and its status is DRAFT. Maintainers will come later and after review would change the status to PUBLISH. That could be a header in on the page: --- page status: DRAFT/PUBLISH --- Simple I think, and should work.

14 23

dnf issue on FC24/25 slaves
by Gil Shinar 21 Jun '17

21 Jun '17

Today we have encountered a dnf issue on all of our FC24/25 slaves. It affected all Jenkins jobs that are running on these slaves. If you see this error message: *system-python: /builddir/build/BUILD/hawkey-0.6.3/src/sack.c:354: load_ext: Assertion `ret == 0' failed* please be patient. We are working to solve this issue in the next couple of minutes. It was basically a fedora mirror issue. They have a bug on it but looks like they have already fixed it. Thanks Gil

1 1

ovirt-node-ng-installer-master-2017062004 is missing the Updates repository.
by Mike Hulsman 20 Jun '17

20 Jun '17

------=_Part_53379_1338138929.1497963607312 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I installed the ovirt-node-ng-installer-master-2017062004.iso and tried to create a host from within a Ovirt-engine. I got the error: Failed to install Host node01. Yum Cannot queue package qemu-kvm-tools: Package qemu-kvm-tools cannot be found. The solution for this problem is to enable the updates in the /etc/yum.repos.d/CentOS-Base.repo file. I also see that the base repo is also disabled. Regards, Mike Hulsman Proxy Managed Services B.V. | www.proxy.nl | Enterprise IT-Infra, Open Source and Cloud Technology Delftweg 128 3043 NB Rotterdam The Netherlands | +31 10 307 0965 ------=_Part_53379_1338138929.1497963607312 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: Arial, Helvetica, sans-serif; font-s= ize: 12pt; color: #000000"><div>I installed the ovirt-node-ng-installer-mas= ter-2017062004.iso and tried to create a host from within a Ovirt-engine.<b= r></div><div>I got the error: Failed to install Host node01. Yum Cannot que= ue package qemu-kvm-tools: Package qemu-kvm-tools cannot be found.<br data-= mce-bogus=3D"1"></div><div><br data-mce-bogus=3D"1"></div><div>The solution= for this problem is to enable the updates in the /etc/yum.repos.d/CentOS-B= ase.repo file.<br data-mce-bogus=3D"1"></div><div><br data-mce-bogus=3D"1">= </div><div>I also see that the base repo is also disabled.<br data-mce-bogu= s=3D"1"></div><div><br data-mce-bogus=3D"1"></div><div><br></div><div data-= marker=3D"__SIG_PRE__">Regards, <br><br>Mike Hulsman<br><br>Proxy Managed S= ervices B.V. | www.proxy.nl | Enterprise IT-Infra, Open Source and Cloud Te= chnology<br>Delftweg 128 3043 NB Rotterdam The Netherlands | +31 10 307 096= 5</div></div></body></html> ------=_Part_53379_1338138929.1497963607312--

1 0

[ OST Failure Report ] [ oVirt master ] [ 19/06/17 ] [ add_secondary_storage_domains ]
by Gil Shinar 20 Jun '17

20 Jun '17

Test failed: 002_bootstrap.add_secondary_storage_domains Link to suspected patches: Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/7264 Link to all logs: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/7264/artif… Error snippet from the log: Host 0: 2017-06-19 08:46:48,457-0400 WARN (jsonrpc/1) [storage.HSM] getPV failed for guid: 360014050f775dd654404bd39d061693c (hsm:1928) Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 1925, in _getDeviceList pv = lvm.getPV(guid) File "/usr/lib/python2.7/site-packages/vdsm/storage/lvm.py", line 852, in getPV raise se.InaccessiblePhysDev((pvName,)) InaccessiblePhysDev: Multipath cannot access physical device(s): "devices=(u'360014050f775dd654404bd39d061693c',)" 2017-06-19 08:46:48,546-0400 WARN (jsonrpc/1) [storage.LVM] lvm pvs failed: 5 [] [' Failed to find physical volume "/dev/mapper/360014050fae4a3a8e8047e6933531876".'] (lvm:322) 2017-06-19 08:46:48,546-0400 WARN (jsonrpc/1) [storage.HSM] getPV failed for guid: 360014050fae4a3a8e8047e6933531876 (hsm:1928) Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 1925, in _getDeviceList pv = lvm.getPV(guid) File "/usr/lib/python2.7/site-packages/vdsm/storage/lvm.py", line 852, in getPV raise se.InaccessiblePhysDev((pvName,)) InaccessiblePhysDev: Multipath cannot access physical device(s): "devices=(u'360014050fae4a3a8e8047e6933531876',)" Host 1: *2017-06-19 08:49:03,151-0400 ERROR (monitor/b92f872) [storage.Monitor] Setting up monitor for b92f8727-8c51-4e12-a3fe-5441531c13ca failed (monitor:329) Traceback (most recent call last): File "/usr/share/vdsm/storage/monitor.py", line 326, in _setupLoop self._setupMonitor() File "/usr/share/vdsm/storage/monitor.py", line 348, in _setupMonitor self._produceDomain() File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 237, in wrapper value = meth(self, *a, **kw) File "/usr/share/vdsm/storage/monitor.py", line 366, in _produceDomain self.domain = sdCache.produce(self.sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 108, in produce domain.getRealDomain() File "/usr/share/vdsm/storage/sdc.py", line 49, in getRealDomain return self._cache._realProduce(self._sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 132, in _realProduce domain = self._findDomain(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 149, in _findDomain return findMethod(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 174, in _findUnfetchedDomain raise se.StorageDomainDoesNotExist(sdUUID) StorageDomainDoesNotExist: Storage domain does not exist: (u'b92f8727-8c51-4e12-a3fe-5441531c13ca',)*

3 3

Heads up: VdcAction* classes names have been changed
by Tal Nisan 20 Jun '17

20 Jun '17

Hi all, I've merged patches to change the legacy name "VdcAction*" to "Action*", the Vdc prefix is here from long time ago and doesn't make much sense anymore (if it ever did). Please make sure you rebase your patches before submitting and make sure CI passes again even if it passed before rebasing. Changed classes are: VdcActionType -> ActionType VdcActionTypeDeserializer -> ActionTypeDeserializer VdcActionParametersBase -> ActionParametersBase VdcActionUtils -> ActionUtils Thanks for the reviewers that helped review those long and boring patches (amureini, masayah, frolland, ishaby, awels, gsheremeta, oourfali) Next up on my list is VdcQuery*, stay tuned :)

3 2