- Users - oVirt List Archives

Standard operating procedure for a node failure on HCI required
by Thomas Hoberg 04 Apr '21

04 Apr '21

oVirt may have started as a vSphere 'look-alike', but it graduated to a Nutanix 'clone', at least in terms of marketing. IMHO that means the 3-node hyperconverged default oVirt setup (2 replicas and 1 arbiter) deserves special love in terms of documenting failure scenarios. 3-node HCI is supposed to defend you against long-term effects of any single point of failure. There is no protection against the loss of dynamic state/session data, but state-free services should recover or resume: that's what it's all about. Sadly, what I find missing in the oVirt and Gluster documentation is an SOP (standard operating procedure) that one should follow in case of a late-night/early-morning on-call wakeup when one of those three HCI nodes should have failed... dramatically or via a 'brown out' e.g. where only the storage part was actually lost. My impression is that the oVirt and Gluster teams are barely talking, but in HCI that's fatal. And I sure can't find those recovery procedures, not even in the commercial RH documents. So please, either add them or show me where I missed them.

2 2

oVirt cannot start VM after reboot with cluster chipset set to i440fx
by Joris Dobbelsteen 03 Apr '21

03 Apr '21

Hi I’m running a oVirt 4.4.4 installation (with a single node and single cluster). After a recent reboot, I’m trying to start the VMs, which fails with: VM udc1 is down with error. Exit message: XML error: The device at PCI address 0000:00:02.0 cannot be plugged into the PCI controller with index='0'. It requires a controller that accepts a pcie-root-port.. Dmesg shows: Mar 15 17:07:48 ovirt1 journal[2245]: internal error: a PCI slot is needed to connect a PCI controller model='pcie-root-port', but none is available, and it cannot be automatically added The issue seems with the “custom chipset/firmware” set to i440fx rather than Q35 for the cluster. The VM is configured to cluster default. The rationale for running i440 is that Debian doesn’t actually support Q35 with cloud-init, leading to an uninitialized VM. Since I’m running mainly Debian/Ubuntu VMs it’s needed to have i440 set instead. The error is also visible in oVirt Manager, when checking out the “Vm Devices” for the failed VM (all of them). The workaround for starting the VM seems to be to do: Edit -> System -> Advanced Parameters -> Custom Chipset/Firmware Type -> Change to Q35 and back to cluster default (being i440). This resets the list to remove the need for a pcie-root-port. I gives the impressions that there is an initialization error of the ovirt engine, where the Q35 devices are loaded in incorrectly or maybe not fetched as the right cluster default. I’ve not tested what happens if the configured for i440fx is applied at VM level, rather than cluster level. Does anyone know how to resolve this for future versions? Or what can be done to make this work after a reboot? Best regards, Joris

1 0

VMConsole: Certificate invalid: name is not a listed principal
by Stefan Seifried 02 Apr '21

02 Apr '21

Hi, I recently tried out the vm console feature on an ovirt eval environment running 4.4.4.7-1.el8: 1.) pasted the pub-key of my local user into the web interface (User->Options) 2.) connected via ssh like so ssh -p 2222 sevm -l ovirt-vmconsole 3.) got the list of all the vm's :) 4.) choose a vm with a virtio serial console enabled 5.) Certificate invalid :( --- Please, enter the id of the Serial Console you want to connect to. To disconnect from a Serial Console, enter the sequence: <Enter><~><.> SELECT> 24 Certificate invalid: name is not a listed principal Host key verification failed. Connection to sevm closed. --- I guess somethings wrong in "/etc/pki/ovirt-vmconsole". Is there any additional information I can get out from the logs or the console proxy (e.g. the "name" which is not a listed principal)? To be honest I never really worked with SSH certificates, so I fear I will do something stupid if I try to fix this head on. So any advice or help on this issue is appreciated. Thanks, Stefan

1 0

Re: Power failure makes cluster and hosted engine unusable
by Thomas Hoberg 01 Apr '21

01 Apr '21

I am glad you got it done! I find that oVirt resembles more an adventure game (with all its huge emotional rewards, once you prevail), than a streamlined machine, that just works every time you push a button. Those are boring, sure, but really what I am looking for when the mission is to run infrastructure.

1 0

Re: Power failure makes cluster and hosted engine unusable
by Roman Bednar 01 Apr '21

01 Apr '21

Hi Seann, On Mon, Mar 29, 2021 at 8:31 PM Seann G. Clark via Users <users(a)ovirt.org> wrote: > All, > > > > After a power failure, and generator failure I lost my cluster, and the > Hosted engine refused to restart after power was restored. I would expect, > once storage comes up that the hosted engine comes back online without too > much of a fight. In practice because the SPM went down as well, there is no > (clearly documented) way to clear any of the stale locks, and no way to > recover both the hosted engine and the cluster. > Could you provide more details/logs on storage not coming up? Also more information about the current locks would be great, is there any procedure you tried that did not work for cleaning those up? I have spent the last 12 hours trying to get a functional hosted-engine > back online, on a new node and each attempt hits a new error, from the > installer not understanding that 16384mb of dedicated VM memory out of > 192GB free on the host is indeed bigger than 4096MB, to ansible dying on > an error like this “Error while executing action: Cannot add Storage > Connection. Storage connection already exists.” > > The memory error referenced above shows up as: > > [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": > "Available memory ( {'failed': False, 'changed': False, 'ansible_facts': > {u'max_mem': u'180746'}}MB ) is less then the minimal requirement (4096MB). > Be aware that 512MB is reserved for the host and cannot be allocated to the > engine VM."} > > That is what I typically get when I try the steps outlined in the KB > “CHAPTER 7. RECOVERING A SELF-HOSTED ENGINE FROM AN EXISTING BACKUP” from > the RH Customer portal. I have tried this numerous ways, and the cluster > still remains in a bad state, with the hosted engine being 100% inoperable. > This could be a bug in the ansible role, did that happen during "hosted-engine --deploy" or other part of the recovery guide? Provide logs here as well please, its seems like a completely separate issue though. > > What I do have are the two host that are part of the cluster and can host > the engine, and backups of the original hosted engine, both disk and > engine-backup generated. I am not sure what I can do next, to recover this > cluster, any suggestions would be apricated. > > > > Regards, > > Seann > > > > > _______________________________________________ > 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/JLDIFTKYDPQ6Y… >

3 3

[ANN] oVirt 4.4.6 Second Release Candidate is now available for testing
by Lev Veyde 01 Apr '21

01 Apr '21

oVirt 4.4.6 Second Release Candidate is now available for testing The oVirt Project is pleased to announce the availability of oVirt 4.4.6 Second Release Candidate for testing, as of April 1st, 2021. This update is the sixth 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.6 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.6 (redeploy in case of already being on 4.4.6). 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 - We found a few issues while testing on CentOS Stream so we are still basing oVirt 4.4.6 Node and Appliance on CentOS Linux. Additional Resources: * Read more about the oVirt 4.4.6 release highlights: http://www.ovirt.org/release/4.4.6/ * 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.6/ [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

Locked disks
by Giulio Casella 01 Apr '21

01 Apr '21

Since yesterday I found a couple VMs with locked disk. I don't know the reason, I suspect some interaction made by our backup system (vprotect, snapshot based), despite it's working for more than a year. I'd give a chance to unlock_entity.sh script, but it reports: CAUTION, this operation may lead to data corruption and should be used with care. Please contact support prior to running this command Do you think I should trust? Is it safe? VMs are in production... My manager is 4.4.4.7-1.el8 (CentOS stream 8), hosts are oVirt Node 4.4.4 TIA, Giulio

3 7

Hyperconverged engine high availability?
by David White 31 Mar '21

31 Mar '21

I just finished deploying oVirt 4.4.5 onto a 3-node hyperconverged cluster running on Red Hat 8.3 OS. Over the course of the setup, I noticed that I had to setup the storage for the engine separately from the gluster bricks. It looks like the engine was installed onto /rhev/data-center/ on the first host, whereas the gluster bricks for all 3 hosts are on /gluster_bricks/. I fear that I may already know the answer to this, but: Is it possible to make the engine highly available? Also, thinking hypothetically here, what would happen to my VMs that are physically on the first server, if the first server crashed? The engine is what handles the high availability, correct? So what if a VM was running on the first host? There would be nothing to automatically "move" it to one of the remaining healthy hosts. Or am I misunderstanding something here? Sent with ProtonMail Secure Email.

4 6

Deployment issues
by Valerio Luccio 31 Mar '21

31 Mar '21

Hello all, last September I deployed Ovirt on a CentOS 8 server, with storage on our gluster (replica 3). I then added some VMs, etc. A few days ago I managed to screw everything up and, after bannging my head for a couple of days, decided to start from scratch. I made a copy of all the data under the storage to a safe space, the ran ovirt-hosted-engine-cleanup and deleted everything under the storage and tried to create a new hosted engine (I tried both from the cockpit and from command line). Everything seems to work fine (I can ssh to the engine) until it tries to save the engine to storage and it fails with the error: FAILED! => {"changed": false, "msg": "Fault reason is \"Operation Failed\". Fault detail is \"[Error creating a storage domain's metadata]\". HTTP response code is 400."} I don't get any more details. I'm using exactly the same parameters I used before. I have no problems reaching the gluster storage and the process does create the top-level directory and <top-level>/dom_md/ids with the correct ownership. I looked at the glusterfs log files, including the rhev-data-center-mnt-glusterSD-<host:_root>.log file, but I don't spot any specific error. What am I doing wrong ? Is there something else I need to clean up before trying a new deployment ? Should I just try to delete all of the ovirt configuration files ? Which ones ? Thanks, -- As a result of Coronavirus-related precautions, NYU and the Center for Brain Imaging operations will be managed remotely until further notice. All telephone calls and e-mail correspondence are being monitored remotely during our normal business hours of 9am-5pm, Monday through Friday. For MRI scanner-related emergency, please contact: Keith Sanzenbach at keith.sanzenbach(a)nyu.edu and/or Pablo Velasco at pablo.velasco(a)nyu.edu For computer/hardware/software emergency, please contact: Valerio Luccio at valerio.luccio(a)nyu.edu For TMS/EEG-related emergency, please contact: Chrysa Papadaniil at chrysa(a)nyu.edu For CBI-related administrative emergency, please contact: Jennifer Mangan at jennifer.mangan(a)nyu.edu Valerio Luccio (212) 998-8736 Center for Brain Imaging 4 Washington Place, Room 158 New York University New York, NY 10003 "In an open world, who needs windows or gates ?"

4 12

Re: Power failure makes cluster and hosted engine unusable
by Thomas Hoberg 31 Mar '21

31 Mar '21

Yup, that's a bug in the ansible code, I've come across on hosts that had 512GB of RAM. I quite simply deleted the checks from the ansible code and re-ran the wizard. I can't read YAML or Python or whatever it is that Ansible uses, but my impression is that things are 'cast' or converted into an INT data type on these checks that overflows at that point. I wound up commenting out the entire set of checks to get past this, because I could see no easy way to fix this. I just checked that the commands used to retrieve the memory size returned the proper number of kilobytes and then rolled my eyes at what seemd like a type cast operation. I never went deeper, because at that point I have a hard time keeping the beast inside me at bay, that sees how Ansible can bring a Xeon Scalable Gold system to what seems slower than a 6502 executing BASIC. The hosted-setup takes what seems like an hour, no matter how fast or slow your hardware. I was so fed up at the speed of Ansible and the quality of oVirt QA, I couldn't bring myself to open a ticket, I hope you're better motivated. BTW things aren't much better at the low end either. While Ansible doesn't seem that much slower on an Atom farm I also operate, the hosted-engine setup does fail on them, so replug their SSDs for that part into an i7 and then replug the SSDs to the Atoms aftwards. Once, up and running oVirt is just fine on Atoms (mine have 32GB of RAM each). I am almost ready to donate my Atoms to the project, because I keep thinking that oVirt's major chance would be as edge HCI, but they are asking for 128GB RAM minimum... BTW. I was running oVirt 4.3 on CentOS7 when hitting that error. No idea if it's still the same with 4.4/COS8 as my 'perhaps-next-but-more-likely-never' generation test farm runs on NUCs with 64GB.

1 0