- Users - oVirt List Archives

[ANN] oVirt 4.2.0 Second Beta Release is now available for testing
by Sandro Bonazzola 29 Nov '17

29 Nov '17

The oVirt Project is pleased to announce the availability of the Second Beta Release of oVirt 4.2.0, as of November 15th, 2017 This is pre-release software. This pre-release should not to be used in production. Please take a look at our community page[1] to learn how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This update is the second beta release of the 4.2.0 version. This release brings more than 240 enhancements and more than one thousand bug fixes, including more than 430 high or urgent severity fixes, on top of oVirt 4.1 series. What's new in oVirt 4.2.0? - The Administration Portal has been completely redesigned using Patternfly, a widely adopted standard in web application design. It now features a cleaner, more intuitive design, for an improved user experience. - There is an all-new VM Portal for non-admin users. - A new High Performance virtual machine type has been added to the New VM dialog box in the Administration Portal. - Open Virtual Network (OVN) adds support for Open vSwitch software defined networking (SDN). - oVirt now supports Nvidia vGPU. - The ovirt-ansible-roles package helps users with common administration tasks. - Virt-v2v now supports Debian/Ubuntu based VMs. For more information about these and other features, check out the oVirt 4.2.0 blog post <https://ovirt.org/blog/2017/11/introducing-ovirt-4.2.0-beta/>. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later * oVirt Node 4.2 (available for x86_64 only) 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. - An async release of oVirt Node will follow soon. Additional Resources: * Read more about the oVirt 4.2.0 release highlights: http://www.ovirt.org/release/4.2.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.2.0/ [4] http://resources.ovirt.org/pub/ovirt-4.2-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> <http://www.teraplan.it/redhat-osd-2017/>

2 1

please test UI plugins in 4.2 beta
by Greg Sheremeta 29 Nov '17

29 Nov '17

Hi everyone, [I should have sent this message sooner -- apologies, and thanks to Martin Sivak for the reminder!] If you're trying out oVirt 4.2 Beta, please check that any existing UI plugins [1] you are using 1. still work (they should!), and 2. look good in the new UI. If something doesn't look quite right with a UI plugin [for example, if it doesn't quite match the new theme], please contact Alexander Wels and me and we can assist with getting it updated. [1] https://www.ovirt.org/develop/release-management/features/ux/uiplugins/ Best wishes, Greg -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

1 0

FOSDEM 2018 - CFP is about to close!
by Doron Fediuck 29 Nov '17

29 Nov '17

Hi all, FOSDEM 18's Virt and IaaS CFP ends on Friday! This is your last chance to submit your session, so do not wait any longer. You can find more details in [1]. Thanks, Doron [1] https://www.ovirt.org/blog/2017/10/come-to-fosdem-event/

1 0

strange problems with engine
by alex＠rt14.ru 29 Nov '17

29 Nov '17

2 2

Update gluster HCI from 4.1.3 to 4.1.7
by Gianluca Cecchi 28 Nov '17

28 Nov '17

Hello, I have an environment with 3 hosts and gluster HCI on 4.1.3. I'm following this link to take it to 4.1.7 https://www.ovirt.org/documentation/how-to/hosted-engine/#upgrade-hosted-en… The hosts and engine were at 7.3 prior of beginning the update. All went ok for the engine that now is on 7.4 (not rebooted yet) Points 4. 5. 6. for the first updated host were substituted by rebooting it I'm at point: 7. Exit the global maintenance mode: in a few minutes the engine VM should migrate to the fresh upgraded host cause it will get an higher score One note: actually exiting from global maintenance doesn't imply that the host previously put into maintenance exiting from it, correct? So in my workflow, before point 7., actually I have selected the host and activated it. Currently the situation is this - engine running on ovirt02 - update happened on ovirt03 Then after exiting from global maintenance I don't see the engine vm migrating to it. And in fact (see below) the score of ovirt02 is the same (3400) as the one of ovirt03, so it seems it is correct that engine remains there...? Which kind of messages should I see inside logs of engine/hosts? [root@ovirt01 ~]# rpm -q vdsm vdsm-4.19.20-1.el7.centos.x86_64 [root@ovirt02 ~]# rpm -q vdsm vdsm-4.19.20-1.el7.centos.x86_64 [root@ovirt02 ~]# [root@ovirt03 ~]# rpm -q vdsm vdsm-4.19.37-1.el7.centos.x86_64 from host ovirt01: [root@ovirt01 ~]# hosted-engine --vm-status --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt01.localdomain.local Host ID : 1 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3352 stopped : False Local maintenance : False crc32 : 256f2128 local_conf_timestamp : 12251210 Host timestamp : 12251178 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=12251178 (Tue Nov 28 10:11:20 2017) host-id=1 score=3352 vm_conf_refresh_time=12251210 (Tue Nov 28 10:11:52 2017) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : 192.168.150.103 Host ID : 2 Engine status : {"health": "good", "vm": "up", "detail": "up"} Score : 3400 stopped : False Local maintenance : False crc32 : 9b8c8a6c local_conf_timestamp : 12219386 Host timestamp : 12219357 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=12219357 (Tue Nov 28 10:11:23 2017) host-id=2 score=3400 vm_conf_refresh_time=12219386 (Tue Nov 28 10:11:52 2017) conf_on_shared_storage=True maintenance=False state=EngineUp stopped=False --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt03.localdomain.local Host ID : 3 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 9f6399ef local_conf_timestamp : 2136 Host timestamp : 2136 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=2136 (Tue Nov 28 10:11:56 2017) host-id=3 score=3400 vm_conf_refresh_time=2136 (Tue Nov 28 10:11:56 2017) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False [root@ovirt01 ~]# Can I manually migrate engine vm to ovirt03? On ovirt03: [root@ovirt03 ~]# gluster volume info engine Volume Name: engine Type: Replicate Volume ID: 6e2bd1d7-9c8e-4c54-9d85-f36e1b871771 Status: Started Snapshot Count: 0 Number of Bricks: 1 x (2 + 1) = 3 Transport-type: tcp Bricks: Brick1: ovirt01.localdomain.local:/gluster/brick1/engine Brick2: ovirt02.localdomain.local:/gluster/brick1/engine Brick3: ovirt03.localdomain.local:/gluster/brick1/engine (arbiter) Options Reconfigured: performance.strict-o-direct: on nfs.disable: on user.cifs: off network.ping-timeout: 30 cluster.shd-max-threads: 6 cluster.shd-wait-qlength: 10000 cluster.locking-scheme: granular cluster.data-self-heal-algorithm: full performance.low-prio-threads: 32 features.shard-block-size: 512MB features.shard: on storage.owner-gid: 36 storage.owner-uid: 36 cluster.server-quorum-type: server cluster.quorum-type: auto network.remote-dio: off cluster.eager-lock: enable performance.stat-prefetch: off performance.io-cache: off performance.read-ahead: off performance.quick-read: off performance.readdir-ahead: on transport.address-family: inet [root@ovirt03 ~]# [root@ovirt03 ~]# gluster volume heal engine info Brick ovirt01.localdomain.local:/gluster/brick1/engine Status: Connected Number of entries: 0 Brick ovirt02.localdomain.local:/gluster/brick1/engine Status: Connected Number of entries: 0 Brick ovirt03.localdomain.local:/gluster/brick1/engine Status: Connected Number of entries: 0 [root@ovirt03 ~]# Thanks, Gianluca

2 2

"Cannot acquire bridge address" / Failure in "hosted-engine --deploy" on 4.1.8
by Frank Wall 28 Nov '17

28 Nov '17

Hi, when running "hosted-engine --deploy" on a fresh CentOS 7.4 with pre-built network configuration (and ovirtmgmt bridge), the following error occurs: 2017-11-27 19:08:12 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-common/network/bridge.py", line 295, in _get_hostname_from_bridge_if raise RuntimeError(_('Cannot acquire bridge address')) RuntimeError: Cannot acquire bridge address While checking the source of bridge.py line 295 the root cause is interesting: Running "vdsClient -s $HOSTNAME getVdsCapabilities" works perfectly, all NICs and bridges are returned, but only "networks" is returned as empty list: {}. Clearly looks like a bug. How can I resolve this issue? ovirt-hosted-engine-setup-2.1.4-1.el7.centos.noarch vdsm-4.19.40-1.el7.centos.x86_64 Regards - Frank

2 3

Time management in self hosted engine vm
by Gianluca Cecchi 28 Nov '17

28 Nov '17

Hello, I have a self hosted engine HCI environment that was born in 4.0.5 through the ansible/gdeploy mechanism and then gradually updated to 4.1.7 Now the engine and host are at CentOS 7.4 level. Inside the gdeploy jobs the engine vm was installed through the appliance at the 4.0.5 time. I see in web admin gui that hw clock of engine vm is configured as UTC (so far so good) and the same is inside the OS. And I would like to change it to UTC+1 like the 3 hosts I also see that neither chronyd nor ntpd are installed on engine vm. Can I fix the situation the normal os level way: - timedatectl set-timezone "Europe/Rome" - install and configure chronyd or better not to configure time sync in engine vm? Thanks, Gianluca

2 1

HA on Non Responsive
by Arthur Melo 28 Nov '17

28 Nov '17

Hello, there! Is it possible to reduce time to auto migrate machines when node is non responsive? Atenciosamente, Arthur Melo Linux User #302250

3 5

Hosts been evacuated unnecessarily
by FERNANDO FREDIANI 28 Nov '17

28 Nov '17

This is a multi-part message in MIME format. --------------85B0C37C08377D8D314D9F67 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello folks. Ou oVirt (4.1.7.3-1.el7.centos) which runs in one Datacenter and controls Nodes locally and also remotelly lost communication with the remote Nodes in another Datacenter. To this point nothing wrong as the Nodes can continue working as expected and running their Virtual Machines each without dependency of the oVirt Engine. What happened at some point is that when the communication between Engine and Hosts came back Hosts in the remote Datacenter got confused and initiated a Live Migration of ALL VMs from one of the hosts to another. I had also to restart vdsmd agent on all Hosts in order to get sanity my environment. What adds up even more strangeness to this scenario is that one of the Hosts affected by the need of restarting VDSM doesn't belong to the same Cluster as the others and had to have the vdsmd restarted. I understand the Hosts can survive without the Engine online with reduced possibilities but can communicated between them, but without affecting the VMs or even needing to do what happened in this scenario. Am I wrong on any of the assumptions ? Fernando --------------85B0C37C08377D8D314D9F67 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hello folks. Ou oVirt (4.1.7.3-1.el7.centos) which runs in one Datacenter and controls Nodes locally and also remotelly lost communication with the remote Nodes in another Datacenter. To this point nothing wrong as the Nodes can continue working as expected and running their Virtual Machines each without dependency of the oVirt Engine. What happened at some point is that when the communication between Engine and Hosts came back Hosts in the remote Datacenter got confused and initiated a Live Migration of ALL VMs from one of the hosts to another. I had also to restart vdsmd agent on all Hosts in order to get sanity my environment. What adds up even more strangeness to this scenario is that one of the Hosts affected by the need of restarting VDSM doesn't belong to the same Cluster as the others and had to have the vdsmd restarted. I understand the Hosts can survive without the Engine online with reduced possibilities but can communicated between them, but without affecting the VMs or even needing to do what happened in this scenario. Am I wrong on any of the assumptions ? Fernando </body> </html> --------------85B0C37C08377D8D314D9F67--

1 0

OVS DPDK Performance
by FERNANDO FREDIANI 28 Nov '17

28 Nov '17

This is a multi-part message in MIME format. --------------BDE85DB92A8FD76EF257B82B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello As some may have seen recently OVS DPDK has been introduced to oVirt (https://ovirt.org/blog/2017/09/ovs-dpdk/) This is very interesting feature which can make a huge performance difference in terms of network performance. Just wanted to ask if anyone has tested it in any environment and made any comparison, specially for packet forward (e.g: running Virtual Routers or Virtual Firewalls with virtio) or packet dropping as well. One doubt I have and if someone could clarify is: Should I enable DPDK in the Host any traffic forwarded to any VMs will automatically benefit from this performance gain of DPDK or there additional steps that need to be put in place inside the VM when sharing a physical Network Interface ? Thanks Fernando --------------BDE85DB92A8FD76EF257B82B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hello As some may have seen recently OVS DPDK has been introduced to oVirt (<a class="moz-txt-link-freetext" href="https://ovirt.org/blog/2017/09/ovs-dpdk/">https://ovirt.org/blog/2017/09/ovs-dpdk/</a>). This is very interesting feature which can make a huge performance difference in terms of network performance. Just wanted to ask if anyone has tested it in any environment and made any comparison, specially for packet forward (e.g: running Virtual Routers or Virtual Firewalls with virtio) or packet dropping as well. One doubt I have and if someone could clarify is: Should I enable DPDK in the Host any traffic forwarded to any VMs will automatically benefit from this performance gain of DPDK or there additional steps that need to be put in place inside the VM when sharing a physical Network Interface ? Thanks Fernando </body> </html> --------------BDE85DB92A8FD76EF257B82B--

2 2