[ovirt-users] Re: Failed HostedEngine Deployment
I think you may be right, here. I decided to just start over and use the
actual ovirt-node installation media, rather than Centos Stream installation
media. Hopefully that gets the software-side situated. Thanks for the pointers.
From: Strahil Nikolov
Sent: Sunday, January 23, 2022 5:46 PM
To: Robert Tongue ; users
Subject: Re: [ovirt-users] Failed HostedEngine Deployment
yum downgrade qemu-kvm-block-gluster-6.0.0-33.el8s
libvirt-daemon-driver-qemu-6.0.0-33.el8s qemu-kvm-common
-6.0.0-33.el8s qemu-kvm-hw-usbredir-6.0.0-33.el8s qemu-kvm-u
i-opengl-6.0.0-33.el8s qemu-kvm-block-rbd-6.0.0-33.el8s qemu
-img-6.0.0-33.el8s qemu-kvm-6.0.0-33.el8s qemu-kvm-block-cur
l-6.0.0-33.el8s qemu-kvm-block-ssh-6.0.0-33.el8s qemu-kvm-ui
-spice-6.0.0-33.el8s ipxe-roms-qemu-6.0.0-33.el8s qemu-kvm-c
ore-6.0.0-33.el8s qemu-kvm-docs-6.0.0-33.el8s qemu-kvm-block-6.0.0-33.el8s
Best Regards,
Strahil Nikolov
On Sun, Jan 23, 2022 at 22:47, Robert Tongue
wrote:
Ahh, I did some repoquery commands can see a good bit of qemu* packages are
coming from appstream rather than
ovirt-4.4-centos-stream-advanced-virtualization.
What's the recommanded fix?
From: Strahil Nikolov
Sent: Sunday, January 23, 2022 3:41 PM
To: users ; Robert Tongue
Subject: Re: [ovirt-users] Failed HostedEngine Deployment
I've seen this.
Ensure that all qemu-related packages are coming from
centos-advanced-virtualization repo (6.0.0-33.el8s.x86_64).
There is a known issue with the latest packages in the CentOS Stream.
Also, you can set the following alias on the Hypervisours:
alias virsh='virsh -c
qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf'
Best Regards,
Strahil Nikolov
В неделя, 23 януари 2022 г., 21:14:20 Гринуич+2, Robert Tongue
написа:
Greetings oVirt people,
I am having a problem with the hosted-engine deployment, and unfortunately
after a weekend spent trying to get this far, I am finally stuck, and cannot
figure out how to fix this.
I am starting with 1 host, and will have 4 when this is finished. Storage is
GlusterFS, hyperconverged, but I am managing that myself outside of oVirt. It's
a single-node GlusterFS volume, which I will expand out across the other 4
nodes as well. I get all the way through the initial hosted-engine deployment
(via the cockpit interface) pre-storage, then get most of the way through the
storage portion of it. It fails at starting the HostedEngine VM in its final
state after copying the VM disk to shared storage.
This is where it gets weird.
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Engine VM
IP address is while the engine's he_fqdn ovirt.deleted.domain resolves to
192.168.x.x. If you are using DHCP, check your DHCP reservation configuration"}
I've masked out the domain and IP for obvious reasons. However I think this
deployment error isn't really the reason for the failure, it's just where it is
at when it fails. The HostedEngine VM is starting, but not actually booting.
I was able to change the VNC password with `hosted-engine
--add-console-password`, and see the local console display with that, however
it just displays "The guest has not initialized the display (yet)".
I also did:
# hosted-engine --console
The engine VM is running on this host
Escape character is ^]
Yet that doesn't move any further, nor allow any input. The VM does not
respond on the network. I am thinking it's just not making it to the initial
BIOS screen and booting at all. What would cause that?
Here is the glusterfs volume for clarity.
# gluster volume info storage
Volume Name: storage
Type: Distribute
Volume ID: e9544310-8890-43e3-b49c-6e8c7472dbbb
Status: Started
Snapshot Count: 0
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: node1:/var/glusterfs/storage/1
Options Reconfigured:
storage.owner-gid: 36
storage.owner-uid: 36
network.ping-timeout: 5
performance.client-io-threads: on
server.event-threads: 4
client.event-threads: 4
cluster.choose-local: off
user.cifs: off
features.shard: on
cluster.shd-wait-qlength: 1024
cluster.locking-scheme: full
cluster.data-self-heal-algorithm: full
cluster.server-quorum-type: server
cluster.quorum-type: auto
cluster.eager-lock: enable
performance.strict-o-direct: on
network.remote-dio: disable
performance.low-prio-threads: 32
performance.io-cache: off
performance.read-ahead: off
performance.quick-read: off
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz
stepping : 9
microcode : 0x21
cpu MHz : 4000.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss
[ovirt-users] Re: Can't upgrade ovirt 4.4.3 to 4.4.9
>Correct. Was added in an upgrade script. There might be a bug/issue/change >in the order that the upgrade script runs vs create_views_* above. >Adding Aviv and Shirly. i found this problem at log. UPDATE 0 2022-01-21 16:02:41,589+0900 Running upgrade sql script '/usr/share/ovirt-engine-dwh/dbscripts/upgrade/pre_upgrade/set_etl_minimal_version.sql'... 2022-01-21 16:02:41,591+0900 dbfunc_psql_die --file=/usr/share/ovirt-engine-dwh/dbscripts/upgrade/pre_upgrade/set_etl_minimal_version.sql * QUERY ** INSERT INTO history_configuration(var_name,var_value) SELECT 'MinimalETLVersion','4.4.7' WHERE not exists (SELECT var_name FROM history_configuration WHERE var_name = 'MinimalETLVersion'); ** INSERT 0 0 * QUERY ** UPDATE history_configuration SET var_value = '4.4.7' WHERE var_name = 'MinimalETLVersion'; ** .. 2022-01-21 16:02:43,138+0900 Skipping upgrade script /usr/share/ovirt-engine-dwh/dbscripts/upgrade/04_04_0040_added_host_count_threads_as_cores.sql, its version 04040040 is <= current version 04040070 * QUERY ** copy (select now()) to stdout with delimiter as '|'; ** Sorry for the mess, Thank you -- Jihwan ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/4HM4YEZIGGLYMPHDOA4GWQP4Q65NNIU3/
[ovirt-users] Re: Can't upgrade ovirt 4.4.3 to 4.4.9
Hello, Thanks for your answer
>This indeed looks like the root cause for the failure. Can you please
>share the full setup log? Thanks.
i send the log file by mail
>I'd like to know as well. Generally speaking, if the engine is down,
>all VMs should still be up, but there is no (simple/robust) way to
>manage them - including stopping/starting/etc. .
when i check --vm-status, engine is up but health is bad status
and when i turn off the global maintenance mode the status of engine is like
{"vm": "down_unexpected", "health": "bad", "detail": "Down", "reason": "bad vm
status"}
Thank you.
Jihwan.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/WNVRHFLH2262LD7YC6XMMXNUXAUY23BU/
[ovirt-users] Re: Can't upgrade ovirt 4.4.3 to 4.4.9
and after few minutes, the status of engine is like
{"vm": "down_unexpected", "health": "bad", "detail": "Down", "reason": "bad vm
status"}
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/R3R436HCODXJPR2OAJTEDDF7WMDEDNAS/
[ovirt-users] Re: Can't upgrade ovirt 4.4.3 to 4.4.9
Hello, when i check --vm-status, engine is up but health is bad status ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/5FHUDF74LA6JLCJRIMP5RGJ6SUQAHN4W/
[ovirt-users] Re: Failed HostedEngine Deployment
yum downgrade qemu-kvm-block-gluster-6.0.0-33.el8s
libvirt-daemon-driver-qemu-6.0.0-33.el8s qemu-kvm-common-6.0.0-33.el8s
qemu-kvm-hw-usbredir-6.0.0-33.el8s qemu-kvm-ui-opengl-6.0.0-33.el8s
qemu-kvm-block-rbd-6.0.0-33.el8s qemu-img-6.0.0-33.el8s qemu-kvm-6.0.0-33.el8s
qemu-kvm-block-curl-6.0.0-33.el8s qemu-kvm-block-ssh-6.0.0-33.el8s
qemu-kvm-ui-spice-6.0.0-33.el8s ipxe-roms-qemu-6.0.0-33.el8s
qemu-kvm-core-6.0.0-33.el8s qemu-kvm-docs-6.0.0-33.el8s
qemu-kvm-block-6.0.0-33.el8s
Best Regards,Strahil Nikolov
On Sun, Jan 23, 2022 at 22:47, Robert Tongue wrote:
#yiv7072323153 P {margin-top:0;margin-bottom:0;}Ahh, I did some repoquery
commands can see a good bit of qemu* packages are coming from appstream rather
than ovirt-4.4-centos-stream-advanced-virtualization.
What's the recommanded fix?From: Strahil Nikolov
Sent: Sunday, January 23, 2022 3:41 PM
To: users ; Robert Tongue
Subject: Re: [ovirt-users] Failed HostedEngine Deployment I've seen this.
Ensure that all qemu-related packages are coming from
centos-advanced-virtualization repo (6.0.0-33.el8s.x86_64).
There is a known issue with the latest packages in the CentOS Stream.
Also, you can set the following alias on the Hypervisours:
alias virsh='virsh -c
qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf'
Best Regards,
Strahil Nikolov
В неделя, 23 януари 2022 г., 21:14:20 Гринуич+2, Robert Tongue
написа:
Greetings oVirt people,
I am having a problem with the hosted-engine deployment, and unfortunately
after a weekend spent trying to get this far, I am finally stuck, and cannot
figure out how to fix this.
I am starting with 1 host, and will have 4 when this is finished. Storage is
GlusterFS, hyperconverged, but I am managing that myself outside of oVirt. It's
a single-node GlusterFS volume, which I will expand out across the other 4
nodes as well. I get all the way through the initial hosted-engine deployment
(via the cockpit interface) pre-storage, then get most of the way through the
storage portion of it. It fails at starting the HostedEngine VM in its final
state after copying the VM disk to shared storage.
This is where it gets weird.
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Engine VM
IP address is while the engine's he_fqdn ovirt.deleted.domain resolves to
192.168.x.x. If you are using DHCP, check your DHCP reservation configuration"}
I've masked out the domain and IP for obvious reasons. However I think this
deployment error isn't really the reason for the failure, it's just where it is
at when it fails. The HostedEngine VM is starting, but not actually booting.
I was able to change the VNC password with `hosted-engine
--add-console-password`, and see the local console display with that, however
it just displays "The guest has not initialized the display (yet)".
I also did:
# hosted-engine --consoleThe engine VM is running on this hostEscape character
is ^]
Yet that doesn't move any further, nor allow any input. The VM does not
respond on the network. I am thinking it's just not making it to the initial
BIOS screen and booting at all. What would cause that?
Here is the glusterfs volume for clarity.
# gluster volume info storage Volume Name: storageType: DistributeVolume ID:
e9544310-8890-43e3-b49c-6e8c7472dbbbStatus: StartedSnapshot Count: 0Number of
Bricks: 1Transport-type: tcpBricks:Brick1:
node1:/var/glusterfs/storage/1Options Reconfigured:storage.owner-gid:
36storage.owner-uid: 36network.ping-timeout: 5performance.client-io-threads:
onserver.event-threads: 4client.event-threads: 4cluster.choose-local:
offuser.cifs: offfeatures.shard: oncluster.shd-wait-qlength:
1024cluster.locking-scheme: fullcluster.data-self-heal-algorithm:
fullcluster.server-quorum-type: servercluster.quorum-type:
autocluster.eager-lock: enableperformance.strict-o-direct:
onnetwork.remote-dio: disableperformance.low-prio-threads:
32performance.io-cache: offperformance.read-ahead: offperformance.quick-read:
offstorage.fips-mode-rchecksum: ontransport.address-family: inetnfs.disable: on
# cat /proc/cpuinfoprocessor : 0vendor_id : GenuineIntelcpu family : 6model :
58model name : Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHzstepping : 9microcode :
0x21cpu MHz : 4000.000cache size : 8192 KBphysical id : 0siblings : 8core id :
0cpu cores : 4apicid : 0initial apicid : 0fpu : yesfpu_exception : yescpuid
level : 13wp : yesflags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est
tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer
xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp
tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida
arat pln pts md_clear flush_l1dbugs :
[ovirt-users] Re: Major problems after upgrading 2 (of 4) Red Hat hosts to 4.4.10
*cluster.server-quorum-ratio is set to 51% which in your case means that you can afford only 1 server down (both 3-node TSP and 4-node TSP). Best Regards,Strahil Nikolov On Sun, Jan 23, 2022 at 22:46, Strahil Nikolov via Users wrote: ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/6OIHCOCRJ5IAQTMVXLE67A6MM2MFCSP2/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/CJSTYHIMFOMGZHG67PENMZNGBIYMR3RU/
[ovirt-users] Re: Failed HostedEngine Deployment
I've seen this.
Ensure that all qemu-related packages are coming from
centos-advanced-virtualization repo (6.0.0-33.el8s.x86_64).
There is a known issue with the latest packages in the CentOS Stream.
Also, you can set the following alias on the Hypervisours:
alias virsh='virsh -c
qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf'
Best Regards,
Strahil Nikolov
В неделя, 23 януари 2022 г., 21:14:20 Гринуич+2, Robert Tongue
написа:
#yiv4464233184 P {margin-top:0;margin-bottom:0;}Greetings oVirt people,
I am having a problem with the hosted-engine deployment, and unfortunately
after a weekend spent trying to get this far, I am finally stuck, and cannot
figure out how to fix this.
I am starting with 1 host, and will have 4 when this is finished. Storage is
GlusterFS, hyperconverged, but I am managing that myself outside of oVirt. It's
a single-node GlusterFS volume, which I will expand out across the other 4
nodes as well. I get all the way through the initial hosted-engine deployment
(via the cockpit interface) pre-storage, then get most of the way through the
storage portion of it. It fails at starting the HostedEngine VM in its final
state after copying the VM disk to shared storage.
This is where it gets weird.
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Engine VM
IP address is while the engine's he_fqdn ovirt.deleted.domain resolves to
192.168.x.x. If you are using DHCP, check your DHCP reservation configuration"}
I've masked out the domain and IP for obvious reasons. However I think this
deployment error isn't really the reason for the failure, it's just where it is
at when it fails. The HostedEngine VM is starting, but not actually booting.
I was able to change the VNC password with `hosted-engine
--add-console-password`, and see the local console display with that, however
it just displays "The guest has not initialized the display (yet)".
I also did:
# hosted-engine --consoleThe engine VM is running on this hostEscape character
is ^]
Yet that doesn't move any further, nor allow any input. The VM does not
respond on the network. I am thinking it's just not making it to the initial
BIOS screen and booting at all. What would cause that?
Here is the glusterfs volume for clarity.
# gluster volume info storage Volume Name: storageType: DistributeVolume ID:
e9544310-8890-43e3-b49c-6e8c7472dbbbStatus: StartedSnapshot Count: 0Number of
Bricks: 1Transport-type: tcpBricks:Brick1:
node1:/var/glusterfs/storage/1Options Reconfigured:storage.owner-gid:
36storage.owner-uid: 36network.ping-timeout: 5performance.client-io-threads:
onserver.event-threads: 4client.event-threads: 4cluster.choose-local:
offuser.cifs: offfeatures.shard: oncluster.shd-wait-qlength:
1024cluster.locking-scheme: fullcluster.data-self-heal-algorithm:
fullcluster.server-quorum-type: servercluster.quorum-type:
autocluster.eager-lock: enableperformance.strict-o-direct:
onnetwork.remote-dio: disableperformance.low-prio-threads:
32performance.io-cache: offperformance.read-ahead: offperformance.quick-read:
offstorage.fips-mode-rchecksum: ontransport.address-family: inetnfs.disable: on
# cat /proc/cpuinfoprocessor : 0vendor_id : GenuineIntelcpu family : 6model :
58model name : Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHzstepping : 9microcode :
0x21cpu MHz : 4000.000cache size : 8192 KBphysical id : 0siblings : 8core id :
0cpu cores : 4apicid : 0initial apicid : 0fpu : yesfpu_exception : yescpuid
level : 13wp : yesflags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est
tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer
xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp
tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida
arat pln pts md_clear flush_l1dbugs : cpu_meltdown spectre_v1 spectre_v2
spec_store_bypass l1tf mds swapgs itlb_multihit srbdsbogomips : 7199.86clflush
size : 64cache_alignment: 64address sizes : 36 bits physical, 48 bits
virtualpower management:
[ plus 7 more ]
Thanks for any insight that can be provided.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JZQYGXQP5DO4HJSLONTBNMPQ5YUX54MX/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
[ovirt-users] Re: Failed HostedEngine Deployment
Thanks for the response. How can I verify this? Has something with the
installation procedures changed recently?
From: Strahil Nikolov
Sent: Sunday, January 23, 2022 3:41 PM
To: users ; Robert Tongue
Subject: Re: [ovirt-users] Failed HostedEngine Deployment
I've seen this.
Ensure that all qemu-related packages are coming from
centos-advanced-virtualization repo (6.0.0-33.el8s.x86_64).
There is a known issue with the latest packages in the CentOS Stream.
Also, you can set the following alias on the Hypervisours:
alias virsh='virsh -c
qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf'
Best Regards,
Strahil Nikolov
В неделя, 23 януари 2022 г., 21:14:20 Гринуич+2, Robert Tongue
написа:
Greetings oVirt people,
I am having a problem with the hosted-engine deployment, and unfortunately
after a weekend spent trying to get this far, I am finally stuck, and cannot
figure out how to fix this.
I am starting with 1 host, and will have 4 when this is finished. Storage is
GlusterFS, hyperconverged, but I am managing that myself outside of oVirt. It's
a single-node GlusterFS volume, which I will expand out across the other 4
nodes as well. I get all the way through the initial hosted-engine deployment
(via the cockpit interface) pre-storage, then get most of the way through the
storage portion of it. It fails at starting the HostedEngine VM in its final
state after copying the VM disk to shared storage.
This is where it gets weird.
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Engine VM
IP address is while the engine's he_fqdn ovirt.deleted.domain resolves to
192.168.x.x. If you are using DHCP, check your DHCP reservation configuration"}
I've masked out the domain and IP for obvious reasons. However I think this
deployment error isn't really the reason for the failure, it's just where it is
at when it fails. The HostedEngine VM is starting, but not actually booting.
I was able to change the VNC password with `hosted-engine
--add-console-password`, and see the local console display with that, however
it just displays "The guest has not initialized the display (yet)".
I also did:
# hosted-engine --console
The engine VM is running on this host
Escape character is ^]
Yet that doesn't move any further, nor allow any input. The VM does not
respond on the network. I am thinking it's just not making it to the initial
BIOS screen and booting at all. What would cause that?
Here is the glusterfs volume for clarity.
# gluster volume info storage
Volume Name: storage
Type: Distribute
Volume ID: e9544310-8890-43e3-b49c-6e8c7472dbbb
Status: Started
Snapshot Count: 0
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: node1:/var/glusterfs/storage/1
Options Reconfigured:
storage.owner-gid: 36
storage.owner-uid: 36
network.ping-timeout: 5
performance.client-io-threads: on
server.event-threads: 4
client.event-threads: 4
cluster.choose-local: off
user.cifs: off
features.shard: on
cluster.shd-wait-qlength: 1024
cluster.locking-scheme: full
cluster.data-self-heal-algorithm: full
cluster.server-quorum-type: server
cluster.quorum-type: auto
cluster.eager-lock: enable
performance.strict-o-direct: on
network.remote-dio: disable
performance.low-prio-threads: 32
performance.io-cache: off
performance.read-ahead: off
performance.quick-read: off
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz
stepping : 9
microcode : 0x21
cpu MHz : 4000.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid
aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr
pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c rdrand
lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority
ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
itlb_multihit srbds
bogomips : 7199.86
clflush size : 64
cache_alignment: 64
address sizes : 36 bits physical, 48 bits virtual
power management:
[ plus 7 more ]
Thanks for any insight that can be provided.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to
users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List
[ovirt-users] Re: Failed HostedEngine Deployment
Ahh, I did some repoquery commands can see a good bit of qemu* packages are
coming from appstream rather than
ovirt-4.4-centos-stream-advanced-virtualization.
What's the recommanded fix?
From: Strahil Nikolov
Sent: Sunday, January 23, 2022 3:41 PM
To: users ; Robert Tongue
Subject: Re: [ovirt-users] Failed HostedEngine Deployment
I've seen this.
Ensure that all qemu-related packages are coming from
centos-advanced-virtualization repo (6.0.0-33.el8s.x86_64).
There is a known issue with the latest packages in the CentOS Stream.
Also, you can set the following alias on the Hypervisours:
alias virsh='virsh -c
qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf'
Best Regards,
Strahil Nikolov
В неделя, 23 януари 2022 г., 21:14:20 Гринуич+2, Robert Tongue
написа:
Greetings oVirt people,
I am having a problem with the hosted-engine deployment, and unfortunately
after a weekend spent trying to get this far, I am finally stuck, and cannot
figure out how to fix this.
I am starting with 1 host, and will have 4 when this is finished. Storage is
GlusterFS, hyperconverged, but I am managing that myself outside of oVirt. It's
a single-node GlusterFS volume, which I will expand out across the other 4
nodes as well. I get all the way through the initial hosted-engine deployment
(via the cockpit interface) pre-storage, then get most of the way through the
storage portion of it. It fails at starting the HostedEngine VM in its final
state after copying the VM disk to shared storage.
This is where it gets weird.
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Engine VM
IP address is while the engine's he_fqdn ovirt.deleted.domain resolves to
192.168.x.x. If you are using DHCP, check your DHCP reservation configuration"}
I've masked out the domain and IP for obvious reasons. However I think this
deployment error isn't really the reason for the failure, it's just where it is
at when it fails. The HostedEngine VM is starting, but not actually booting.
I was able to change the VNC password with `hosted-engine
--add-console-password`, and see the local console display with that, however
it just displays "The guest has not initialized the display (yet)".
I also did:
# hosted-engine --console
The engine VM is running on this host
Escape character is ^]
Yet that doesn't move any further, nor allow any input. The VM does not
respond on the network. I am thinking it's just not making it to the initial
BIOS screen and booting at all. What would cause that?
Here is the glusterfs volume for clarity.
# gluster volume info storage
Volume Name: storage
Type: Distribute
Volume ID: e9544310-8890-43e3-b49c-6e8c7472dbbb
Status: Started
Snapshot Count: 0
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: node1:/var/glusterfs/storage/1
Options Reconfigured:
storage.owner-gid: 36
storage.owner-uid: 36
network.ping-timeout: 5
performance.client-io-threads: on
server.event-threads: 4
client.event-threads: 4
cluster.choose-local: off
user.cifs: off
features.shard: on
cluster.shd-wait-qlength: 1024
cluster.locking-scheme: full
cluster.data-self-heal-algorithm: full
cluster.server-quorum-type: server
cluster.quorum-type: auto
cluster.eager-lock: enable
performance.strict-o-direct: on
network.remote-dio: disable
performance.low-prio-threads: 32
performance.io-cache: off
performance.read-ahead: off
performance.quick-read: off
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz
stepping : 9
microcode : 0x21
cpu MHz : 4000.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid
aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr
pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c rdrand
lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority
ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
itlb_multihit srbds
bogomips : 7199.86
clflush size : 64
cache_alignment: 64
address sizes : 36 bits physical, 48 bits virtual
power management:
[ plus 7 more ]
Thanks for any insight that can be provided.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to
users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of
[ovirt-users] Re: Major problems after upgrading 2 (of 4) Red Hat hosts to 4.4.10
The oVirt settings on the Gluster have server quorum enabled . If quorum is less than 50% +1 servers -> all bricks will shutdown. If the compute-only node is part of the TSP (Gluster's cluster) , it will also be calculated for quorum and in most cases you don't want that. If it's so - just remove it (from the main nodes) from the TSP. Best Regards, Strahil Nikolov В неделя, 23 януари 2022 г., 05:13:25 Гринуич+2, David White написа: Thank you very much. Over the course of troubleshooting, I did wind up updating (and rebooting) the engine. The issue "magically" resolved itself a few hours after I sent this email with the two Gluster nodes. They became operational again, and thus, I wound up having enough compute power to bring everything back online. That said, the compute-only node is still not operational. I'll take a look at the "gluster pool list" command. Thank you for that. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, January 22nd, 2022 at 5:48 PM, Strahil Nikolov wrote: Check the situation with the gluster storage.Also, you can check if the compute-only node is added to the gluster trsuted storage pool:gluster pool list (should show localhost -+ 2 more). Also, consider upgrading the engine. Most probably the engine cannot connect to the vdsm and vdsm-gluster and this makes the whole situation worse. Best Regards,Strahil Nikolov On Sat, Jan 22, 2022 at 23:15, David White via Users wrote: ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/UZLDTUYRNCZYCU5OPTI74ADFXYTRN5VV/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/6OIHCOCRJ5IAQTMVXLE67A6MM2MFCSP2/
[ovirt-users] Failed HostedEngine Deployment
Greetings oVirt people,
I am having a problem with the hosted-engine deployment, and unfortunately
after a weekend spent trying to get this far, I am finally stuck, and cannot
figure out how to fix this.
I am starting with 1 host, and will have 4 when this is finished. Storage is
GlusterFS, hyperconverged, but I am managing that myself outside of oVirt. It's
a single-node GlusterFS volume, which I will expand out across the other 4
nodes as well. I get all the way through the initial hosted-engine deployment
(via the cockpit interface) pre-storage, then get most of the way through the
storage portion of it. It fails at starting the HostedEngine VM in its final
state after copying the VM disk to shared storage.
This is where it gets weird.
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Engine VM
IP address is while the engine's he_fqdn ovirt.deleted.domain resolves to
192.168.x.x. If you are using DHCP, check your DHCP reservation configuration"}
I've masked out the domain and IP for obvious reasons. However I think this
deployment error isn't really the reason for the failure, it's just where it is
at when it fails. The HostedEngine VM is starting, but not actually booting.
I was able to change the VNC password with `hosted-engine
--add-console-password`, and see the local console display with that, however
it just displays "The guest has not initialized the display (yet)".
I also did:
# hosted-engine --console
The engine VM is running on this host
Escape character is ^]
Yet that doesn't move any further, nor allow any input. The VM does not
respond on the network. I am thinking it's just not making it to the initial
BIOS screen and booting at all. What would cause that?
Here is the glusterfs volume for clarity.
# gluster volume info storage
Volume Name: storage
Type: Distribute
Volume ID: e9544310-8890-43e3-b49c-6e8c7472dbbb
Status: Started
Snapshot Count: 0
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: node1:/var/glusterfs/storage/1
Options Reconfigured:
storage.owner-gid: 36
storage.owner-uid: 36
network.ping-timeout: 5
performance.client-io-threads: on
server.event-threads: 4
client.event-threads: 4
cluster.choose-local: off
user.cifs: off
features.shard: on
cluster.shd-wait-qlength: 1024
cluster.locking-scheme: full
cluster.data-self-heal-algorithm: full
cluster.server-quorum-type: server
cluster.quorum-type: auto
cluster.eager-lock: enable
performance.strict-o-direct: on
network.remote-dio: disable
performance.low-prio-threads: 32
performance.io-cache: off
performance.read-ahead: off
performance.quick-read: off
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz
stepping : 9
microcode : 0x21
cpu MHz : 4000.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid
aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr
pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c rdrand
lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority
ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
itlb_multihit srbds
bogomips : 7199.86
clflush size : 64
cache_alignment: 64
address sizes : 36 bits physical, 48 bits virtual
power management:
[ plus 7 more ]
Thanks for any insight that can be provided.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JZQYGXQP5DO4HJSLONTBNMPQ5YUX54MX/
[ovirt-users] Re: How does the Stream based management engine transition to RHV?
Hi Thomas, On Fri, Jan 21, 2022 at 11:16 PM Thomas Hoberg wrote: > > In the recent days, I've been trying to validate the transition from CentOS 8 > to Alma, Rocky, Oracle and perhaps soon Liberty Linux for existing HCI > clusters. > > I am using nested virtualization on a VMware workstation host, because I > understand snapshoting and linked clones much better on VMware, even if I've > tested nested virtualization to some degree with oVirt as well. It makes > moving forth and back between distros and restarting failed oVirt deployments > much easier and more reliable than ovirt-hosted-engine-cleanup. I agree - and IIRC the documentation does recommend reinstalling hosts on failed deployments rather than using ovirt-hosted-engine-cleanup. If you have a polished PXE framework, reinstalling a host should not take much clock time and close to zero actual-work time. > > Installing oVirt 4.10 4.4.10? > on TrueCentOS What's that? > systems, which had been freshly switched to Alma, Rocky and Oracle went > relatively well, apart from Oracle pushing UEK kernels, which break VDO (and > some Python2 mishaps). > > I'm still testing transitioning pre-existing TrueCentOS HCI glusters to Alma, > Rocky and Oracle. > > While that solves the issue of having the hosts running a mature OS which is > downstream of RHEL, there is still an issue with the management engine being > based on the upstream stream release: It doesn't have the vulnerability > managment baked in, which is required even for labs use in an enterprise. Not sure what you mean here, exactly. > > So I'd like to ask our Redhat friends here: How does this work when releases > of oVirt transition to RHV? RHV is built and supported only on RHEL, and RHV and RHEL releases are coordinated. So e.g. if in the next release of oVirt/RHV we want to use some feature that will only be included in the next RHEL release, we make sure to release RHV slightly after that. For oVirt, this is in principle irrelevant, because these new features are already in CentOS Stream by the time of oVirt's release. Sometimes we do have to manually help with this, e.g. because the "Advanced Virtualization" part of RHEL is not maintained in the main CentOS Stream process, but in the CentOS Virt SIG. I think all of this is quite clear for anyone following the relevant release announcements and the occasional discussions about missing parts. > Do you backport oVirt changes from Stream to RHEL? Not sure what exactly you mean here. oVirt is upstream of RHV, not RHEL. RHEL is not related to oVirt. Upstream of RHEL is CentOS Stream. > When bugs are found in that process, are they then fed back into oVirt or > into the oVirt-to-RHEV proces? Again, not sure what you mean. It sounds to me like your question(s) are purely about RHEL/CentOS, unrelated to oVirt/RHV. Please clarify. Thanks. The only thing in oVirt related to your question(s) AFAIU is the ovirt-engine-appliance and ovirt-node images. These are built/published/announced as needed if important CentOS security bug fixes are released. Again, this should be obvious to anyone following our announcements. Best regards, -- Didi ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/EQKNUOAOJUW5HTTQ23MX57LF5CJBGVPS/
[ovirt-users] Re: Can't upgrade ovirt 4.4.3 to 4.4.9
On Fri, Jan 21, 2022 at 12:02 PM wrote: > > Hello, > > I tried to upgrade ovirt to 4.4.9 from 4.4.3 > > when i do 'engine-setup' i get error > -- > [ ERROR ] Failed to execute stage 'Misc configuration': Command > '/usr/share/ovirt-engine-dwh/dbscripts/schema.sh' failed to execute > [ INFO ] DNF Performing DNF transaction rollback This rollback attempt, done due to the failure above, failed: > [ ERROR ] DNF module 'dnf.history' has no attribute 'open_history' This was fixed in otopi-1.9.6, but ovirt-engine-setup only requires otopi >= 1.9.0. We should either patch it, or change the upgrade documentation to include otopi. Perhaps you'd like to create a bug for this? > -- > from the log i found that column "count_threads_as_cores" does not exist > > --- > 193375 2022-01-18 16:36:26,309+0900 DEBUG > otopi.plugins.ovirt_engine_setup.ovirt_engine_dwh.db.schema plugin.execute > :926 execute-output: ['/usr/share/ovirt-engine-dwh/dbscripts/schema.sh', > '-s', 'localhost', '-p', '5432', '-u', 'ovirt_engine_history', '-d', > 'ovirt_engine_history', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setu > p-20220118162426-z0o4xg.log', '-c', 'apply'] stderr: > 193376 psql:/usr/share/ovirt-engine-dwh/dbscripts/create_views_4_4.sql:148: > ERROR: column "count_threads_as_cores" does not exist > 193377 LINE 10: count_threads_as_cores as count_threads_as_cores, This indeed looks like the root cause for the failure. Can you please share the full setup log? Thanks. > 193378^ > 193379 FATAL: Cannot execute sql command: > --file=/usr/share/ovirt-engine-dwh/dbscripts/create_views_4_4.sql > 193380 > 193381 2022-01-18 16:36:26,309+0900 DEBUG otopi.context > context._executeMethod:145 method exception > 193382 Traceback (most recent call last): > 193383 File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, > in _executeMethod > 193384 method['method']() > 193385 File > "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine-dwh/db/schema.py", > line 367, in _misc > 193386 odwhcons.DBEnv.PGPASS_FILE > 193387 File "/usr/lib/python3.6/site-packages/otopi/plugin.py", line 931, > in execute > 193388 command=args[0], > 193389 RuntimeError: Command > '/usr/share/ovirt-engine-dwh/dbscripts/schema.sh' failed to execute > 193390 2022-01-18 16:36:26,330+0900 ERROR otopi.context > context._executeMethod:154 Failed to execute stage 'Misc con > figuration': Command '/usr/share/ovirt-engine-dwh/dbscripts/schema.sh' failed > to execute > 193391 2022-01-18 16:36:26,330+0900 DEBUG otopi.transaction > transaction.abort:119 aborting 'DNF Transaction' > 193392 2022-01-18 16:36:26,331+0900 DEBUG > otopi.plugins.otopi.packagers.dnfpackager dnfpackager.verbose:75 DNF Closi > ng transaction with rollback > 193393 2022-01-18 16:36:26,731+0900 INFO > otopi.plugins.otopi.packagers.dnfpackager dnfpackager.info:79 DNF Performin > g DNF transaction rollback > 193394 2022-01-18 16:36:27,570+0900 ERROR > otopi.plugins.otopi.packagers.dnfpackager dnfpackager.error:84 DNF module > 'dnf.history' has no attribute 'open_history' > 193395 2022-01-18 16:36:27,571+0900 DEBUG otopi.transaction > transaction.abort:125 Unexpected exception from abort() of 'DNF > Transaction' > -- > > when i search for this problem, i found that column "count_threads_as_cores" > is added from ovirt-engine 4.4.6.7. and ovirt-dwh 4.4.7. Correct. Was added in an upgrade script. There might be a bug/issue/change in the order that the upgrade script runs vs create_views_* above. Adding Aviv and Shirly. > do i need to update 4.4.3 to 4.4.6( or 4.4.7) then 4.4.6(or 4.4.7) to 4.4.9? If you have a test system with 4.4.3, you can try there. On Fri, Jan 21, 2022 at 10:54 PM Thomas Hoberg wrote: > > Unfortunately I have no answer to your problem. > > But I'd like to know: where does that leave you? That's a good question, Thomas - thanks for raising it. I can't be sure without checking the setup log. Since the rollback failed, it depends on whether the rpm packages were already upgraded at that point or not. If you took a backup (engine-backup) before the upgrade, I think it would be
[ovirt-users] Re: New oVirt setup with OVN : Hypervisor with LACP bond : queries
On Sat, Jan 22, 2022 at 11:41 PM ravi k wrote: > Hello team, > Hi, Thank you for all the wonderful work you've been doing. I'm starting out > new with oVirt and OVN. So please excuse me if the questions are too naive. > We intend to do a POC to check if we can migrate VMs off our current > VMware to oVirt. The intention is to migrate the VMs with the same IP into > oVirt. We've setup oVirt with three hypervisors. All of them have four > ethernet adapters. We have SDN implemented in our network and LACP bonds > are created at the switch level. So we've created two bonds, bond0 and > bond1 in each hypervisor. bond0 has the logical networks with vlan tagging > created like bond0.101, bond0.102 etc. > Can you give some more details about your current vSphere infrastructure? What about the level of downtime you could give when migrating? Have you already planned the strategy to transfer your VMs from vSphere to oVirt? Take care that probably on your VMware side your VMs have virtual hw for nics defined as vmxnet, so when you migrate to oVirt, it will change and so depending on your OS type (Windows based or Linux based) and in case of Linux, depending on your distro and version, some manual operations could be required to remap vnic assignments and definitions. One possible first way to proceed could be to make a clone of one running VM into one disconnected from the vSphere infra and then test on it the steps to port to oVirt and so analyze times and impacts > As a part of the POC we also want to explore OVN as well to check if we > can implement a zero trust security policy. Here are the questions now :) > > 1. We would like to migrate VMs with the current IP into oVirt. Is it > possible to achieve this? I've been reading notes and pages that mention > about extending the physical network into OVN. But it's a bit confusing on > how to implement it. > How do we connect OVN to the physical network? Does the fact that we have > a SDN make it easier to get this done? > The downstream (RHV) documentation to do it is here: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/administration_guide/sect-adding_external_providers#Connecting_an_OVN_Network_to_a_Physical_Network the upstream one is here: https://www.ovirt.org/documentation/administration_guide/#Adding_OVN_as_an_External_Network_Provider Take care that in RHV this feature is still considered Technology Preview, so not recommended for production. It could apply to oVirt even more, so... BTW, what do you mean with "... the fact that we have a SDN..."? Do you mean standard virtual networking in contrast with physical one or do you have any kind of special networking in vSphere now (NSX or such...)? > > > 2. We have the IP for the hypervisor assigned on a logical > network(ovirtmgmt) in bond0. I read in > https://lists.ovirt.org/archives/list/users@ovirt.org/thread/CIE6MZ47GRCEX4Z6GWRLFSERCEODADJY/ > that oVirt does not care about how the IP is configured when creating the > tunnels. > That was a thread originated by me... ;-) But please consider that it is 5 years old now! At that time we were at 4.1 stage, while now we are at very different 4.4, so refer in case to recent threads and better recent upstream (oVirt) and downstream (RHV) official documentation pointed above Also, at that time ansible was not very much in place, while now in many configuration tasks it is deeply involved. The main concern in that thread was the impact of having OVN tunneling on the ovirtmgmt management network, that is the default choice when you configure OVN, in contrast with creating a dedicated network for it. > 3. Once we have OVN setup, ovn logical networks created and VMs > created/migrated, how do we establish the zero trust policy? From what I've > read there are ACLs and security groups. Any pointers on where to explore > more about implementing it. > The downstream documentation and notes for this is here: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/administration_guide/sect-external_provider_networks#Assigning_Security_Groups_to_Logical_Networks and upstream here: https://www.ovirt.org/documentation/administration_guide/#Assigning_Security_Groups_to_Logical_Networks some manual undocumented steps through OpenStack Networking API or Ansible could be required depending on your needs BTW: both upstream and downstream docs refer here to 4.2.7 : " In oVirt 4.2.7, security groups are disabled by default. " and " In Red Hat Virtualization 4.2.7, security groups are disabled by default. " They should be changed with the corresponding version, or into something like "in 4.2.7 and above..." if that applies and is intended > If you've read till here, thank you for your patience. > no problem ;-) Gianluca ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement:
[ovirt-users] Re: CentOS 8.4 Linux hosts from 4.4.8 to Rocky Linux 4.4.10
On Fri, Jan 21, 2022 at 6:28 PM Gianluca Cecchi wrote: > > Hello, > after updating the external engine from CentOS 8.4 and 4.4.8 to Rocky Linux > 8.5 and 4.4.9 as outlined here: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/YUDJRC22SQPAPAIURQIVSEMGITDRQOOM/ > I went further and updated also the hosts. > Environment is with an external engine and 3 CentOS Linux 8.4 hosts in 4.4.8 > with iSCSI storage domain. The term we use in the documentation for "not-a-self-hosted-engine" is "standalone engine". I hope it's clear enough. Sadly, we introduced it quite late in the game. > > Preliminarily I upgraded the engine to 4.4.10 (not yet the just released > async) without problems. > Then, one host at a time: > > . put host into maintenance from web admin UI > Management --> Maintenance > > . In a terminal f host set proxy for my environment needs > export https_proxy=http://my_proxy:my_proxy_port > export http_proxy=http://my_proxy:my_proxy_port (not sure if this > necessary...) > > . in the same terminal execute migration script > ./migrate2rocky.sh -r > > . executed Management --> SSH Management --> SSH Restart from web admin ui > the host comes on in maintenance mode > > . selected Installation --> Check for Upgrade but the host is detected as > already update > > . for further security and to be sure that all upgrade steps are applied I > executed > Installation --> Reinstall > I deselected > - activate host after install > - reboot host after install > It went ok so > > . executed Management --> SSH Management --> SSH Restart from web admin ui > the host comes on in maintenance mode > > . Management --> Activate > > . Empty another host moving its VMs to the just updated host and continue in > the same way, also electing as new SPM the updated host > > All went smoothly and without VMs disruption. > Let's see how it goes next days with the light workload I have on this > testing environment. > Currently the async 1 of 4.4.10 is not catched up by engine-upgrade-check > command.. I'm going to retry applying again during the next few days. Good luck, and thanks for the report! Best regards, -- Didi ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7D5I6N2JNXZ5I3G242LZN34CH2XFRLGL/
