- Users - oVirt List Archives

"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

Upgrading from Hosted Engine 3.6 to 4.X
by Cam Wright 28 Nov '17

28 Nov '17

Hi there, We're looking to upgrade our hosted engine setup from 3.6 to 4.0 (or 4.1)... We built the 3.6 setup a couple of years ago with Fedora 22 (we wanted the newer-at-the-time kernel 4.4) on the hosts and engine, but when we move to 4.X we'd like to move to EL7 on the engine (as that seems to be the supported version) and to the oVirt Node ISO installer on the hypervisors. We've got only four hosts in our oVirt datacentre, configured in two clusters. Our current idea is to take a backup of the oVirt database using the backup-restore tool, and to take a 'dd' of the virtual disk too, for good measure. Then upgrade the engine to 4.X and confirm that the 3.6 hosts will run, and then finally piecemeal upgrade the hosts to 4.X using the oVirt Node ISO installer. Looking at this page - https://www.ovirt.org/documentation/self-hosted/chap-Maintenance_and_Upgrad… - it seems the 'hosted-engine --upgrade-appliance' path is the best way to do this... but because our hosts are running Fedora instead of EL, I think that makes this option moot to us. Is what I've suggested a valid upgrade path, or is there a more sane way of going about this? -C Cam Wright - Systems and Technical Resource Administrator CUTTINGEDGE / 90 Victoria St, West End, Brisbane, QLD, 4101 T + 61 7 3013 6200 M 0420 827 007 E cwright(a)cuttingedge.com.au | W www.cuttingedge.com.au /SYD /BNE /TYO -- This email is confidential and solely for the use of the intended recipient. If you have received this email in error please notify the author and delete it immediately. This email is not to be distributed without the author's written consent. Unauthorised forwarding, printing, copying or use is strictly prohibited and may be a breach of copyright. Any views expressed in this email are those of the individual sender unless specifically stated to be the views of Cutting Edge Post Pty Ltd (Cutting Edge). Although this email has been sent in the belief that it is virus-free, it is the responsibility of the recipient to ensure that it is virus free. No responsibility is accepted by Cutting Edge for any loss or damage arising in any way from receipt or use of this email. This email may contain legally privileged information and privilege is not waived if you have received this email in error.

3 4

Re: [ovirt-users] VDSM multipath.conf - prevent automatic management of local devices
by Yaniv Kaul 28 Nov '17

28 Nov '17

On Nov 28, 2017 12:24 AM, "Ben Bradley" <listsbb(a)virtx.net> wrote: On 23/11/17 06:46, Maton, Brett wrote: > Might not be quite what you're after but adding > > # RHEV PRIVATE > > To /etc/multipath.conf will stop vdsm from changing the file. > ||| > Hi there. Thanks for the reply. Yes I am aware of that and it seems that's what I will have to do. I have no problem with VDSM managing the file, I just wish it didn't automatically load local storage devices into multipathd. It doesn't. Recent multipath releases do. Does it bother you in any way? Y. I'm still not clear on the purpose of this automatic management though. >From what I can tell there is no difference to hosts/clusters made through this automatic management - i.e. you still have to add storage domains manually in oVirt. Could anyone give any info on the purpose of this auto-management of local storage devices into multipathd in VDSM? Then I will be able to make an informed decision as to the benefit of letting it continue. Thanks, Ben > On 22 November 2017 at 22:42, Ben Bradley <listsbb(a)virtx.net <mailto: > listsbb(a)virtx.net>> wrote: > > Hi All > > I have been running ovirt in a lab environment on CentOS 7 for > several months but have only just got around to really testing things. > I understand that VDSM manages multipath.conf and I understand that > I can make changes to that file and set it to private to prevent > VDSM making further changes. > > I don't mind VDSM managing the file but is it possible to set to > prevent local devices being automatically added to multipathd? > > Many times I have had to flush local devices from multipath when > they are added/removed or re-partitioned or the system is rebooted. > It doesn't even look like oVirt does anything with these devices > once they are setup in multipathd. > > I'm assuming it's the VDSM additions to multipath that are causing > this. Can anyone else confirm this? > > Is there a way to prevent new or local devices being added > automatically? > > Regards > Ben > _______________________________________________ > Users mailing list > Users(a)ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > > > _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

1 0

oVirt self-hosted Engine [Failed to acquire lock: error -243]
by Terry hey 27 Nov '17

27 Nov '17

Hello all, I installed ovirt self-hosted engine. Unfortunately, the engine VM was suddenly shutdown. And later, it automatically powered on. The engine admin console showed the following error. VM HostedEngine is down with error. Exit message: resource busy: Failed to acquire lock: error -243. I would like to know what is this error message is talking about and how to solve this error. I would like to first thank all of you help me to solve this issue. Regards, Terry

3 3

Auto-starting VMS in a all-in-one / confusion.
by CRiMSON 27 Nov '17

27 Nov '17

I've been digging thru mailing lists and blogs and I'm a bit confused about how you have VMs auto-start after a reboot in a ovirt system that is setup as all-in-one. >From what I can gather this can be achieved via some startup scripts (or a rc.local foo). But there is no setting inside the WebUI that can be set to achieve this? Or have I missed something.

5 6

Error during delete snapshot
by Arthur Melo 27 Nov '17

27 Nov '17

Can someone help me with this error? Failed to delete snapshot '<UNKNOWN>' for VM 'proxy03'. Atenciosamente, Arthur Melo Linux User #302250

2 7