[ovirt-users] Re: engine.log flooded with "Field 'foo' can not be updated when status is 'Up'"

[Matthias Leopold]

https://bugzilla.redhat.com/show_bug.cgi?id=1742924

Am 13.08.19 um 19:14 schrieb Sharon Gratch:

Hi,
We checked that issue and found out that you are right and this extra 
logging lines problem is caused by "next run configuration" improvements 
added to oVirt 4.3.5.


The current behaviour is that for each running VM with next run 
configuration existed, a warning line of "Field 'xxx' can not be 
updated when status is 'Up'" appears in log, per each vm device and 
whenever the vms list is refreshed.

This definitely may flood the engine log if there are few such VMs.

Can you please file a bug on that?

Thanks,
Sharon



On Tue, Aug 13, 2019 at 5:01 PM Matthias Leopold 
> wrote:


Thanks for the feedback, I think my description was a bit clumsy,
but at
least someone confirms that he has seen this...
I still hope it's linked to unfinished VM "Custom Compatibility
Version"
updates, tomorrow I'll know, when I finally can do the last VM reboots.
My "Administration Portal" is still usable, but nevertheless I think
this is something the upstream developers should look into.

Regards
Matthias

Am 13.08.19 um 12:48 schrieb Staniforth, Paul:
 > Hello Mathias,
 >                          I also had this problem, the flood of
warning messages was most notably generated when showing all the VMs
running from the admin portal dashboard as we had 70 VMs running
this generated the following but for all 70 VMs. I was able to
restart most of the VMs otherwise the admin portal became unusable.
 > I don't recall this being a problem upgrading from 4.1 to 4.2
 >
 > Regards
 >                  Paul S.
 >
 > 2019-08-13 11:44:36,771+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [936d48c4-76c6-4363-85f0-7147923bbb2f] Field
'customCompatibilityVersion' can not be updated when status is 'Up'
 > 2019-08-13 11:44:36,771+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [936d48c4-76c6-4363-85f0-7147923bbb2f] Field 'exportDate'
can not be updated when status is 'Up'
 > 2019-08-13 11:44:36,771+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [936d48c4-76c6-4363-85f0-7147923bbb2f] Field
'managedDeviceMap' can not be updated when status is 'Up'
 > 2019-08-13 11:44:36,771+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [936d48c4-76c6-4363-85f0-7147923bbb2f] Field 'ovfVersion'
can not be updated when status is 'Up'
 > 2019-08-13 11:44:36,772+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [936d48c4-76c6-4363-85f0-7147923bbb2f] Field
'balloonEnabled' can not be updated when status is 'Up'
 > 2019-08-13 11:44:36,772+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [936d48c4-76c6-4363-85f0-7147923bbb2f] Field 'watchdog'
can not be updated when status is 'Up'
 > 2019-08-13 11:44:36,773+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [936d48c4-76c6-4363-85f0-7147923bbb2f] Field 'rngDevice'
can not be updated when status is 'Up'
 > 2019-08-13 11:44:36,774+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [936d48c4-76c6-4363-85f0-7147923bbb2f] Field
'soundDeviceEnabled' can not be updated when status is 'Up'
 > 2019-08-13 11:44:36,774+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [936d48c4-76c6-4363-85f0-7147923bbb2f] Field
'consoleEnabled' can not be updated when status is 'Up'
 > 2019-08-13 11:44:36,775+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [936d48c4-76c6-4363-85f0-7147923bbb2f] Field
'virtioScsiEnabled' can not be updated when status is 'Up'
 > 2019-08-13 11:44:36,776+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [936d48c4-76c6-4363-85f0-7147923bbb2f] Field
'graphicsDevices' can not be updated when status is 'Up'
 > 2019-08-13 11:44:39,490+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [0b246c13-223f-4728-b988-5da34139aeb2] Field
'customCompatibilityVersion' can not be updated when status is 'Up'
 > 2019-08-13 11:44:39,490+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [0b246c13-223f-4728-b988-5da34139aeb2] Field 'exportDate'
can not be updated when status is 'Up'
 > 2019-08-13 11:44:39,490+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityChecker] (default

task-855) [0b246c13-223f-4728-b988-5da34139aeb2] Field
'managedDeviceMap' can not be updated when status is 'Up'
 > 2019-08-13 11:44:39,490+01 WARN 
[org.ovirt.engine.core.utils.ObjectIdentityCh

[ovirt-users] Evaluate oVirt to remove VMware

[dsalade]

Howdy All!!!

Somewhat new user to Linux and having some issues with oVirt node networking.
We are mainly a Windows/VMware medium shop but have a pretty good network.

Our VMware setup has redundant switches using multiple VLANs. This was fairly 
easy to setup with VMware.
We never had an issue with VMware, add 2 NICs to the ESXi host and then adding 
VLANs into the Virtual Switch. 

Biggest issue I am having, should I be bonding, teaming and VLANing on top of 
that?
Tried setting up node with Engine inside which fails to deploy because of 
networking.

Then I tried a standalone Engine and could not add node to it - I believe 
networking as well as Power Management agent was the problem.
Would like the nodes/engine to be on one subnet (lets say 10.10.11.x) and VMs 
to be allowed to run there are well as 10 other VLANs.

I guess welcome to the wonderful world of Linux networking and learning some 
new technologies is in store for me.
I hope I am not being vague, like I said fairly new to Linux.

Thanks for any responses!
Allen
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/RFBBDI7R4R5LIX63KHCJWMS7MYLSCI55/

[ovirt-users] Need to enable STP on ovirt bridges

[ej . albany]

Hello. I have been trying to figure out an issue for a very long time.
That issue relates to the ethernet and 10gb fc links that I have on my
cluster being disabled any time a migration occurs.

I believe this is because I need to have STP turned on in order to
participate with the switch. However, there does not seem to be any
way to tell oVirt to stop turning it off! Very frustrating.

After entering a cronjob that enables stp on all bridges every 1
minute, the migration issue disappears

Is there any way at all to do without this cronjob and set STP to be
ON without having to resort to such a silly solution?

Here are some details about my systems, if you need it.


selinux is disabled.









[root@swm-02 ~]# rpm -qa | grep ovirt
ovirt-imageio-common-1.5.1-0.el7.x86_64
ovirt-release43-4.3.5.2-1.el7.noarch
ovirt-imageio-daemon-1.5.1-0.el7.noarch
ovirt-vmconsole-host-1.0.7-2.el7.noarch
ovirt-hosted-engine-setup-2.3.11-1.el7.noarch
ovirt-ansible-hosted-engine-setup-1.0.26-1.el7.noarch
python2-ovirt-host-deploy-1.8.0-1.el7.noarch
ovirt-ansible-engine-setup-1.1.9-1.el7.noarch
python2-ovirt-setup-lib-1.2.0-1.el7.noarch
cockpit-machines-ovirt-195.1-1.el7.noarch
ovirt-hosted-engine-ha-2.3.3-1.el7.noarch
ovirt-vmconsole-1.0.7-2.el7.noarch
cockpit-ovirt-dashboard-0.13.5-1.el7.noarch
ovirt-provider-ovn-driver-1.2.22-1.el7.noarch
ovirt-host-deploy-common-1.8.0-1.el7.noarch
ovirt-host-4.3.4-1.el7.x86_64
python-ovirt-engine-sdk4-4.3.2-2.el7.x86_64
ovirt-host-dependencies-4.3.4-1.el7.x86_64
ovirt-ansible-repositories-1.1.5-1.el7.noarch
[root@swm-02 ~]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
[root@swm-02 ~]# uname -r
3.10.0-957.27.2.el7.x86_64
You have new mail in /var/spool/mail/root
[root@swm-02 ~]# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
2: em1:  mtu 1500 qdisc mq master
test state UP group default qlen 1000
link/ether d4:ae:52:8d:50:48 brd ff:ff:ff:ff:ff:ff
3: em2:  mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether d4:ae:52:8d:50:49 brd ff:ff:ff:ff:ff:ff
4: p1p1:  mtu 1500 qdisc mq master
ovirtmgmt state UP group default qlen 1000
link/ether 90:e2:ba:1e:14:80 brd ff:ff:ff:ff:ff:ff
5: p1p2:  mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 90:e2:ba:1e:14:81 brd ff:ff:ff:ff:ff:ff
6: ovs-system:  mtu 1500 qdisc noop state DOWN
group default qlen 1000
link/ether a2:b8:d6:e8:b3:d8 brd ff:ff:ff:ff:ff:ff
7: br-int:  mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 96:a0:c1:4a:45:4b brd ff:ff:ff:ff:ff:ff
25: test:  mtu 1500 qdisc noqueue
state UP group default qlen 1000
link/ether d4:ae:52:8d:50:48 brd ff:ff:ff:ff:ff:ff
inet 10.15.11.21/24 brd 10.15.11.255 scope global test
   valid_lft forever preferred_lft forever
26: ovirtmgmt:  mtu 1500 qdisc
noqueue state UP group default qlen 1000
link/ether 90:e2:ba:1e:14:80 brd ff:ff:ff:ff:ff:ff
inet 10.15.28.31/24 brd 10.15.28.255 scope global ovirtmgmt
   valid_lft forever preferred_lft forever
27: ;vdsmdummy;:  mtu 1500 qdisc noop state DOWN
group default qlen 1000
link/ether 62:e5:e5:07:99:eb brd ff:ff:ff:ff:ff:ff
29: vnet0:  mtu 1500 qdisc mq master
ovirtmgmt state UNKNOWN group default qlen 1000
link/ether fe:6f:9c:95:00:02 brd ff:ff:ff:ff:ff:ff
[root@swm-02 ~]# free -m
  totalusedfree  shared  buff/cache   available
Mem:  644131873   61804   9 735   62062
Swap: 16383   0   16383
[root@swm-02 ~]# free -h
  totalusedfree  shared  buff/cache   available
Mem:62G1.8G 60G9.5M735M 60G
Swap:   15G  0B 15G
[root@swm-02 ~]# ls
ls  lsb_release lshwlslocks
 lsmod   lspci   lssubsys
lsusb.py
lsattr  lscgrouplsinitrdlslogins
 lsnslss16toppm  lstopo-no-graphics
lsblk   lscpu   lsipc   lsmem
 lsoflsscsi  lsusb
[root@swm-02 ~]# lscpu
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):16
On-line CPU(s) list:   0-15
Thread(s) per core:2
Core(s) per socket:4
Socket(s): 2
NUMA node(s):  2
Vendor ID: GenuineIntel
CPU family:6
Model: 44
Model name:Intel(R) Xeon(R) CPU   X5672  @ 3.20GHz
Stepping:  2
CPU MHz:   3192.064
BogoMIPS:  6384.12
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache:  256K
L3 cache:  12288K
NUMA node0 CPU(s)