Important changes to the oVirt Terraform Provider
by Janos Bonic
Dear oVirt community,
We are making sweeping and backwards-incompatible changes to the oVirt
Terraform provider. *We want your feedback before we make these changes.*
Here’s the short list what we would like to change, please read the details
below.
1. The current master branch will be renamed to legacy. The usage of
this provider will be phased out within Red Hat around the end / beginning
of next year. If you want to create a fork, we are happy to add a link to
your fork to the readme.
2. A new main branch will be created and a *new Terraform provider*
written from scratch on the basis of go-ovirt-client
<https://github.com/ovirt/go-ovirt-client>. (Preview here
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt>) This
provider will only have limited functionality in its first release.
3. This new provider will be released to the Terraform registry, and
will have full test coverage and documentation. This provider will be
released as version v2.0.0 when ready to signal that it is built on the
Terraform SDK v2.
4. A copy of this new Terraform provider will be kept in the v1 branch
and backported to the Terraform SDK v1 for the benefit of the OpenShift
Installer <https://github.com/openshift/installer>. We will not tag any
releases, and we will not release this backported version in binary form.
5. We are hosting a *community call* on the 14th of October at 13:00 UTC
on this link <https://bluejeans.com/476587312/8047>. Please join to
provide feedback and suggest changes to this plan.
Why are we doing this?
The original Terraform provider
<https://github.com/EMSL-MSC/terraform-provider-ovirt> for oVirt was
written four years ago by @Maigard <https://github.com/Maigard> at EMSL-MSC
<http://github.com/EMSL-MSC/terraform-provider-ovirt>. The oVirt fork of
this provider is about 2 years old and went through rapid expansion, adding
a large number of features.
Unfortunately, this continuous rapid growth came at a price: the original
test infrastructure deteriorated and certain resources, especially the
virtual machine creation ballooned to a size we feel has become
unmaintainable.
If you tried to contribute to the Terraform provider recently, you may have
noticed that our review process has become extremely slow. We can no longer
run the original tests, and our end to end test suite is not integrated
outside of the OpenShift CI system. Every change to the provider requires
one of only 3 people to review the code and also run a manual test suite
that is currently only runable on one computer.
We also noticed an increasing number of bugs reported on OpenShift on
oVirt/RHV related to the Terraform provider.
Our original plan was that we would fix the test infrastructure and then
subsequently slowly transition API calls to go-ovirt-client, but that
resulted in a PR that is over 5000 lines in code
<https://github.com/oVirt/terraform-provider-ovirt/pull/277> and cannot in
good conscience be merged in a single piece. Splitting it up is difficult,
and would likely result in broken functionality where test coverage is not
present.
What are we changing for you, the users?
First of all, documentation. You can already preview the documentation here
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/docs>.
You will notice that the provider currently only supports a small set of
features. You can find the full list of features
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/milestone/1>
we are planning for the first release on GitHub. However, if you are using
resources like cluster creation, etc. these will currently not work and we
recommend sticking to the old provider for the time being.
The second big change will be how resources are treated. Instead of
creating large resources that need to call several of the oVirt APIs to
create, we will create resources that are only calling one API. This will
lead to fewer bugs. For example:
- ovirt_vm will create the VM, but not attach any disks or network
interfaces to it.
- ovirt_disk_attachment or ovirt_disk_attachments will attach a disk to
the VM.
- ovirt_nic will create a network interface.
- ovirt_vm_start will start the virtual machine when provisioned, stop
it when deprovisioned.
You can use the depends_on
<https://www.terraform.io/docs/language/meta-arguments/depends_on.html>
meta-argument to make sure disks and network interfaces are attached before
you start the VM. Alternatively, you can hot-plug network interfaces later.
For example:
resource "ovirt_vm" "test" {
cluster_id = "some-cluster-id"
template_id = "some-template-id"
}
resource "ovirt_disk" "test" {
storagedomain_id = "some-storage-domain-id"
format = "cow"
size = 512
alias = "test"
sparse = true
}
resource "ovirt_disk_attachment" "test" {
vm_id = ovirt_vm.test.id
disk_id = ovirt_disk.test.id
disk_interface = "virtio_scsi"
}
resource "ovirt_vm_start" "test" {
vm_id = ovirt_vm.test.id
depends_on = [ovirt_disk_attachment.test]
}
The next change is the availability of the provider on the Terraform
Registry. You will no longer have to download the binary. Instead, you will
be able to simply pull in the provider like this:
terraform {
required_providers {
ovirt = {
source = "ovirt/ovirt"
version = "..."
}
}
}
provider "ovirt" {
# Configuration options
}
The configuration options for the provider itself have also been greatly
expanded, see the preliminary documentation
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/docs>
for details.
What’s changing behind the scenes?
The new Terraform provider is a complete rewrite based on the
go-ovirt-client <https://github.com/ovirt/go-ovirt-client> library. The
single biggest advantage of this library is that it has built-in mocks for
all resources it supports. Having mocks allows us to run tests without
needing to spin up an oVirt instance. We have already configured GitHub
Actions
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/actions> on
the new provider and all changes are automatically checked against these
mocks.
We may decide to add an end-to-end test later, but for the foreseeable
future we will trust the correctness of the mocks to test community
contributions. This means that we will be able to merge changes much
quicker.
On the OpenShift side we will also switch to using the new provider, since
this is the primary motivation for the change. The OpenShift Installer uses
the legacy version 1 of the Terraform SDK, so we will maintain a version
1-compatible copy in the v1 branch, which the installer can pull in. It is
important to note, however, that the v1 branch will be a pure backport, we
will not develop it separately. Development will be focused on the version
in main that is being released to the Terraform Registry.
What does this mean to you, the contributors?
The current Terraform provider has several pull requests open
<https://github.com/oVirt/terraform-provider-ovirt/pulls>. Unfortunately,
we currently do not have the capacity to properly vet and and run our
internal test suite against these changes. In contrast to the new Terraform
provider, we do not have working tests, linting, and the code structure
that make merging changes easier.
We are very sorry to say that *these patches are unlikely to be merged*. We
know that this is a terrible thing, you have put in effort into writing
them. Unfortunately, we do not see an alternative as there already numerous
bugs on our radar and adding more code would not make the problem go away.
We want to hear your opinion
As the owners of the original Terraform provider we haven’t been keeping up
with reviewing your contributions and issues. Some are several months old
and haven’t received answers for a long time. We want to change that, we
want to hear from you. Please join our community round table around the
Terraform provider on the 14th of October at 13:00 UTC on this link
<https://bluejeans.com/476587312/8047>.
*We want to know: Which resources are the most important to you? How does
this change impact you? Can we make the transition smoother for you? Would
you do anything differently in the light of the issues described above?*
3 years, 1 month
NFS Synology NAS (DSM 7)
by Maton, Brett
Hi List,
I can't get oVirt 4.4.8.5-1.el8 (running on oVirt Node hosts) to connect
to an NFS share on a Synology NAS.
I gave up trying to get the hosted engine deployed and put that on an
iscsi volume instead...
The directory being exported from NAS is owned by vdsm / kvm (36:36)
perms I've tried:
0750
0755
0777
Tried auto / v3 / v4_0
As others have mentioned regarding NFS, if I connect manually from the
host with
mount nas.mydomain.com:/volume1/ov_nas
It connects and works just fine.
If I try to add the share as a domain in oVirt I get
Operation Cancelled
Error while executing action Add Storage Connection: Permission settings on
the specified path do not allow access to the storage.
Verify permission settings on the specified storage path.
When tailing /var/log/messages on
When tailing /var/log/messages on the oVirt host, I see this message appear
(I changed the domain name for this post so the dots might be transcoded in
reality):
Aug 27 17:36:07 ov001 systemd[1]:
rhev-data\x2dcenter-mnt-nas.mydomain.com:_volume1_ov__nas.mount:
Succeeded.
The NAS is running the 'new' DSM 7, /etc/exports looks like this:
/volume1/ov_nas x.x.x.x(rw,async,no_root_squash,anonuid=36,anongid=36)
(reloaded with exportfs -ra)
Any suggestions appreciated.
Regards,
Brett
3 years, 1 month
VM hanging at sustained high throughput
by David Johnson
Hi ovirt gurus,
This is an interesting issue, one I never expected to have.
When I push high volumes of writes to my NAS, I will cause VM's to go into
a paused state. I'm looking at this from a number of angles, including
upgrades on the NAS appliance.
I can reproduce this problem at will running a centos 7.9 VM on Ovirt 4.5.
*Questions:*
1. Is my analysis of the failure (below) reasonable/correct?
2. What am I looking for to validate this?
3. Is there a configuration that I can set to make it a little more robust
while I acquire the hardware to improve the NAS?
*Reproduction:*
Standard test of file write speed:
[root@cen-79-pgsql-01 ~]# dd if=/dev/zero of=./test bs=512k count=4096
oflag=direct
4096+0 records in
4096+0 records out
2147483648 bytes (2.1 GB) copied, 1.68431 s, 1.3 GB/s
Give it more data
[root@cen-79-pgsql-01 ~]# dd if=/dev/zero of=./test bs=512k count=12228
oflag=direct
12228+0 records in
12228+0 records out
6410993664 bytes (6.4 GB) copied, 7.22078 s, 888 MB/s
The odds are about 50/50 that 6 GB will kill the VM, but 100% when I hit 8
GB.
*Analysis:*
What I think appears to be happening is that the intent cache on the NAS is
on an SSD, and my VM's are pushing data about three times as fast as the
SSD can handle. When the SSD gets queued up beyond a certain point, the NAS
(which places reliability over speed) says "Whoah Nellie!", and the VM
chokes.
*David Johnson*
3 years, 1 month
ovirt-4.4 morrors failing
by Ayansh Rocks
Hi All,
Maximum mirrors are failing of ovirt-4.4 dependencies....what can be done
here ?
Error: Failed to download metadata for repo 'ovirt-4.4-centos-gluster8':
Cannot prepare internal mirrorlist: No URLs in mirrorlist
Errors during downloading metadata for repository
'ovirt-4.4-openstack-victoria':
- Status code: 404 for
http://mirror.centos.org/centos/8/cloud/x86_64/openstack-victoria/repodat...
(IP: 54.169.224.98)
Error: Failed to download metadata for repo 'ovirt-4.4-openstack-victoria':
Cannot download repomd.xml: Cannot download repodata/repomd.xml: All
mirrors were tried
Errors during downloading metadata for repository
'ovirt-4.4-centos-nfv-openvswitch':
- Status code: 404 for
http://mirror.centos.org/centos/8/nfv/x86_64/openvswitch-2/repodata/repom...
(IP: 13.231.175.254)
Error: Failed to download metadata for repo
'ovirt-4.4-centos-nfv-openvswitch': Cannot download repomd.xml: Cannot
download repodata/repomd.xml: All mirrors were tried
[root@iondelsvr12 yum.repos.d]# dnf install ovirt-hosted-engine-setup -y
Ceph packages for x86_64
0.0 B/s | 0 B 00:00
Errors during downloading metadata for repository
'ovirt-4.4-centos-ceph-pacific':
- Curl error (7): Couldn't connect to server for
http://mirror.centos.org/centos/8/storage/x86_64/ceph-pacific/repodata/re...
[Failed to connect to mirror.centos.org port 80: Connection refused]
Error: Failed to download metadata for repo
'ovirt-4.4-centos-ceph-pacific': Cannot download repomd.xml: Cannot
download repodata/repomd.xml: All mirrors were tried
3 years, 1 month
Unable to migrate VMs to a newly upgraded Ovirt node host
by Giulio Casella
Hi guys,
I just faced a problem after updating a host. I cannot migrate VM to
updated host.
Here's the error I see trying to migrate a VM to that host.
Dec 16 10:13:11 host01.ovn.di.unimi.it systemd[1]: Starting Network
Manager Script Dispatcher Service...
Dec 16 10:13:11 host01.ovn.di.unimi.it libvirtd[5667]: Unable to read
from monitor: Connection reset by peer
Dec 16 10:13:11 host01.ovn.di.unimi.it libvirtd[5667]: internal error:
qemu unexpectedly closed the monitor: 2021-12-16T10:13:00.447480Z
qemu-kvm: -numa node,nodeid=0,cpus=0-15,mem=8192: warning: Parameter
-numa node,mem is deprecated, use -numa node,memdev instead
2021-12-16T10:13:11.158057Z qemu-kvm: Failed to load pckbd:kbd
2021-12-16T10:13:11.158114Z qemu-kvm: error while loading state for
instance 0x0 of device 'pckbd'
2021-12-16T10:13:11.158744Z qemu-kvm: load of migration failed: No such
file or directory
Dec 16 10:13:11 host01.ovn.xx.xxxxx.it kvm[35663]: 0 guests now active
Instead I can start VM on that host, and migrate away VM from that host.
Rolling back to ovirt-node-ng-4.4.9.1-0.20211207.0+1 via host console
restores full functionality.
The affected version is ovirt-node-ng-4.4.9.3-0.20211215.0+1 (and also
previous one, I don't remember precisely, it was another async release).
Any ideas?
TIA,
gc
3 years, 1 month
Install hosted engine using fcoe
by kyles＠aasteel.com
We're building a new cluster, but it utilizes fcoe for our storage. Is there a way to install the hosted engine using fcoe? I am unable to see our LUNs in the ovirt node currently as fcoe isn't enabled.
3 years, 1 month
Deploy ovirt-csi in the kubernetes cluster
by ssarang520＠gmail.com
Hi,
I want to deploy ovirt-csi in the kubernetes cluster. But the guide only has how to deploy to openshift.
How can I deploy the ovirt-csi in the kubernetes cluster? Is there any way to do that?
3 years, 2 months
how to search event not matching a user
by Gianluca Cecchi
Hello,
every event in Advanced view has a field "User".
I'm trying to compose a search in web admin of events with user different
from myuser@internal
It seems I'm not able to get what I want.
I also tried to base attempts on an old 2019 thread (on 4.3.6) where this
queries worked:
Disks: name=engine* or name=host*
Disks: alias=engine* or alias=host*
but now on 4.4.8 gives nothing even if matched.
Any hint and also documentation reference about the correct syntax to use
in 4.4.x?
Thanks,
Gianluca
3 years, 2 months
What happened to oVirt engine-setup?
by Richard W.M. Jones
A while back I had oVirt 4.4.7 installed which I used for testing.
For some reason that installation has died in some way, so I'm trying
to install a fresh new oVirt 4.4.10.
Last time I installed ovirt, it was very easy - I provisioned a couple
of machines, ran engine-setup in one, answered a few questions and
after a few minutes the engine was installed.
Somehow this has changed and now it's really far more complicated,
involving some ansible things and wanting to create VMs and ssh
everywhere.
Can I go back to the old/easy way of installing oVirt engine? And if
so, what happened to the instructions for that?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
3 years, 2 months
Host needs to be reinstalled after configuring power management
by Andrew DeMaria
Hi,
I am running ovirt 4.3 and have found the following action item immediately
after configuring power management for a host:
Host needs to be reinstalled as important configuration changes were
applied on it.
The thing is - I've just freshly installed this host and it seems strange
that I need to reinstall it.
Is there a better way to install a host and configure power management
without having to reinstall it after?
Thanks,
Andrew
3 years, 2 months
