Thanks and well done everyone. No virtual release party ? ?? Regards, Paul S. ________________________________ From: Sandro Bonazzola <sbonazzo(a)redhat.com&gt; Sent: 20 May 2020 13:54 To: users <users(a)ovirt.org>; oVirt development list <devel(a)ovirt.org>; infra <infra(a)ovirt.org&gt; Subject: [ovirt-users] oVirt 4.4.0 Release is now generally available Caution External Mail: Do not click any links or open any attachments unless you trust the sender and know that the content is safe. oVirt 4.4.0 Release is now generally available The oVirt Project is excited to announce the general availability of the oVirt 4.4.0 Release, as of May 20th, 2020 This release unleashes an altogether more powerful and flexible open source virtualization solution that encompasses hundreds of individual changes and a wide range of enhancements across the engine, storage, network, user interface, and analytics, as compared to oVirt 4.3. Important notes before you install / upgrade Some of the features included in the oVirt 4.4.0 release require content that will be available in CentOS Linux 8.2 but cannot be tested on RHEL 8.2 yet due to some incompatibility in the openvswitch package that is shipped in CentOS Virt SIG, which requires rebuilding openvswitch on top of CentOS 8.2. The cluster switch type OVS is not implemented for CentOS 8 hosts. Please note that oVirt 4.4 only supports clusters and datacenters with compatibility version 4.2 and above. If clusters or datacenters are running with an older compatibility version, you need to upgrade them to at least 4.2 (4.3 is recommended). Please note that in RHEL 8 / CentOS 8 several devices that worked on EL7 are no longer supported. For example, megaraid_sas driver is removed. If you use Enterprise Linux 8 hosts you can try to provide the necessary drivers for the deprecated hardware using the DUD method (See users mailing list thread on this at https://lists.ovirt.org/archives/list/users@ovirt.org/thread/NDSVUZSESOXE... ) Installation instructions For the engine: either use the oVirt appliance or install CentOS Linux 8 minimal by following these steps: - Install the CentOS Linux 8 image from http://centos.mirror.garr.it/centos/8.1.1911/isos/x86_64/CentOS-8.1.1911-... - dnf install https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm<https://e... - dnf update (reboot if needed) - dnf module enable -y javapackages-tools pki-deps postgresql:12 - dnf install ovirt-engine - engine-setup For the nodes: Either use oVirt Node ISO or: - Install CentOS Linux 8 from http://centos.mirror.garr.it/centos/8.1.1911/isos/x86_64/CentOS-8.1.1911-...;, selecting the minimal installation. - dnf install https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm<https://e... - dnf update (reboot if needed) - Attach the host to the engine and let it be deployed. Update instructions Update from oVirt 4.4 Release Candidate On the engine side and on CentOS hosts, you’ll need to switch from ovirt44-pre to ovirt44 repositories. In order to do so, you need to: 1. dnf remove ovirt-release44-pre 2. rm -f /etc/yum.repos.d/ovirt-4.4-pre-dependencies.repo 3. rm -f /etc/yum.repos.d/ovirt-4.4-pre.repo 4. dnf install https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm<https://e... 5. dnf update On the engine side you’ll need to run engine-setup only if you were not already on the latest release candidate. On oVirt Node, you’ll need to upgrade with: 1. Move node to maintenance 2. dnf install https://resources.ovirt.org/pub/ovirt-4.4/rpm/el8/noarch/ovirt-node-ng-im... 3. Reboot 4. Activate the host Update from oVirt 4.3 oVirt 4.4 is available only for CentOS 8. In-place upgrades from previous installations, based on CentOS 7, are not possible. For the engine, use backup, and restore that into a new engine. Nodes will need to be reinstalled. A 4.4 engine can still manage existing 4.3 hosts, but you can’t add new ones. For a standalone engine, please refer to upgrade procedure at https://ovirt.org/documentation/upgrade_guide/#Upgrading_from_4-3<http... If needed, run ovirt-engine-rename (see engine rename tool documentation at https://www.ovirt.org/documentation/admin-guide/chap-Utilities.html<ht... ) When upgrading hosts: You need to upgrade one host at a time. 1. Turn host to maintenance. Virtual machines on that host should migrate automatically to a different host. 2. Remove it from the engine 3. Re-install it with el8 or oVirt Node as per installation instructions 4. Re-add the host to the engine Please note that you may see some issues live migrating VMs from el7 to el8. If you hit such a case, please turn off the vm on el7 host and get it started on the new el8 host in order to be able to move the next el7 host to maintenance. What’s new in oVirt 4.4.0 Release? * Hypervisors based on CentOS Linux 8 (rebuilt from award winning RHEL8), for both oVirt Node and standalone CentOS Linux hosts. * Easier network management and configuration flexibility with NetworkManager. * VMs based on a more modern Q35 chipset with legacy SeaBIOS and UEFI firmware. * Support for direct passthrough of local host disks to VMs. * Live migration improvements for High Performance guests. * New Windows guest tools installer based on WiX framework now moved to VirtioWin project. * Dropped support for cluster level prior to 4.2. * Dropped API/SDK v3 support deprecated in past versions. * 4K block disk support only for file-based storage. iSCSI/FC storage do not support 4K disks yet. * You can export a VM to a data domain. * You can edit floating disks. * Ansible Runner (ansible-runner) is integrated within the engine, enabling more detailed monitoring of playbooks executed from the engine. * Adding and reinstalling hosts is now completely based on Ansible, replacing ovirt-host-deploy, which is not used anymore. * The OpenStack Neutron Agent cannot be configured by oVirt anymore, it should be configured by TripleO instead. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 8.1 * CentOS Linux (or similar) 8.1 This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 8.1 * CentOS Linux (or similar) 8.1 * oVirt Node 4.4 based on CentOS Linux 8.1 (available for x86_64 only) See the release notes [1] for installation instructions and a list of new features and bugs fixed. If you manage more than one oVirt instance, OKD or RDO we also recommend to try ManageIQ<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2...;. In such a case, please be sure to take the qc2 image and not the ova image. 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.0 release highlights: http://www.ovirt.org/release/4.4.0/<https://eur02.safelinks.protection... * Get more oVirt project updates on Twitter: https://twitter.com/ovirt<https://eur02.safelinks.protection.outlook.c... * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/<https://eur02.safelinks.protection.outlook.... [1] http://www.ovirt.org/release/4.4.0/<https://eur02.safelinks.protection... [2] http://resources.ovirt.org/pub/ovirt-4.4/iso/<https://eur02.safelinks.... -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2... sbonazzo@redhat.com<mailto:sbonazzo@redhat.com> [https://static.redhat.com/libs/redhat/brand-assets/2/corp/logo--200.png]&... [|Our code is open_]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F... Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. To view the terms under which this email is distributed, please go to:- http://leedsbeckett.ac.uk/disclaimer/email/

Il giorno mer 20 mag 2020 alle ore 16:33 <thomas(a)hoberg.net&gt; ha scritto: oVirt 4.3.10 is approaching GA and we expect 4.3.11 to be released too before declaring 4.3 at the end of life. After that, 4.3 should keep working till CentOS 7 or any other repo on the system will break it with some incompatible change. I totally understand system administrators' point of view and how difficult it is to find a good maintenance window for a busy production environment, ensuring backups are recent enough, check new requirements matching, give it a try on a test environment if it's available and so on. That said, I would really encourage starting to plan a maintenance window for upgrading to 4.4 as soon as practical. It will be easier to help with upgrade from 4.3 at this time than 2 years from now when 4.3 can be broken (or new hardware replacement will be missing drivers on CentOS 7) and there won't be any additional release for fixing upgrade incompatibilities. -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> [image: |Our code is open_] <https://www.redhat.com/en/our-code-is-open> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

Il Mer 20 Mag 2020, 18:15 Derek Atkins <derek(a)ihtfp.com&gt; ha scritto: [snip] I am happy to share my startup script if someone else wants to port it to Interesting. yes, please. We could try to convert to python or through ansible and/or leverage already existing roles/modules. Gianluca

On Wed, May 20, 2020 at 7:05 PM Derek Atkins <derek(a)ihtfp.com&gt; wrote: [snip] Hi Derek, today I played around with Ansible to accomplish, I think, what you currently do in oVirt shell. It was the occasion to learn, as always, something new: as "blocks" in Ansible dont' support looping, a workaround to get that. Furthermore I have a single host environment where it can turn usefull too... The script is supposed to be run on engine, as you already do now. There is a main script, startup.yml, that is the playbook expected to be run in a way such as: /usr/bin/ansible-playbook --vault-password-file=pwfile startup.yml Some explanations below. On engine you need ansible and ovirt-engine-sdk-python packages, that I think are installed by default. The script can be executed with a non root user. In your scripts I see that you don't explicitly set a timeout. In my ansible tasks where I have to wait (connection to engine, storage domains up and DC up), I set a delay of 10 seconds and a retries of 90 for each of them. So for each task where there is an until condition you have 15 minutes the job can wait before failing. You can adjust the values of delay and/or retries. To accomplish the loop over VMs to start them up and set their custom timeout before starting next one, I have an include of a task file: vm_block.yml Inside the directory where you put the two yml files, you will also have a vars directory, where you put your customized var files. In my example I have encrypted two of them with the ansible-vault command and then put the password inside a file named pwfile (that has to simply contain the password). Otherwise you can create in clear all the var files and call the playbook with: /usr/bin/ansible-playbook startup.yml The var files: 1) ovirt_credentials.yml 2) db_credentials.yml 3) vm_vars.yml 1) contains ovirt credentials. In clear it is something like: --- ovirt_username: "admin@internal" ovirt_password: "admin_password" ovirt_ca: "my_ovirt.pem" url_name: engine_hostname ... 2) contains engine db credentials. This is needed because I didn't find an oVirt ansible module or python API that gives you the status of storage domains. It would be nice for the ovirt_storage_domain_info ansible module to have it.... So I use connection to engine db and make a select against the storage_domains table, where the status up is expressed by the status column having a value of 3. BTW: you find the engine db credentials for your engine inside file: /etc/ovirt-engine/engine.conf.d/10-setup-database.conf Contents of the var file (you have only to update the password one, randomly generated during the first engine-setup): --- dbserver: localhost db: engine username: engine password: "TLj63Wvw2yKyDPjlJ9fEku" ... 3) contains variables for your VM ordered names and timeouts, together with the default timeout I have not encrypted this file, so its contents are in my test case --- default_timeout: 10 vms: - name: f30 timeout: 30 - name: slax ... At the end in the directory where you set up your files/directories you will have something like this: -rwx------. 1 g.cecchi g.cecchi 1343 May 24 12:19 my_ovirt.pem -rw-------. 1 g.cecchi g.cecchi 6 May 24 12:18 pwfile -rwx------. 1 g.cecchi g.cecchi 2312 May 25 00:38 startup.yml -rwx------. 1 g.cecchi g.cecchi 225 May 24 21:00 vm_block.yml vars/: total 12 -rw-------. 1 g.cecchi g.cecchi 679 May 25 00:14 db_credentials.yml -rwx------. 1 g.cecchi g.cecchi 808 May 24 21:02 ovirt_credentials.yml -rw-rw-r--. 1 g.cecchi g.cecchi 78 May 24 20:37 vm_vars.yml You can find here: startup.yml https://drive.google.com/file/d/19F16TAAfneYbMnAuUE-BlTI-VNf8l4Yx/view?us... vm_block.yml https://drive.google.com/file/d/1tHCcP5pBlkjeixIF8GGdhGRNaNBGhwbR/view?us... NOTE: in my case I have two storage domains unattached, the ovirt image one and an export one. So inside startup.yml you find: expected_sd_up: "{{ ( result_sd.ovirt_storage_domains | length ) - 2 }}" Change "- 2" with "- 1" for your environment. Executing the job in the rc.local you would get something like this where you redirect output: [g.cecchi@ovirt ~]$ ansible-playbook --vault-password-file=pwfile startup.yml [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all' PLAY [Play to start oVirt VMs] ********************************************************************* TASK [Gathering Facts] ***************************************************************************** ok: [localhost] TASK [Obtain SSO token using username/password credentials] **************************************** FAILED - RETRYING: Obtain SSO token using username/password credentials (90 retries left). .... ok: [localhost] TASK [Sleep for 60 seconds] ************************************************************************ Pausing for 60 seconds (ctrl+C then 'C' = continue early, ctrl+C then 'A' = abort) ok: [localhost] TASK [Get storage domains] ************************************************************************* ok: [localhost] TASK [Set storage domains to be active] ************************************************************ ok: [localhost] TASK [Print expected storage domains to be up] ***************************************************** ok: [localhost] => { "msg": "Expected storage domains to be up: 3" } TASK [Query storage_domains table] ************************************************************** [WARNING]: conditional statements should not include jinja2 templating delimiters such as {{ }} or {% %}. Found: sd_up.query_result[0].up_sd == {{ expected_sd_up }} FAILED - RETRYING: Query storage_domains table (90 retries left). ... ok: [localhost] TASK [Print storage domains that are up] *********************************************************** ok: [localhost] => { "msg": "Number of storage domains up: 3" } TASK [Verify DC is up] ***************************************************************************** FAILED - RETRYING: Verify DC is up (90 retries left). ... ok: [localhost] TASK [External block to start VMs] ***************************************************************** included: /home/g.cecchi/vm_block.yml for localhost included: /home/g.cecchi/vm_block.yml for localhost TASK [Start VM f30] ************************************************************************************ changed: [localhost] TASK [Pause before starting next VM] *************************************************************** ok: [localhost] TASK [Start VM slax] ************************************************************************************ changed: [localhost] TASK [Pause before starting next VM] *************************************************************** ok: [localhost] TASK [Revoke SSO token] **************************************************************************** ok: [localhost] PLAY RECAP ***************************************************************************************** localhost : ok=15 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Cheers, Gianluca

Thanks Derek, GitHub or GitLab probably. Regards, Paul S. ________________________________ From: Derek Atkins <derek(a)ihtfp.com&gt; Sent: 27 May 2020 15:50 To: Gianluca Cecchi <gianluca.cecchi(a)gmail.com&gt; Cc: thomas(a)hoberg.net <thomas(a)hoberg.net>; users <users(a)ovirt.org&gt; Subject: [ovirt-users] AutoStart VMs (was Re: Re: oVirt 4.4.0 Release is now generally available) Caution External Mail: Do not click any links or open any attachments unless you trust the sender and know that the content is safe. Hi, (Sorry if you get this twice -- looks like it didn't like the python script in there so I'm resending without the code) Gianluca Cecchi <gianluca.cecchi(a)gmail.com&gt; writes: [snip] I found the time to work on this using the Python SDK. Took me longer than I wanted but I think I've got something working now. I just haven't done a FULL test, yet, but a runtime time on the online system works (I commented out the start call). I still have two files, a vm_list.py which is a config file that contains the list of VMs, in order, and then the main program itself (start_vms.py) which is based on several of the examples available in github. Unfortunately I can't seem to send the script in email because it's getting blocked by the redhat server -- so I have no idea the best way to share it. -derek -- Derek Atkins 617-623-3745 derek(a)ihtfp.com https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ihtf... Computer and Internet Security Consultant _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org Privacy Statement: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovi... oVirt Code of Conduct: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovi... List Archives: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.o... To view the terms under which this email is distributed, please go to:- http://leedsbeckett.ac.uk/disclaimer/email/

Hi, On Wed, May 27, 2020 5:38 pm, Gianluca Cecchi wrote: [snip] I do. Can't stand it. Doesn't mean I can't read it and/or write it, but I have to hold my nose doing it. Syntactic white space? Eww. But Python is already installed and used and, apparently, supported.. And when I looked at the examples I found that 90% of what I needed to do was already implemented, so it turned out to be much easier than expected. It's pretty much a direct translation of my bash script around ovirt-shell. It does have one feature that the old code didn't, which is the ability to wait for ovirt to declare that a vm is actually "up". I've never even installed ansible, let alone tried to use it. I don't need flexibility, I need the job to get done. But I'll take a look when I get the chance. Thanks! -derek PS: you (meaning whomever is "in charge" is welcome to add my script(s) to the examples repo if you feel other people would benefit from seeing it there. -- Derek Atkins 617-623-3745 derek(a)ihtfp.com www.ihtfp.com Computer and Internet Security Consultant

Hi, Strahil Nikolov <hunter86_bg(a)yahoo.com&gt; writes: Thank you for your input. Turns out it's probably not an issue right now anyways because my understanding is that there is no "live" upgrade path from 4.3/7.x to 4.4/8.x. My understanding is that the only upgrade path is a re-install. If that's the case, then I suspect it will be a VERY long time until I upgrade, because I'm on a single-host production system so can't stage a reinstall the same way I can stage a "yum upgrade". I guess only time will tell ;) There wasn't a significant learning curve to python (as I've already had experience with it, and most of what I needed to do was already in the SDK examples). Ansible is a tool I have never even looked at, let alone tried to use it, so I suspect it would take me more than a couple hours to get it working. -derek -- Derek Atkins 617-623-3745 derek(a)ihtfp.com www.ihtfp.com Computer and Internet Security Consultant

On Wed, May 20, 2020 at 7:16 PM Derek Atkins <derek(a)ihtfp.com&gt; wrote: Why not open RFE to add the feature you need? You can use the python SDK to do anything supported by oVirt API. Did you look here? https://github.com/oVirt/ovirt-engine-sdk/tree/master/sdk/examples

Hi, On Wed, May 20, 2020 3:06 pm, Gianluca Cecchi wrote: Self-hosted engine. NFS served by the host itself. Both Host and Engine are CentOS-based systems with ovirt installed on top of it. Currently running 4.3.8; I plan to upgrade to 4.3.10 (and 7.8) once it goes GA. The start_vms.sh script is, of course, run on the engine, and runs with a user with appropriate privs to start VMs. Thanks! -derek -- Derek Atkins 617-623-3745 derek(a)ihtfp.com www.ihtfp.com Computer and Internet Security Consultant

On May 21, 2020 6:08:19 PM GMT+03:00, Derek Atkins <derek(a)ihtfp.com&gt; wrote: Actually, You can use Ansible and 'uri' module to communicate wwith the engine via the API. Most probably the 'uri' module was written in python - but you don't have to deal with python code - just ansible. Also, it's worth checking the ansible Ovirt modules , as they are kept up to date evwn when the API endpoint changes. I think it won't be too hard to get a list of the VMs and then create some logic how to order them for the 'ignition'. Best Regards, Strahil Nikolov

On Fri, May 22, 2020 at 4:17 PM Derek Atkins <derek(a)ihtfp.com&gt; wrote: Actually at least one time last week I had a situation where after a crash of a single host environment with 4.3.9 and gluster on host itself, all 3 gluster storage domains resulted active but actually only the engine rhev mount point was up and not the other 3 configured Something like this: /rhev/data-center/mnt/glusterSD/ovirtst.mydomai.storage:_engine While for the other 3 storage domains I only had the gluster brick active but not the filesystem mounted. In web admin gui all the storage domains was marked as active.... and as soon as I powered on the first VM the operation went into error of course and only at that time the 3 storage domains were marked as down... From the web admin gui I was able to then activate them and start VMs. I had no time to investigate more and so opening a bug for that... The problem is that in my opinion the datacenter was marked as up too, so your check would not be of great meaning. In my opinion you could crosscheck also storage domains number with expected mount points of type /rhev/data-center/mnt/... Gianluca

On Fri, May 22, 2020 at 6:18 PM Strahil Nikolov <hunter86_bg(a)yahoo.com&gt; wrote: As I wrote, it happens sometime that the storage domains are marked as up, but actually they are not (the related /rhev/data-center/mnt/... filesystem not mounted) It happened to me several times, only when restarting from a crash (not always though) and only in single host configurations. Both in NFS config (not supported actually) and in Gluster config (supposed to be supported). Gianluca

Ciao Sandro, just tried to re-install a Centos7 based HCI cluster because it had moved to another network. And from what I can tell it fails because Gobinda Das introduced a hot-fix into 'gluster-ansible-infra/roles/backend_setup/tasks/vdo_create.yml' that adds a '--maxDiscardSize 16M' option statically on April 13th. Only problem, the vdo 6.1 that is part of the CentOS7/oVirt 4.3.10 stack doesn't know that option at all, it seems to have been introduced for VDO 6.2 which is COS 8 based. Questions: Should this not be caught by automated testing? Where and how do I need to fill a bug report in such a way that it gets to Gobinda or his team?

May be we need to check for VDO version. Will check and update. @Prajith Kesava Prasad <pkesavap(a)redhat.com&gt; Can please take a look? On Wed, Jun 17, 2020 at 7:43 PM Yedidyah Bar David <didi(a)redhat.com&gt; wrote: -- Thanks, Gobinda

Dear oVirt users, any news on the gluster support side on oVirt 4.3. With 6.10 being possibly the latest release, it would be nice if there is an known stable upgrade path to either gluster 7 and possibly 8 for the oVirt 4.3 branch. Thanks Olaf

Hi Strahil, Thanks for confirming v7 is working fine with oVirt 4.3, it being from you, gives quite some faith. If that's generally the case it would be nice if the yum repo ovirt-4.3-dependencies.repo could be updated to the gluster - v7 in the official repository e.g.; [ovirt-4.3-centos-gluster7] name=CentOS-$releasever - Gluster 7 baseurl=http://mirror.centos.org/centos/7/storage/$basearch/gluster-7/ gpgcheck=1 enabled=1 gpgkey=https://www.centos.org/keys/RPM-GPG-KEY-CentOS-SIG-Storage keeping the gluster support up-to-date, gives at least some users the time to plan the upgrade path to oVirt 4.4, while remaining to not to run on EOL gluster's. Thanks Olaf Op di 11 aug. 2020 om 19:35 schreef Strahil Nikolov <hunter86_bg(a)yahoo.com&gt;:

Hi Strahil, It's not really clear how i can pull requests to the oVirt repo. I've found this bugzilla issue for going from v5 to v6; https://bugzilla.redhat.com/show_bug.cgi?id=1718162 with this corresponding commit; https://gerrit.ovirt.org/#/c/100701/ Would the correct route be to issue a bugzilla request for this? Thanks Olaf

Hi Strahil, Ok done; https://bugzilla.redhat.com/show_bug.cgi?id=1868393 only it didn't allow me to select the most recent 4.3. Thanks Olaf Op wo 12 aug. 2020 om 15:58 schreef Strahil Nikolov <hunter86_bg(a)yahoo.com&gt;: