December 2020 - Users - oVirt List Archives

High performance VM cannot migrate due to TSC frequency
by Gianluca Cecchi 18 Dec '20

18 Dec '20

Hello, I'm in 4.4.3 and CentOS 8.3 with 3 hosts. I have a high performance VM that is running on ov300 and is configured to be run on any host. It seems that both if I set or not the option Migrate only to hosts with the same TSC frequency I always am unable to migrate the VM and inside engine.log I see this: 2020-12-11 15:56:03,424+01 INFO [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (default task-36) [e4801b28-c832-4474-aa53-4ebfd7c6e2d0] Candidate host 'ov301' ('382bfc8f-60d5-4e06-8571-7dae1700574d') was filtered out by 'VAR__FILTERTYPE__INTERNAL' filter 'Migration-Tsc-Frequency' (correlation id: null) 2020-12-11 15:56:03,424+01 INFO [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (default task-36) [e4801b28-c832-4474-aa53-4ebfd7c6e2d0] Candidate host 'ov200' ('949d0087-2c24-4759-8427-f9eade1dd2cc') was filtered out by 'VAR__FILTERTYPE__INTERNAL' filter 'Migration-Tsc-Frequency' (correlation id: null) Can you verify if it is only my problem? Apart from the problem itself, what is "TSC frequency" and how can I check if my 3 hosts are different or not indeed? Normal VMs are able to migrate without problems Thanks, Gianluca

3 8

[ANN] oVirt 4.4.4 Sixth Release Candidate is now available for testing
by Lev Veyde 17 Dec '20

17 Dec '20

oVirt 4.4.4 Sixth Release Candidate is now available for testing The oVirt Project is pleased to announce the availability of oVirt 4.4.4 Sixth Release Candidate for testing, as of December 17th, 2020. This update is the fourth in a series of stabilization updates to the 4.4 series. How to prevent hosts entering emergency mode after upgrade from oVirt 4.4.1 Note: Upgrading from 4.4.2 GA or later should not require re-doing these steps, if already performed while upgrading from 4.4.1 to 4.4.2 GA. These are only required to be done once. Due to Bug 1837864 <https://bugzilla.redhat.com/show_bug.cgi?id=1837864> - Host enter emergency mode after upgrading to latest build If you have your root file system on a multipath device on your hosts you should be aware that after upgrading from 4.4.1 to 4.4.4 you may get your host entering emergency mode. In order to prevent this be sure to upgrade oVirt Engine first, then on your hosts: 1. Remove the current lvm filter while still on 4.4.1, or in emergency mode (if rebooted). 2. Reboot. 3. Upgrade to 4.4.4 (redeploy in case of already being on 4.4.4). 4. Run vdsm-tool config-lvm-filter to confirm there is a new filter in place. 5. Only if not using oVirt Node: - run "dracut --force --add multipath” to rebuild initramfs with the correct filter configuration 6. Reboot. Documentation - If you want to try oVirt as quickly as possible, follow the instructions on the Download <https://ovirt.org/download/> page. - For complete installation, administration, and usage instructions, see the oVirt Documentation <https://ovirt.org/documentation/>. - For upgrading from a previous version, see the oVirt Upgrade Guide <https://ovirt.org/documentation/upgrade_guide/>. - For a general overview of oVirt, see About oVirt <https://ovirt.org/community/about.html>. Important notes before you try it Please note this is a pre-release build. The oVirt Project makes no guarantees as to its suitability or usefulness. This pre-release must not be used in production. Installation instructions For installation instructions and additional information please refer to: https://ovirt.org/documentation/ This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 8.3 or newer * CentOS Linux (or similar) 8.3 or newer This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 8.3 or newer * CentOS Linux (or similar) 8.3 or newer * oVirt Node 4.4 based on CentOS Linux 8.3 (available for x86_64 only) See the release notes [1] for installation instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available for CentOS Linux 8 - oVirt Node NG is already available for CentOS Linux 8 Additional Resources: * Read more about the oVirt 4.4.4 release highlights: http://www.ovirt.org/release/4.4.4/ * 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] http://www.ovirt.org/release/4.4.4/ [2] http://resources.ovirt.org/pub/ovirt-4.4-pre/iso/ -- Lev Veyde Senior Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

Network Teamd support
by Carlos C 17 Dec '20

17 Dec '20

Hi folks, Does Ovirt 4.4.4 support or will support Network Teamd? Or only bonding? regards Carlos

3 2

Cannot connect Glusterfs storage to Ovirt
by Ariez Ahito 17 Dec '20

17 Dec '20

HI guys, i have installed ovirt 4.4 hosted engine and a separate glusterfs storage. now during hosted engine deployment when i try do choose STORAGE TYPE: gluster Storage connection: 10.33.50.33/VOL1 Mount Option: when i try to connect this gives me an error: [ ERROR ] ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is "[Problem while trying to mount target]". HTTP response code is 400. [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Fault reason is \"Operation Failed\". Fault detail is \"[Problem while trying to mount target]\". HTTP response code is 400."}

4 6

Move self hosted engine to a different gluster volume
by ralf＠os-s.de 17 Dec '20

17 Dec '20

Hi, I apparently successfully upgraded a hyperconverged self hosted setup from 4.3 to 4.4. During this process the selfhosted engine required a new gluster volume (/engine-new). I used a temporary storage for that. Is it possible to move the SHE back to the original volume (/engine)? What steps would be needed? Could I just do: 1. global maintenance 2. stop engine and SHE guest 3. copy all files from glusterfs /engine-new to /engine 4. use hosted-engine --set-shared-config storage <server1>:/engine hosted-engine --set-shared-config mnt_options backup-volfile-servers=<server2>:<server3> 5. disable maintenance Or are additional steps required? Kind regards, Ralf

1 0

Increase the initial size of LVM snapshots to prevent VM's from freezing
by Gal Villaret 16 Dec '20

16 Dec '20

Hi all, Lately, I have been encountering an issue where VMs freeze during backups. From what I can gather, this happens because some of the VMs sometimes perform large writes during the backup window and the snapshots dose not grow fast enough. I use ISCSI storage with all VM disks preallocated. Is there a configuration value I can change in order to increase the initial size of snapshots and also maybe change the watermark trigger for the expansion of snapshots? Thanks.

2 1

Bad CPU TYPE after Centos 8.3
by Lionel Caignec 15 Dec '20

15 Dec '20

Hi, i've just upgraded one host to latest centos release. And after reboot ovirt said "Host CPU type is not compatible with Cluster Properties." Looking on server i can see cpu is detected as skylake (cat /sys/devices/cpu/caps/pmu_name). My CPU is Intel(R) Xeon(R) Gold 5220R CPU @ 2.20GHz so according to ark cascade lake server. When i installed my new ovirt environment month agos, i configure cluster to be "secure Intel Cascade lake server family" and all sound goods. So anyone can help me? Environment : OS : Centos 8.3 (for manager and host in error) ovirt-engine 4.4.3.12-1.el8 Host with error : vdsm.x86_64 4.40.35.1-1.el8 Working Host : vdsm.x86_64 .40.26.3-1.el8 Maybe someone can help me? I don't know what to do, and does not want to try update another host if it fail... Sorry if i post my message at wrong place. Lionel Caignec.

5 15

How to unlock disk images?
by thomas＠hoberg.net 15 Dec '20

15 Dec '20

On one oVirt 4.3 farm I have three locked images I'd like to clear out. One is an ISO image, that somehow never completed the transfer due to a slow network. It's occupying little space, except in the GUI where it sticks out and irritates. I guess it would just be an update somewhere on the Postgress database to unlock it and have it deletable: But since the schema isn't documented, I'd rather ask here: How to I unlock the image? Two are left-overs from a snapshot that somehow never completed, one for the disk another for the RAM part. I don't know how my colleague managed to get into that state, but impatience/concurrency probably was a factor, a transient failure of a node could have been another. In any case the snapshot operation logically has been going on for weeks without any real activity, survived several restarts (after patches) of all nodes and the ME and shows no sign of disappearing voluntarily. Again, I'd assume that I need to clear out the snapshot job, unlock the images and then delete what's left. Some easy SQL and most likely a management engine restart afterwards... if you knew what you were doing (or there was an option in the GUI). So how do I list/delete snapshot jobs that aren't really running any more? And how do I unlock the images so I can delete them? Thanks for your help!

2 4

illegal disk status
by Daniel Menzel 15 Dec '20

15 Dec '20

Hi, we have a problem with some VMs which cannot be started anymore due to an illegal disk status of a snapshot. What happend (most likely)? we tried to snapshot those vms some days ago but the storage domain didn't have enough free space left. Yesterday we shut those vms down - and from then on they didn't start anymore. What have I tried so far? 1. Via the web interface I tried to remove the snapshot - didn't work. 2. Searched the internet. Found (among other stuff) this: https://bugzilla.redhat.com/show_bug.cgi?id=1649129 3. via /vdsm-tool dump-volume-chains/ I managed to list those 5 snapshots (see below). The output for one machine was: image: 2d707743-4a9e-40bb-b223-83e3be672dfe - 9ae6ea73-94b4-4588-9a6b-ea7a58ef93c9 status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL, type: PREALLOCATED, capacity: 32212254720, truesize: 32212254720 - f7d2c014-e8f5-4413-bfc5-4aa1426cb1e2 status: ILLEGAL, voltype: LEAF, format: COW, legality: ILLEGAL, type: SPARSE, capacity: 32212254720, truesize: 29073408 So my idea was to follow the said bugzilla thread and update the volume - but I didn't manage to find input for the /job_id/ and /generation/. So my question is: Does anyone have an idea on how to (force) remove a given snapshot via vsdm-{tool|client}? Thanks in advance! Daniel -- Daniel Menzel Geschäftsführer Menzel IT GmbH Charlottenburger Str. 33a 13086 Berlin +49 (0) 30 / 5130 444 - 00 daniel.menzel(a)menzel-it.net https://menzel-it.net Geschäftsführer: Daniel Menzel, Josefin Menzel Unternehmenssitz: Berlin Handelsregister: Amtsgericht Charlottenburg Handelsregister-Nummer: HRB 149835 B USt-ID: DE 309 226 751

2 1

Nodes install Python3 every day
by jb 15 Dec '20

15 Dec '20

Hello, I notice a strange thing in the logs. All Nodes (ovirt 4.4.3.12-1.el8) install every days again Python3, after checking for updates. The GUI log shows this entries: 13.12.2020, 11:39 Check for update of host onode1.example.org. Gathering Facts. 13.12.2020, 11:39 Check for update of host onode1.example.org. include_tasks. 13.12.2020, 11:39 Check for update of host onode1.example.org. Detect host operating system. 13.12.2020, 11:39 Check for update of host onode1.example.org. Fetch installed packages. 13.12.2020, 11:39 Check for update of host onode1.example.org. Check if vdsm is preinstalled. 13.12.2020, 11:39 Check for update of host onode1.example.org. Parse operating system release. 13.12.2020, 11:39 Check for update of host onode1.example.org. Detect if host is a prebuilt image. 13.12.2020, 11:39 Check for update of host onode1.example.org. Install Python3 for CentOS/RHEL8 hosts. 13.12.2020, 11:39 Check for update of host onode1.example.org. Set facts. /var/log/ovirt-engine/ansible-runner-service.log shows: 2020-12-13 11:39:20,849 - runner_service.services.playbook - DEBUG - cb_event_handler event_data={'uuid': '7c4b039d-6212-4b52-95fd-40d85036ed98', 'counter': 33, 'stdout': 'ok: [onode1.example.org]', 'start_line': 31, 'end_line': 32, 'runner_ident': '72737578-3d2f-11eb-b955-00163e33f845', 'event': 'runner_on_ok', 'pid': 603696, 'created': '2020-12-13T10:39:20.847869', 'parent_uuid': '00163e33-f845-ee64-acee-000000000013', 'event_data': {'playbook': 'ovirt-host-check-upgrade.yml', 'playbook_uuid': '0eb5c935-9f17-4b07-961e-7e0a866dd5ed', 'play': 'all', 'play_uuid': '00163e33-f845-ee64-acee-000000000008', 'play_pattern': 'all', 'task': 'Install Python3 for CentOS/RHEL8 hosts', 'task_uuid': '00163e33-f845-ee64-acee-000000000013', 'task_action': 'yum', 'task_args': '', 'task_path': '/usr/share/ovirt-engine/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml:20', 'role': 'ovirt-host-deploy-facts', 'host': 'onode1.example.org', 'remote_addr': 'onode1.example.org', 'res': {'msg': 'Nothing to do', 'changed': False, 'results': [], 'rc': 0, 'invocation': {'module_args': {'name': ['python3'], 'state': 'present', 'allow_downgrade': False, 'autoremove': False, 'bugfix': False, 'disable_gpg_check': False, 'disable_plugin': [], 'disablerepo': [], 'download_only': False, 'enable_plugin': [], 'enablerepo': [], 'exclude': [], 'installroot': '/', 'install_repoquery': True, 'install_weak_deps': True, 'security': False, 'skip_broken': False, 'update_cache': False, 'update_only': False, 'validate_certs': True, 'lock_timeout': 30, 'conf_file': None, 'disable_excludes': None, 'download_dir': None, 'list': None, 'releasever': None}}, '_ansible_no_log': False}, 'start': '2020-12-13T10:39:19.872585', 'end': '2020-12-13T10:39:20.847636', 'duration': 0.975051, 'event_loop': None, 'uuid': '7c4b039d-6212-4b52-95fd-40d85036ed98'}} Is this a bug? Best regards Jonathan

3 4