- Devel - oVirt List Archives

Re: Starting with oVirt
by Strahil Nikolov 02 Sep '22

02 Sep '22

Hardware wise - try one server with CentOS Stream 8 and check that all hardware is recognized and works as expected. You can start with a single server and expand further. RH dropped Gluster Support for their downstream solution (RHV) , yet oVirt doesn't have plans to get rid of it. The easiest for you would be to use SAN or NAS as storage. If that's not an option, you can use GlusterFS - which is a distributed File System . The latter needs a 10GBE NICs (1 Gigabit is OK, but don't expect much speed when writing in the VMs). oVirt supports GlusterFS in 2 modes:- replica 1 - a mode intended for a single host setup- replica 3 (where you have 3 copies of your data) - where the storage nodes should be multiple to 3. You can also have compute-only oVirt nodes (those do not participate in GlusterFS but have CPU & RAM to host VMs) If you configure HA VMs , the engine will take care to recover them on another host. If you loose 2 out of 3 servers - GlusterFS will loose majority of the bricks (term for a host+mount point combination) and will shutdown until majority is restored. In all cases - you should segregate the network for Storage and Compute workloads (Gluster/NFS on separate network). P.S.: iSCSI is also a storage option. Best Regards,Strahil Nikolov On Fri, Sep 2, 2022 at 9:29, Teemu Saarinen<teemu.saarinen(a)netum.fi> wrote:  Hi, Our company is planning oftaking oVirt in into our environment. We would have a few questions for that if you could guide us. Hardware: What would be the minimum configuration for us using oVirt?.Idea would be to replace all our current Linux and Windows servers withoVirt. There are currently 24 servers in use. The goal would also be that the virtual servers could be migrated live and also in the HA configuration, i.e. if onehardware crashes execution continues on the other. As far as I understand Ovirt enables this? So we would like to know what kind ofhardware (minimum) we should have for this size of environment? Storagin: Do all machines need a lot of hard disk space or is it enough to have only one or two? I'm referring to shared storage. Can you also have storagin as HA? Host: What happens to HOST1 and HOST2 virtual machines if the oVirt host server crashes? Do they continue to operate without it, or do they crash at the same time? Thank You! Teemu S. _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)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/devel@ovirt.org/message/CTLLKBXYUZQEL…

1 0

[ACTION REQUIRED] engine-setup: getCredentials updated
by Yedidyah Bar David 25 Aug '22

25 Aug '22

Hi all, We now merged all of these patches: [1] https://github.com/oVirt/otopi/pull/29 [2] https://github.com/oVirt/ovirt-engine/pull/585 [3] https://github.com/oVirt/ovirt-engine-keycloak/pull/53 [4] https://github.com/oVirt/ovirt-dwh/pull/47 If you have a new dwh and/or keycloak, and an older engine, and run engine-setup, and get an error about getCredentials, please update both otopi and the engine. Thanks and best regards, -- Didi

1 3

Macintosh-oVirt integration with new VIRTIO compliant virtualization framework?
by ovirt＠pixerati.com 24 Aug '22

24 Aug '22

Now that Apple has implemented a VIRTIO-compliant framework (https://developer.apple.com/documentation/virtualization) has anyone tried automating VM deployment to a Macintosh host using oVirt? I'm assuming this would have to take the form of some sort of Ansible hack, correct? I can't imagine getting a Macintosh to show up as a managed node would be a simple task...

1 0

Change in DNF COPR plugin requires action
by Marcin Sobczyk 23 Aug '22

23 Aug '22

Hi All, recently there was a PR merged to DNF COPR plugin [1] that makes the default chroot on CentOS Stream 9 to be 'epel-9'. Because of this we now need to specify the 'centos-stream-9' chroot name that we use in oVirt COPR explicitly, i.e.: dnf copr enable -y ovirt/ovirt-master-snapshot centos-stream-9 I can see there's a bunch of places throughout our projects that need an update. I'll post PRs for the ones I can spot. Regards, Marcin [1] https://github.com/rpm-software-management/dnf-plugins-core/pull/459/files

2 3

ovirt-engine-4.5.2.4 has been tagged
by Martin Perina 19 Aug '22

19 Aug '22

ovirt-engine-4.5.2.4 has been tagged -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.

1 0

github testing: merge with branch, or use PR HEAD?
by Yedidyah Bar David 17 Aug '22

17 Aug '22

Hi all, I was annoyed for some time now by the fact that when I used some github-CI-generated RPMs, with a git hash in their names, I could never find this git hash anywhere - not in my local git repo, nor in github. Why is it so? Because, if I got it right, the default for 'actions/checkout@v2' is to merge the PR HEAD with the branch HEAD. See e.g. [1]: HEAD is now at 7bbb40c9a Merge 026bb9c672bf46786dd6d16f4cbe0ecfa84c531d into 35e217936b5571e9657946b47333a563373047bb Meaning: my patch was 026bb9c, master was 35e2179, and the generated RPMs will have 7bbb40c9a, not to be found anywhere else. If you check the main PR page [3], you can find there '026bb9c', but not '7bbb40c9a'. (Even 026bb9c might require some effort, e.g. "didib force-pushed the add-hook-log-console branch 2 times, most recently from c90e658 to 66ebc88 yesterday". I guess this is the result of github discouraging force-pushes, in direct opposite of gerrit, which had a notion of different patchsets for a single change. I already ranted about this in the past, but that's not the subject of the current message). This is not just an annoyance, it's a real difference in semantics. In gerrit/jenkins days, IIRC most/all projects I worked on, ran CI testing/building on the pushed HEAD, and didn't touch it. Rebase, if at all, happened either explicitly, or at merge time. actions/checkout's default, to auto-merge, is probably meant to be more "careful" - to test what would happen if the code is merged. I agree this makes sense. But I personally think it's almost always ok to test on the pushed HEAD and not rebase/merge _implicitely_. What do you think? It should be easy to change, using [2]: - uses: actions/checkout@v2 with: ref: ${{ github.event.pull_request.head.sha }} No need to reach a complete consensus - can be decided upon per-project/repo. But if you disagree, I'd like to understand why. Thanks. Best regards, [1] https://github.com/oVirt/vdsm/runs/6881311961?check_suite_focus=true [2] https://github.com/marketplace/actions/checkout?version=v2.4.2#checkout-pul… [3] https://github.com/oVirt/vdsm/pull/249 -- Didi

6 16

ovirt-engine-4.5.2.2 has been tagged
by Martin Perina 10 Aug '22

10 Aug '22

ovirt-engine-4.5.2.2 has been tagged -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.

1 0

Starting with oVirt
by Teemu Saarinen 03 Aug '22

03 Aug '22

Hi, Our company is planning of taking oVirt in into our environment. We would have a few questions for that if you could guide us. Hardware: What would be the minimum configuration for us using oVirt?. Idea would be to replace all our current Linux and Windows servers with oVirt. There are currently 24 servers in use. The goal would also be that the virtual servers could be migrated live and also in the HA configuration, i.e. if one hardware crashes execution continues on the other. As far as I understand Ovirt enables this? So we would like to know what kind of hardware (minimum) we should have for this size of environment? Storagin: Do all machines need a lot of hard disk space or is it enough to have only one or two? I'm referring to shared storage. Can you also have storagin as HA? Host: What happens to HOST1 and HOST2 virtual machines if the oVirt host server crashes? Do they continue to operate without it, or do they crash at the same time? Thank You! Teemu S.

1 0

ovirt-engine-4.5.2.1 has been tagged
by Martin Perina 03 Aug '22

03 Aug '22

ovirt-engine-4.5.2.1 has been tagged -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.

1 0

Obsoleting Packages in 'dnf check-update' on RHEL 8.6 hosts
by Scott Worthington 01 Aug '22

01 Aug '22

Hello, My 4.5.1.3-1.el8 oVirt homelab cluster is running on RHEL 8.6 hosts and a RHEL 8.6 stand-alone engine. During the installation, I followed the instructions for RHEL 8.6: https://ovirt.org/download/install_on_rhel.html After the installation is complete, all packages are up-to-date, and everything is running, I run a 'dnf check-upgrade' and I find there are two packages that are listed under "Obsoleting Packages": """ Last metadata expiration check: 0:43:06 ago on Mon 01 Aug 2022 08:08:50 AM EDT. Obsoleting Packages centos-stream-release.noarch 8.6-1.el8 @@System centos-stream-release.noarch 8.6-1.el8 @@System centos-stream-release.noarch 8.6-1.el8 @@System redhat-release.x86_64 8.6-0.1.el8 @rhel-8-for-x86_64-baseos-rpms """ For the hosts, it makes it appear that the hosts always have an upgrade pending in the oVirt Engine UI. "centos-strea-release.noarch" appears to contain similar files to the original RHEL 8.6 package "redhat-release-8.6.0.1.el8" except for the addition of "centos*" named files. Any thoughts on how to change this behavior so that it doesn't appear to have packages to upgrade because a 'dnf update' does nothing to these "Obsoleting Packages"? Thanks in advance.

1 0