- Devel - oVirt List Archives

vdsm libs dependencies
by Pavel Gashev 11 Jun '17

11 Jun '17

--_000_3ECE0CC4CC784D5C8DE6B77CDA7F189Aacroniscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IGRlcGVuZGVuY2llcyBvZiB2ZHNtIGxp YnJhcmllcy4gQ291bGQgc29tZWJvZHkgc3VnZ2VzdCBob3cgSSBjYW4gdXNlIHZkc20ubmV0d29y ay5pcHdyYXBwZXIgZnJvbSB2ZHNtLnN0b3JhZ2U/DQoNClNwZWNpZmljYWxseSwgSSBuZWVkIGEg d2F5IHRvIGRldGVybWluZSB0aGF0IGFuIElQIGFkZHJlc3Mgb2YgTkZTIHBhdGggaXMgbG9jYWwu IFRoZSByaWdodCB3YXkgdG8gZGV0ZXJtaW5lIHRoYXQgaXMgYXMgc2ltcGxlIGFzIHRoZSBmb2xs b3dpbmc6DQoNCiMgL3NiaW4vaXAgcm91dGUgZ2V0IFguWC5YLlggfCBncmVwIC1xIF5sb2NhbCAm JiBlY2hvIElQIGlzIGxvY2FsDQoNClRoaXMgaXMgd2h5IEkgbmVlZCB0byB1c2UgdmRzbS5uZXR3 b3JrLmlwd3JhcHBlci4gU2VlIGRldGFpbHMgYXQgaHR0cHM6Ly9nZXJyaXQub3ZpcnQub3JnLyMv Yy82ODgyMi8NCg0KVGhhbmtzDQoNCg== --_000_3ECE0CC4CC784D5C8DE6B77CDA7F189Aacroniscom_ Content-Type: text/html; charset="utf-8" Content-ID: <77AD686C8113B2458D846577C397B4F2(a)acronis.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjIuMGNtIDQyLjVw dCAyLjBjbSAzLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0Ii IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGhhdmUgYSBxdWVzdGlvbiBhYm91dCBk ZXBlbmRlbmNpZXMgb2YgdmRzbSBsaWJyYXJpZXMuIENvdWxkIHNvbWVib2R5IHN1Z2dlc3QgaG93 IEkgY2FuIHVzZSB2ZHNtLm5ldHdvcmsuaXB3cmFwcGVyIGZyb20gdmRzbS5zdG9yYWdlPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5TcGVjaWZpY2FsbHksIEkgbmVlZCBhIHdheSB0byBkZXRlcm1pbmUgdGhhdCBhbiBJ UCBhZGRyZXNzIG9mIE5GUyBwYXRoIGlzIGxvY2FsLiBUaGUgcmlnaHQgd2F5IHRvIGRldGVybWlu ZSB0aGF0IGlzIGFzIHNpbXBsZSBhcyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4jIC9zYmlu L2lwIHJvdXRlIGdldCBYLlguWC5YIHwgZ3JlcCAtcSBebG9jYWwgJmFtcDsmYW1wOyBlY2hvIElQ IGlzIGxvY2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoaXMgaXMgd2h5IEkgbmVlZCB0byB1c2UgdmRzbS5uZXR3 b3JrLmlwd3JhcHBlci4gU2VlIGRldGFpbHMgYXQNCjxhIGhyZWY9Imh0dHBzOi8vZ2Vycml0Lm92 aXJ0Lm9yZy8jL2MvNjg4MjIvIj5odHRwczovL2dlcnJpdC5vdmlydC5vcmcvIy9jLzY4ODIyLzwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3ECE0CC4CC784D5C8DE6B77CDA7F189Aacroniscom_--

4 6

GWT symbol maps are now installed with Engine, the "debuginfo" packages are out
by Vojtech Szocs 09 Jun '17

09 Jun '17

Hello everyone, in master [1] and 4.1 [2] branches, meaningful (de-obfuscated) GWT/Java stack traces are now available right after Engine installation or upgrade. There's no need to install the complementary "debuginfo" packages anymore. In fact, those packages are removed now. (If installed, please remove them manually before upgrading Engine.) Please refer to commit msg for details. [1] https://gerrit.ovirt.org/#/c/75420 [2] https://gerrit.ovirt.org/#/c/77892/ Regards, Vojtech

4 5

ovirt engine in docker container
by Petr Kotas 08 Jun '17

08 Jun '17

Hi all, I am containerizing the ovirt engine with docker and docker-compose. Does anybody tried something similar? I would like to share knowledge and build universal dev environment to easier our lives. Thanks :) Petr Kotas

2 1

outage alert: Gerrit.ovirt.org is down
by Eyal Edri 08 Jun '17

08 Jun '17

FYI, Gerrit.ovirt.org which is hosted on Amazon seems to be not responding, we're investigating the issue and will report shortly once we identify the problem. oVirt 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)

1 1

[ OST Failure Report ] [ oVirt master ] [ 06-06-2017 ] live_storage_migration
by Evgheni Dereveanchin 08 Jun '17

08 Jun '17

Hi, We have the following test failing on master: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/7050/testR… Stack trace from engine.log: 2017-06-06 12:15:13,150-04 ERROR [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateDiskCommand] (DefaultQuartzScheduler2) [2b9829cc-1fce-47c8-93d8-c97b5531c930] Error during ValidateFailure.: java.lang.IllegalArgumentException: Cannot validate operation on disk for action of type LiveMigrateDisk as it is not an allowed command for the disk content type. at org.ovirt.engine.core.bll.validator.storage.DiskOperationsValidator.isOperationAllowedOnDisk(DiskOperationsValidator.java:34) [bll.jar:] at org.ovirt.engine.core.bll.storage.disk.MoveOrCopyDiskCommand.checkOperationAllowedOnDiskContentType(MoveOrCopyDiskCommand.java:187) [bll.jar:] at org.ovirt.engine.core.bll.storage.disk.MoveOrCopyDiskCommand.validate(MoveOrCopyDiskCommand.java:144) [bll.jar:] at org.ovirt.engine.core.bll.storage.lsm.LiveMigrateDiskCommand.validate(LiveMigrateDiskCommand.java:360) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.internalValidate(CommandBase.java:849) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:403) [bll.jar:] ... Suspect patches: https://gerrit.ovirt.org/#/c/77521/ https://gerrit.ovirt.org/#/c/77452/ full engine.log: http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper… first failing job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/7050/ -- Regards, Evgheni Dereveanchin

2 1

Need Support to fix oVirt Engine - Fails to start engine VM
by Rizwan Qureshi 08 Jun '17

08 Jun '17

--_000_LOXP123MB106111E7C95DE5E4C1CE0364EDC90LOXP123MB1061GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Developers, We are new to ovirt developers list, infact new to oVirt also. We unfortuna= tely managed to break our oVirt installation. The engine VM does not seem t= o start after we updated to 4.0 from 3.6 and did a restart. We are looking for someone specialized to fix this kind of issues. I have f= ailed to find anyone who provides support for oVirt so resorting to the dev= elopers list now. Already tried using the users list and someone did try to= help but could not get it to work. You can see the thread below for refere= nce and logs that I posted: http://lists.ovirt.org/pipermail/users/2017-May/082309.html Can anyone help please? -- Best Regards, Rizwan Qureshi VoIP Admin Ph: 01482427836 --_000_LOXP123MB106111E7C95DE5E4C1CE0364EDC90LOXP123MB1061GBRP_ 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"> Hello Developers,<o:p></o:p> We are new to ovirt developers list, infact new to o= Virt also. We unfortunately managed to break our oVirt installation. The en= gine VM does not seem to start after we updated to 4.0 from 3.6 and did a r= estart.<o:p></o:p> <o:p> </o:p> We are looking for someone specialized to fix this k= ind of issues. I have failed to find anyone who provides support for oVirt = so resorting to the developers list now. Already tried using the users list= and someone did try to help but could not get it to work. You can see the thread below for reference and logs th= at I posted:<o:p></o:p> <o:p> </o:p> <a href=3D"http://lists.ovirt.org/pipermail/users/20= 17-May/082309.html">http://lists.ovirt.org/pipermail/users/2017-May/082309.= html</a><o:p></o:p> <o:p> </o:p> Can anyone help please?<o:p></o:p> <o:p> </o:p> --<o:p></o:p> Best Regards,<o:p></o:p>= Rizwan Qureshi<o:p></o:p></span= > VoIP Admin<o:p></o:p></p= > Ph: 01482427836<o:p></o:p></spa= n> <o:p> </o:p> </div> </body> </html> --_000_LOXP123MB106111E7C95DE5E4C1CE0364EDC90LOXP123MB1061GBRP_--

2 1

Who cares about 'memGuaranteedSize'?
by Francesco Romani 08 Jun '17

08 Jun '17

Hi all, We have this field in the Vdsm API: - description: The amount of memory guaranteed to the VM in MB name: memGuaranteedSize type: uint Available in VmDefinition, VMFullInfo, VmParameters Vdsm dutifully records and reports this value - but doesn't use it. It is used exactly once for balloon stata: stats['balloonInfo'].update({ 'balloon_max': str(max_mem), 'balloon_min': str( int(vm.conf.get('memGuaranteedSize', '0')) * 1024), 'balloon_cur': str(balloon_cur), 'balloon_target': str(balloon_target) }) Now, a quick git grep in both MOM and Engine reveals no obvious usages. Am I missing something? Can we drop this for 4.2, and deprecate it in next(4.1) ? Thanks, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

2 1

[ OST Failue Report ] [ oVirt master ] [ 7/6/17 ] engine upgrade: 001_upgrade_engine
by Daniel Belenky 07 Jun '17

07 Jun '17

Hi all, oVirt engine upgrade test failed. Version failing: upgrade from 4.1 to master | upgrade from 4.0 to master Link to failed job: test-repo_ovirt_experimental_master/7091/ <http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/7091/> Link to suites logs: logs <http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/7091/artif…> Suspected patch: Gerrit 77254: packaging: ovirt-provider-ovn password must not be empty by default <https://gerrit.ovirt.org/#/c/77254/> Potential fix(es): [1] 77934: Add ovirtProviderOvnPassword to the answer file <https://gerrit.ovirt.org/#/c/77934/> [2] 77975: Update upgrade engine answer-file with ovirtProviderOvnPassword <https://gerrit.ovirt.org/#/c/77975/> iIt seems that though the answer file includes the ovn password, engine-setup ignores it. Can anyone provide more info/actions can be done in order to fix this issue? Thanks, -- DANIEL BELENKY Associate sw engineer RHEV DEVOPS Red Hat Israel <https://www.redhat.com/> dbelenky(a)redhat.com IRC: #rhev-integ, #rhev-dev <https://red.ht/sig>

1 0

Re: [ovirt-devel] Making event types backwards compatible?
by Michal Skrivanek 07 Jun '17

07 Jun '17

> On 29 May 2017, at 11:44, Juan Hernández <jhernand(a)redhat.com> wrote: > >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote: >> >>> On 29 May 2017, at 10:39, Juan Hernández <jhernand(a)redhat.com> wrote: >>> >>> Hello, >>> >>> It has been recently requested that the API provides event types: >>> >>> [RFE] Expose event types to API >>> https://bugzilla.redhat.com/1453170 >>> >>> Currently the API provides the event code and description, for example: >>> >>> <event href="/ovirt-engine/api/events/8021" id="8021"> >>> <code>19</code> >>> <description>Host myhost failed to recover.</description >>> ... >>> </event> >>> >>> There is no documentation of what is the meaning of codes, except the >>> source code of the engine itself. This forces some applications to add >>> their own code to name mapping. For example, the 'ovirt' Ruby gem used >>> by older versions of ManageIQ to interact with oVirt contains the following: >>> >>> https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485 >>> >>> We could avoid this by adding to the API a new event attribute that >>> indicates the type: >>> >>> <event href="/ovirt-engine/api/events/8021" id="8021"> >>> <code>19</code> >>> <type>host_recover_failure</type> >>> <description>Host myhost failed to recover.</description> >>> ... >>> </event> >>> >>> Ideally this should be defined as an enum, so that it will be >>> represented as an enum in the SDKs. Alternatively it could just be an >>> string, and we could reuse the 'name' attribute: >>> >>> <event href="/ovirt-engine/api/events/8021" id="8021"> >>> <code>19</code> >>> <name>host_recover_failure</name> >>> <description>Host myhost failed to recover.</description> >>> ... >>> </event> >>> >>> However, the key point to making this useful would be to keep the types >>> (or names) backwards compatible, so that users of the API can rely on >>> their values and meanings. >>> >>> So this is my question to you: can we commit to keep the names and >>> meanings of the backend event types backwards compatible? >> >> Do we even have to make it bw compatible? >> I guess it depends on the actual usage of those names… >> The ovirt ruby gem itself doesn’t do much with it > > We need to make keep it backwards compatible or else tell users "don't > rely on these values, as they may change without notice". > > The 'ovirt' gem doesn't do anything special, it just creates its own > code to name mapping. But the users of the 'ovirt' gem (the ManageIQ > oVirt provider) do rely on the name. For example: > > > https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models… > > That means that if we ever change the meaning of a code the ManageIQ > provider, for example, will break. Right,then it indeed needs to stay stable. But how is maintaining the enum string different from the code? It is the same information, so if MIQ doesn't use the name directly then it doesn't really matter if it's a code or string. Perhaps deprecate the code and keep the name fixed? Thanks, michal > >>> >>> Regards, >>> Juan Hernandez >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >

4 6

[ovirt-system-tests] ssh to an oVirt VM in Lago
by Valentina Makarova 06 Jun '17

06 Jun '17

Hello! Please, help me to find way to execute some command in oVirt VM. Is it possible to get ssh connection to non-host VM in LAGO? And how can I get ssh connection through the console in my computer? I installed ovirt-system-tests and run tests from basic-suite-master. So there is 2 hosts and 3 vms in my configuration. And I want to execute command inside the vm0 using LAGO (as part of my own test). It is easy for host vm and engine, there is method ''ssh" in ovirt-engine-api-model. And this task for host vm can be performed as there prefix.virt_env.get_vm(VM_NAME).ssh(['bash_command_what_i_want']) Please give me advice, can Iget connection to vm0 in a similar way? And a second question is about ssh to this vm connection from my laptop's console. According run_vm test from 004_basic_sanity.py ( https://github.com/oVirt/ovirt-system-tests/blob/master/basic-suite-master/… ) vm0 should contain interface with ip 192.168.200.200, but ping this from engine (192.168.200.4) Destination Host Unreachable. And 'ping vm0' defined vm0 as 192.168.201.213 and also couldn't reach vm0. And in webadmin (https://engine/ovirt-engine/webadmin/#vms) IP Address field is empty. What is a right way to get connection to vm0 console and execute some command there? Sincerely, Valentina Makarova

5 7