VM Snapshot inconsistent
by Arsène Gschwind
Hi,
I running oVirt 4.3.9 with FC based storage.
I'm running several VM with 3 disks on 3 different SD. Lately we did delete a VM Snapshot and that task failed after a while and since then the Snapshot is inconsistent.
disk1 : Snapshot still visible in DB and on Storage using LVM commands
disk2: Snapshot still visible in DB but not on storage anymore (It seems the merge did run correctly)
disk3: Snapshot still visible in DB but not on storage ansmore (It seems the merge did run correctly)
When I try to delete the snapshot again it runs forever and nothing happens.
Is there a way to suppress that snapshot?
Is it possible to merge disk1 with its snapshot using LVM commands and then cleanup the Engine DB?
Thanks for any hint or help.
rgds , arsene
--
Arsène Gschwind <arsene.gschwind(a)unibas.ch<mailto:arsene.gschwind@unibas.ch>>
Universitaet Basel
3 years, 9 months
Re: Management Engine IP change
by Alex K
On Tue, Jul 28, 2020 at 11:51 AM Anton Louw via Users <users(a)ovirt.org>
wrote:
>
>
> Hi All,
>
>
>
> Does somebody perhaps know the process of changing the Hosted Engine IP
> address? I see that it is possible, I am just not sure if it is a straight
> forward process using ‘nmtui’ or editing the network config file. I have
> also ensured that everything was configured using the FQDN.
>
Since the FQDN is not changing you should not have issues just updating
your DNS then changing manually the engine IP from the ifcfg-ethx files
then restart networking.
What i find difficult and perhaps impossible is to change engine FQDN, as
one will need to regenerate all certs from scratch (otherwise you will have
issues with several services: imageio proxy, OVN, etc) and there is no such
procedure documented/or supported.
I might be able to soon test this engine IP change in a virtual environment
and let you know.
>
>
> Thanks
>
> *Anton Louw*
> *Cloud Engineer: Storage and Virtualization* at *Vox*
> ------------------------------
> *T:* 087 805 0000 | *D:* 087 805 1572
> *M:* N/A
> *E:* anton.louw(a)voxtelecom.co.za
> *A:* Rutherford Estate, 1 Scott Street, Waverley, Johannesburg
> www.vox.co.za
>
> [image: F] <https://www.facebook.com/voxtelecomZA>
> [image: T] <https://www.twitter.com/voxtelecom>
> [image: I] <https://www.instagram.com/voxtelecomza/>
> [image: L] <https://www.linkedin.com/company/voxtelecom>
> [image: Y] <https://www.youtube.com/user/VoxTelecom>
>
> [image: #VoxBrand]
> <https://www.vox.co.za/fibre/fibre-to-the-home/?prod=HOME>
> *Disclaimer*
>
> The contents of this email are confidential to the sender and the intended
> recipient. Unless the contents are clearly and entirely of a personal
> nature, they are subject to copyright in favour of the holding company of
> the Vox group of companies. Any recipient who receives this email in error
> should immediately report the error to the sender and permanently delete
> this email from all storage devices.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived by *Mimecast Ltd*, an innovator in Software as a
> Service (SaaS) for business. Providing a *safer* and *more useful* place
> for your human generated data. Specializing in; Security, archiving and
> compliance. To find out more Click Here
> <https://www.voxtelecom.co.za/security/mimecast/?prod=Enterprise>.
>
>
> _______________________________________________
> Users mailing list -- users(a)ovirt.org
> To unsubscribe send an email to users-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/users@ovirt.org/message/EZPTYSINJMO...
>
3 years, 9 months
oVirt Node - Add Host Error
by Lovepreet Deol
Hi,
Greetings for the day.
I am trying to learn ovirt on vmware workstation and setting up a
virtualization datacenter in it. My topology is as follows :
[image: oVirt Topology NEW.PNG]
Ovirt engine - release 44
ovirt node - 4.4.1.1
I am getting the following error when trying to add the ovirt node to ovirt
engine.
[image: error 2.PNG]
Please help.
Regards
*Lovepreet Deol*
3 years, 9 months
Upgrade procedure for oVirt
by Alex K
Hi all!
I am going though an upgrade from ovirt 4.2 (4.2.8.2-1.el7) to 4.3 for a
two node cluster with self hosted engine. I have done previously upgrades
from 4.1 to 4.2 successfully with minor issues which where fixed.
I wanted to confirm with you, in case I am missing anything that may have
changed in the mean time, on the steps for minor and major upgrade:
*# Ovirt procedure for minor upgrade: (4.x.y -> 4.x.z)*
• enable global maintenance mode
• at engine: engine-upgrade-check
• at engine: yum update "ovirt-*-setup*"
• at engine: engine-setup
• at engine: yum update
• at each host from GUI: host -> installation -> upgrade
• at each host: yum update, reboot, activate
*# Ovirt procedure for major upgrade (4.x -> 4.y)*
• update DC to latest minor version (engine + nodes)
• enable global maintenance
• at engine: install major version repo: yum install
https://resources.ovirt.org/pub/yum-repo/ovirt-release4x.rpm
• at engine: engine-upgrade-check
• at engine: yum update "ovirt-*-setup*"
• at engine: engine-setup
• at engine: remove the old ovirt release from /etc/yum.repos.d
• at engine: yum update
• after completion of engine upgrade disable global maintenance
• verify engine version
• update each host/node: update to minor, then install new repo, remove old
repo, yum update, reboot, activate
• after completion of updates: set DC and cluster compatibility level to
latest version 4.x.
• shutdown guest VMs and confirm they start up again. (you may need to
disable guest disk leases or re-activate guest disks)
• check events for any issues and fix accordingly
Am I missing anything? I am planning the upgrade hoping to have no issues
since the cluster is hosting production VMs.
Thanx for any feedback!
Alex
3 years, 9 months
Ovirt hypervisor as an DRBD node
by radchenko.anatoliy＠gmail.com
Hi community,
I would like to use 3 nodes for hypervisor (hosted engine or install a separate VM with engine for its subsequent management) to use them as storage nodes - drbd 9 dual primary + quorum node (aka backup), ocfs 2 - so that the VMs used the hardware of both nodes (so to speak, hyperconverged with drbd). Can you tell me if there are any limits on the part of ovirt for this configuration and the best way to mount ocfs2 - iscsi via scst, posixFS or cinder?
Thanks in advance
Best regards
3 years, 9 months
Re: Management Engine IP change
by thomas＠hoberg.net
I honestly don't know, because I have not tried myself, so you might just want to stop reading right here.
But from what I understand about the design philosophy of oVirt, it should be ok to change it, while nobody probably ever tested it and everybody would tell you it's a bad idea to do so, unless you're willing to rebuild from scratch.
The reason it *should* be ok is that the nodes don't care about the management engine.
They care only about the information on the shared cluster storage.
How that gets there, who changes it: They couldn't care less.
Yet, I believe I have seen events being reported back to the management engine via REST API calls, referring to the management engine via URIs that should have been using FQDN only. So there is some biliateral communication going on, mostly asynchronous as far as I can see and not using IPs.
What I can tell you, is that /etc/sysconfig/network-scripts/ifcfg-eth0 has NM_CONTROLLED=no inside, so nmtui won't go near it. You can change that, delete the line, edit the config... and hopefully it will live.
And in case things go seriously wrong, you should be able to fix it with hosted-engine --console
But, again, I never tried it myself.
But I use DHCP on two out of four farms...
3 years, 9 months
Migrate VMs from oVirt (3.5) to oVirt (4.4)
by Ian Easter
Hey folks,
What is the proper course of action to migrate VMs managed by and older
oVirt instance into a new oVirt instance?
Assuming this was the best case to upgrade due to the age of the older
instance.
*Thank you,*
*Ian*
3 years, 9 months
oVirt thrashes Docker network during installation
by thomas＠hoberg.net
I want to run containers and VMs side by side and not necessarily nested. The main reason for that is GPUs, Voltas mostly, used for CUDA machine learning not for VDI, which is what most of the VM orchestrators like oVirt or vSphere seem to focus on. And CUDA drivers are notorious for refusing to work under KVM unless you pay $esla.
oVirt is more of a side show in my environment, used to run some smaller functional VMs alongside bigger containers, but also in order to consolidate and re-distribute the local compute node storage as a Gluster storage pool: Kibbutz storage and compute, if you want, very much how I understand the HCI philosophy behind oVirt.
The full integration of containers and VMs is still very much on the roadmap I believe, but I was surprised to see that even co-existence seems to be a problem currently.
So I set-up a 3-node HCI on CentOS7 (GPU-less and older) hosts and then added additional (beefier GPGPU) CentOS7 hosts, that have been running CUDA workloads on the latest Docker-CE v19 something.
The installation works fine, I can migrate VMs to these extra hosts etc., but to my dismay Docker containers on these hosts lose access to the local network, that is the entire subnet the host is in. For some strange reason I can still ping Internet hosts, perhaps even everything behind the host's gateway, but local connections are blocked.
It would seem that the ovritmgmt network that the oVirt installation puts in breaks the docker0 bridge that Docker put there first.
I'd consider that a bug, but I'd like to gather some feedback first, if anyone else has run into this problem.
I've repeated this several times in completely distinct environments with the same results:
Simply add a host with a working Docker-CE as an oVirt host to an existing DC/cluster and then try if you can still ping anyone on that net, including the Docker host from a busybox container afterwards (should try that ping just before you actually add it).
No, I didn't try this with podman yet, because that's separate challenge with CUDA: Would love to know if that is part of QA for oVirt already.
3 years, 9 months
Hosted Engine Deployement
by Vijay Sachdeva
Hi All,
It tried deploying hosted engine using cli and got this error every time:
Can anyone please let me know what here is missing..!! As it would be a great help.patri
Thanks
Vijay Sachdeva
3 years, 9 months
Non storage nodes erronously included in quota calculations for HCI?
by thomas＠hoberg.net
For my home-lab I operate a 3 node HCI cluster on 100% passive Atoms, mostly to run light infrastructure services such as LDAP and NextCloud.
I then add workstations or even laptops as pure compute hosts to the cluster for bigger but temporary things, that might actually run a different OS most of the time or just be shut off. From oVirt's point of view, these are just first put into maintenance and then shut down until needed again. No fencing or power management, all manual.
All nodes, even the HCI ones, run CentOS7 with more of a workstation configuration, so updates pile up pretty quickly.
After I recently upgraded one of these extra compute nodes, I found my three node HCI cluster not just faltering, but indeed very hard to reactivate at all.
The faltering is a distinct issue: I have the impression that reboots of oVirt nodes cause broadcast storms on my rather simplistic 10Gibt L2 switch, which a normal CentOS instance (or any other OS) doesn't, but that's for another post.
No what struck me, was that the gluster daemons on the three HCI nodes kept complaining about a lack of quorum long after the network was all back to normal, even if all three of them were there, saw each other perfectly on "gluster show status all", ready and without any healing issues pending at all.
Glusterd would complain on all three nodes that there was no quota for the bricks and stop them.
That went away as soon as I started one additional compute node, a node that was a gluster peer (because an oVirt host added to a HCI cluster always gets put into the Gluster, even if it's not contributing storage) but had no bricks. Immediately the gluster daemon on the three nodes with contributing bricks would report back good quota and launch the volumes (and thus all the rest of oVirt), even if in terms of *storage bricks* nothing had changed.
I am afraid that downing the extra compute-only oVirtNode will bring down the HCI: Clearly not the type of redundancy it's designed to deliver.
Evidently such compute-only hosts (and gluster members) get included into some quorum deliberations even if they hold not a single brick, neither storage nor arbitration.
To me that seems like a bug, if that is indeed what happens: There I need your advice and suggestions.
AFAIK HCI is a late addition to oVirt/RHEV as storage and compute were orginally designed to be completely distinct. In fact there are still remnants of documentation which seem to prohibit using a node for both compute and storage... what HCI is all about.
And I have seen compute nodes with "matching" storage (parts of a distinct HCI setup, that was taken down but still had all the storage and Gluster elements operable), being happliy absorbed into a HCI cluster with all Gluster storage appearing in the GUI etc., without any manual creation or inclusion of bricks: Fully automatic (and undocumented)!
In that case it makes sense to widen the scope of quota calculations when additional nodes are hyperconverged elements with contributing bricks. It also seems the only way to turn a 3 node HCI into 6 or 9 node one.
But if you really just want to add compute nodes without bricks, those can't get "quota votes" without storage to play a role in the redundancy.
I can easily imagine the missing "if then else" in the code here, but I was actually very surprised to see those failure and success messages coming from glusterd itself, which to my understanding is pretty unrelated to oVirt on top. Not from the management engine (wasn't running anyway), not from VDSM.
Re-creating the scenario is very scary even if I have gone through this three times already, trying to just bring my HCI back up. And then there is so verbose logs all over the place that I'd like some advice which ones I should post.
But simply speaking: Gluster peers should get no quota voting rights on volumes unless they contribute bricks. That rule seems broken.
Those in the know, please let me know if am on a goose chase or if there is a real issue here that deserves a bug report.
3 years, 9 months
