- Users - oVirt List Archives

moVirt 2.0 released!
by Filip Krepinsky 30 Jun '17

30 Jun '17

Hello everyone, moVirt 2.0 has just been released and should arrive to your devices soon! You can also get the apk from our GitHub [1]. The main feature of this release is managing multiple oVirt installations + many other cool features [2]. Thanks everybody who helped with testing and especially big thanks to Shira who gave us lots of valuable input. Have a nice day Filip [1]: https://github.com/oVirt/moVirt/releases/tag/v2.0 [2]: https://github.com/oVirt/moVirt/wiki/Changelog

1 0

Help! No VMs start after reboot of cluster
by cmc 30 Jun '17

30 Jun '17

Hi, I restarted my 3 host cluster after setting it into global maintenance mode and then shutting down all of the nodes and then bringing them up again. I moved it out of global maintenance mode and no VM is running, including the hosted engine. Any help greatly appreciated! Thanks, Cam

3 5

Re: [ovirt-users] Frustration defines the deployment of Hosted Engine
by Karli Sjöberg 30 Jun '17

30 Jun '17

11 16

vm shutdown long delay is a problem for users of pools
by Paul 30 Jun '17

30 Jun '17

This is a multipart message in MIME format. ------=_NextPart_000_0079_01D2EB83.89CE5690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Shutting down VM's in the portal with the red downfacing arrow takes quite some time (about 90 seconds). I read this is mainly due to a 60 second delay in the ovirt-guest-agent. I got used to right-click and use "power off" instead of "shutdown", which is fine. My users make use of VM in a VM-pool. They get assigned a VM and after console disconnect the VM shuts down (default recommended behavior). My issue is that the users stays assigned to this VM for the full 90 seconds and cannot do "power off". Suppose he disconnected by accident, he has to wait 90 seconds until he is assigned to the pool again until he can connect to another VM. My questions are: - Is it possible to decrease the time delay of a VM shutdown? 90 seconds is quite a lot, 10 seconds should be enough - Is it possible for normal users to use "power off"? - Is it possible to "unallocate" the user from a VM if it is powering down? So he can allocate another VM Kind regards, Paul ------=_NextPart_000_0079_01D2EB83.89CE5690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 15 = (filtered medium)"><style></style></head><body lang=3DNL = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1>Hi,<o:p></o:p>Shutting = down VM’s in the portal with the red downfacing arrow takes quite = some time (about 90 seconds). I read this is mainly due to a 60 second = delay in the ovirt-guest-agent. I got used to right-click and use = “power off” instead of “shutdown”, which is = fine.<o:p></o:p><o:p> </o:p>My users = make use of VM in a VM-pool. They get assigned a VM and after console = disconnect the VM shuts down (default recommended behavior). My issue is = that the users stays assigned to this VM for the full 90 seconds and = cannot do “power off”. Suppose he disconnected by accident, = he has to wait 90 seconds until he is assigned to the pool again until = he can connect to another VM. <o:p></o:p><o:p> </o:p>My = questions are:<o:p></o:p><![if = !supportLists]>-          = <![endif]>Is it possible to decrease the time delay of a = VM shutdown? 90 seconds is quite a lot, 10 seconds should be = enough<o:p></o:p><![if = !supportLists]>-          = <![endif]>Is it possible for normal users to use = “power off”?<o:p></o:p><![if !supportLists]>-          = <![endif]>Is it possible to “unallocate” the = user from a VM if it is powering down? So he can allocate another = VM<o:p></o:p><o:p> </o:p>Kind = regards,<o:p></o:p><o:p> </o:p>Paul<o:p></o:p></div></body></html> ------=_NextPart_000_0079_01D2EB83.89CE5690--

3 3

Unable to rename disks via REST API
by Bruno Rodriguez 30 Jun '17

30 Jun '17

Hello everyone, I'm having some problems about renaming some disks (setting a different alias, name or description) for VMs disks created from a template. When I get this URL https://ovirt-manager/ovirt-engine/api/disks/0123 I can see are the methods sparsify, export, move and copy. I tried to POST the following XML to the previous URL with no result (as expected, it won't work) <disk> <alias>my_machine_Disk1</alias> </disk> I'm quite sure I'm thinking about it in a wrong way (as usual). Any help would be welcome... Thank you in advance -- Bruno Rodríguez Rodríguez *Port d'Informació Científica (PIC)*

3 9

[ANN] oVirt 4.1.3 Third Release Candidate is now available
by Sandro Bonazzola 29 Jun '17

29 Jun '17

The oVirt Project is pleased to announce the availability of the Third Release Candidate of oVirt 4.1.3 for testing, as of June 22nd, 2017 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 update is the first release candidate of the third in a series of stabilization updates to the 4.1 series. 4.1.3 brings more than 45 enhancements and more than 220 bugfixes, including more than 120 high or urgent severity fixes, on top of oVirt 4.1 series This release is available now for: * Fedora 24 (tech preview) * Red Hat Enterprise Linux 7.3 or later * CentOS Linux (or similar) 7.3 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.3 or later * CentOS Linux (or similar) 7.3 or later * oVirt Node 4.1 * Fedora 24 (tech preview) See the release notes draft [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Live is already available[4] - oVirt Node is already available[4] We are addressing compose issues for above components which are missing ansible 2.3 and latest fluentd builds from CentOS SIGs. Additional Resources: * Read more about the oVirt 4.1.3 release highlights: http://www.ovirt.org/release/4.1.3/ * 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.1.3/ [4] resources.ovirt.org/pub/ovirt-4.1-pre/iso/ -- 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>

2 2

moVirt 2.0 RC 1 released!
by Filip Krepinsky 29 Jun '17

29 Jun '17

Hia, the first RC of moVirt 2.0 has been released! You can get it from our GitHub [1]; the play store will be upgraded after considered stable. The main feature of this release is a support for managing multiple oVirt installations from one moVirt. Other changes: - actions/lists/dashboard are now filtered by selecting accounts/clusters in the left drawer - event lists now correctly working for single vm, host, etc.. - better syncing and network detection - cleaner ui design and connection settings - enhanced security and support for certificates (import from file) - sorting and filtering made more usable - more descriptive errors - other small enhancements and bug fixes We would greatly appreciate if you could try it and share your feedback with us. [2] Let us know about any suggestions you might have; and as usual, patches are also welcome :) Have a great day Filip [1]: https://github.com/oVirt/moVirt/releases/download/v2.0-rc1/moVirt-release.a… [2]: https://github.com/oVirt/moVirt

4 5

Moving thin provisioned disks question
by Gianluca Cecchi 29 Jun '17

29 Jun '17

Hello, I have a storage domain that I have to empty, moving its disks to another storage domain, Both source and target domains are iSCSI What is the behavior in case of preallocated and thin provisioned disk? Are they preserved with their initial configuration? Suppose I have one 500Gb thin provisioned disk Why can I indirectly see that the actual size is 300Gb only in Snapshots tab --> Disks of its VM ? Thanks, Gianluca

4 10

Ovirt installation planning question
by Alan Bunch 28 Jun '17

28 Jun '17

--_000_C46E817F004EDF47A188C55D2DB37A84031354DcExchMX3Altourlo_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCB0aGUgaW5pdGlhbCBzZXR1cCBm b3Igb3ZpcnQuIEkgaGF2ZSAzIG5vZGVzDQp0aGF0IEkgYW0gYWJvdXQgcmVhZHkgdG8gaW5zdGFs bCBhIGh5cGVyIGNvbnZlcmdlZCBzZXR1cCB1c2luZyBHbHVzdGVyDQpmb3Igc3RvcmFnZSBhbmQg aG9zdGVkLWVuZ2luZS4NCg0KTXkgcXVlc3Rpb24gaXMgdGhpczoNCg0KV2hhdCBkb2VzIHRoZSBu ZXR3b3JraW5nIHNldHVwIG5lZWQgdG8gbG9vayBsaWtlIGF0IGluc3RhbGwgdGltZSA/IERvDQpJ IG5lZWQgdG8gc2V0dXAgYWxsIG9mIHRoZSBib25kcywgdmxhbnMgYW5kIGJyaWRnZXMgYmVmb3Jl IEkgc3RhcnQgdGhlIGluc3RhbGwNCm9yIHNob3VsZCBJIGp1c3Qgc2V0IGFuIG92aXJ0bWdtdCBi b25kL3ZsYW4vYnJpZGdlIGFuZCBzZXR1cCB0aGUgcmVzdCBvZiB0aGUNCm5ldHdvcmtpbmcgaW5z aWRlIG9mIG92aXJ0LiBJIGV4cGVjdCB0byBuZWVkIDMgb3IgNCBuZXR3b3Jrcy92bGFuIHRvIG1h dGNoDQpteSBleGlzdGluZyBuZXR3b3JrcyB0byBhdHRhY2ggdm0ncyB0by4NCg0KQW55IGhlbHAg b3IgcG9pbnRlcnMgd291bGQgYmUgYXBwcmVjaWF0ZWQuDQoNClRoYW5rIFlvdQ0K77u/DQo= --_000_C46E817F004EDF47A188C55D2DB37A84031354DcExchMX3Altourlo_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNh Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K c3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6 d2hpdGUiPkhlbGxvIGFsbCw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjxz cGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIGhhdmUgYSBxdWVzdGlvbiBhYm91dCB0aGUg aW5pdGlhbCBzZXR1cCBmb3Igb3ZpcnQuIEkgaGF2ZSAzIG5vZGVzPC9zcGFuPjxicj4NCjxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj50aGF0IEkgYW0gYWJvdXQgcmVhZHkgdG8gaW5zdGFs bCBhIGh5cGVyIGNvbnZlcmdlZCBzZXR1cCB1c2luZyBHbHVzdGVyPC9zcGFuPjxicj4NCjxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5mb3Igc3RvcmFnZSBhbmQgaG9zdGVkLWVuZ2luZS48 L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk15IHF1ZXN0 aW9uIGlzIHRoaXM6PC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj5XaGF0IGRvZXMgdGhlIG5ldHdvcmtpbmcgc2V0dXAgbmVlZCB0byBsb29rIGxpa2UgYXQg aW5zdGFsbCB0aW1lID8gRG88L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPkkgbmVlZCB0byBzZXR1cCBhbGwgb2YgdGhlIGJvbmRzLCB2bGFucyBhbmQgYnJpZGdlcyBi ZWZvcmUgSSBzdGFydCB0aGUgaW5zdGFsbDwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+b3Igc2hvdWxkIEkganVzdCBzZXQgYW4gb3ZpcnRtZ210IGJvbmQvdmxhbi9i cmlkZ2UgYW5kIHNldHVwIHRoZSByZXN0IG9mIHRoZTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+bmV0d29ya2luZyBpbnNpZGUgb2Ygb3ZpcnQuIEkgZXhwZWN0IHRv IG5lZWQgMyBvciA0IG5ldHdvcmtzL3ZsYW4gdG8gbWF0Y2g8L3NwYW4+PGJyPg0KPHNwYW4gc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPm15IGV4aXN0aW5nIG5ldHdvcmtzIHRvIGF0dGFjaCB2bSdz IHRvLjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+QW55 IGhlbHAgb3IgcG9pbnRlcnMgd291bGQgYmUgYXBwcmVjaWF0ZWQuPC9zcGFuPjxicj4NCjxicj4N CjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5UaGFuayBZb3U8L3NwYW4+PGJyPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6d2hpdGUiPu+7vzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C46E817F004EDF47A188C55D2DB37A84031354DcExchMX3Altourlo_--

1 0

Re: [ovirt-users] [ansible/ansible] ovirt_storage_domains can not find iscsi disk during creation (state: present) (#25417)
by victor 600833 28 Jun '17

28 Jun '17

Hi ondra, As you pointed. in your previous mail. The iscsiadm discovered througth 10.11.8.190. It should have probed 10.10.1.1. This may be the root cause. Victor, If you lookup at our playbook. - name: create iscsi_dsk02 ovirt_storage_domains: auth: url: https://rhevm2.res1/ovirt-engine/api token: "{{ ovirt_auth.token }}" insecure: True name: iscsi_dsk02 domain_function: data host: pdx1cr207 data_center: default iscsi: target: iqn.2017-06.stet.iscsi.server:target address: *10.10.1.1* lun_id: 3600140550738b53dd774303bfedac122 state: absent destroy: true register: res_iscsi_dsk02 - debug: var: res_iscsi_dsk02 On Wed, Jun 28, 2017 at 7:58 AM, Ondra Machacek <notifications(a)github.com> wrote: > It's using the host, which you will pass as host parameter to the task > for iscsi discover. > > As Yaniv said, can you please share your issue on our mailing list: > > users(a)ovirt.org > > There are people with knowledge of iSCSI and they will help you. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/ansible/ansible/issues/25417#issuecomment-311563987>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AScoAyV364pDjqXtCPSNodvhE…> > . >

2 2