Testing PXE uefi boot in oVirt
by Gianluca Cecchi
Hello,
I'm testing a configuration with a CentOS 8.3 VM as a PXE server for UEFI
boot.
Its chipset/fw type is "I440FX Chipset with BIOS", I don't think it is
important.
And I have another (tobe, configured in hw as rhel 8.0) CentOS 8 VM
configured now as "Q35 Chipset with UEFI" as a client.
I already removed filters from vnics of both
It seems that the client successfully downloads the BOOTX64.EFI but then
fails fetching the netboot image with the message:
Fetching Netboot Image
Unable to fetch TFTP image: TFTP Error
under tftp root dir I created grub.cfg this way
set timeout=60
menuentry 'CentOS 8.3' {
linuxefi images/c83/vmlinuz ip=dhcp inst.repo=http://172.20.0.1/c83/
initrdefi images/c83/initrd.img
}
and also a link to it with the mac address of the client in the form
grub.cfg-00:1a:4a:19:01:54 -> grub.cfg
documentation for uefi pxe server config is not quite clear on where to put
it and naming
Any good docs? Also the latest rh el 8.3 advanced installation guide is not
so clear...
See here for a screenshot:
https://drive.google.com/file/d/1YJwgmg-0vTcXYWHbgCf81m8SLsN7Rwjf/view?us...
For instance, is it expected that I can test this functionality at all
using oVirt VMs?
So the UEFI implementation for PXE boot?
At the moment I'm using virtio as the vnic type for both the server and the
client. Do I have to change them to something different (eg e1000)?
Thanks in advance for any input.
Gianluca
3 years, 10 months
[ANN] oVirt 4.4.5 Fifth Release Candidate is now available for testing
by Lev Veyde
oVirt 4.4.5 Fifth Release Candidate is now available for testing
The oVirt Project is pleased to announce the availability of oVirt 4.4.5
Fifth Release Candidate for testing, as of February 11th, 2021.
This update is the fifth 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.5 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.5 (redeploy in case of already being on 4.4.5).
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.5 Node and Appliance on CentOS Linux.
Additional Resources:
* Read more about the oVirt 4.4.5 release highlights:
http://www.ovirt.org/release/4.4.5/
* 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.5/
[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>
3 years, 10 months
OVN network and external access
by Gianluca Cecchi
Hello,
can I have external access from a VM with vnic configured on OVN network,
still maintaining switch type of cluster to Linux Bridge? Or am I forced to
use switch type OVS (that seems still in Tech Preview)?
Thanks,
Gianluca
3 years, 10 months
Re: Ovirt - affinity labels names and virtual machines
by Benny Zlotnik
Hi,
I suggest sending questions to ovirt-users so others could find
answers as well as to allow others who might know better chime in as
well
As to your question, something like this works for me:
vms_service = connection.system_service().vms_service()
vm_service = vms_service.vm_service('vm-id')
affinity_labels = vm_service.affinity_labels_service().list()
for affinity_label in affinity_labels:
hosts = connection.follow_link(affinity_label.hosts)
for host in hosts:
print(connection.follow_link(host).name)
(I am not sure where exactly the problem is in your code)
On Mon, Feb 15, 2021 at 2:32 PM Lavi Bochnik <lavi.bochnik(a)gmail.com> wrote:
>
> Hello Benny,
>
> Not sure if I can email you directly, but you helped me once.
> I have some VM's which are labeled with specific affinity.
> Via API I would like to get a VM affinity label, in order to later get the hosts defined under that affinity.
> I tried many ways as:
> vm = vms_service.list(search='<vm_name>')[0]
> print(vm.affinity_labels)
>
> or:
> for affinity_label in affinity_labels:
> print("%s:" % affinity_label.name)
> for vm_link in connection.follow_link(affinity_label.vms):
> vm = connection.follow_link(vm_link)
> print(" - %s" % vm.name)
>
> Getting an href error: Error: The URL '/ovirt-engine/api/affinitylabels/0d68b36e-455a-4054-9958-0503d54a18db/vms' isn't compatible with the base URL of the connection
>
> Href's are looking fine, as:
> In [77]: for x in affinity_labels_service.list():
> ...: print(x.href)
>
> /ovirt-engine/api/affinitylabels/0d68b36e-455a-4054-9958-0503d54a18db
> /ovirt-engine/api/affinitylabels/862df742-fdc4-4eb0-933c-027729e2187d
> /ovirt-engine/api/affinitylabels/686d96a6-0c9c-4fb7-b453-a79cbd48790b
> /ovirt-engine/api/affinitylabels/6d42df24-c4b1-45e7-8029-0ce26b8ed73d
>
> Or this:
>
> 1 for affinity_label in affinity_labels:
> ----> 2 for h in connection.follow_link(affinity_label.hosts):
> 3 print(h)
> 4
> 5
>
> /usr/local/lib64/python3.6/site-packages/ovirtsdk4/__init__.py in follow_link(self, obj)
> 782 raise Error(
> 783 "The URL '%s' isn't compatible with the base URL of the "
> --> 784 "connection" % href
> 785 )
> 786
>
> Error: The URL '/ovirt-engine/api/affinitylabels/0d68b36e-455a-4054-9958-0503d54a18db/hosts' isn't compatible with the base URL of the connection
>
> Not clear what is the right way to get a VM affinity hosts list.
>
> Thanks,
> Lavi
3 years, 10 months
Single Node Hyperconverged - Failing Engine Deployment - Network setup?
by jhamiltonactually＠gmail.com
Ovirt newbie here - installing v 4.4.4 (well, trying to!)
Following my post about failing Gluster setup, I can't get the self hosted engine to deploy. I'm installing on my HP DL380p G6. I have 2 disk 170GB Raid 0 for OS and 6 x 330GB disk Raid 5 for Gluster. DNS all set up, but Im realizing I'm missing something here. I have a feeling my problems with Gluster/Engine were caused by incorrect network setup. Seems I'm not the 1st to fall at this hurdle - some people in the community are saying RH have made it's deliberately difficult to get these 'free' set-ups working. It does feel a little like that!
Most instructions just say that a 'self hosted, hyperconverged, single node setup requires 2 nics' - and that's about it! That is the 'Networking Pre-requisites'!
I've had some help on here and Reddit which eventually made me find a solution some had had to use - editing lvm.conf to make sure my drive (sdb) was being blacklisted correctly.
So, with that, Gluster installs, with following DNS settings:
The kvm host (ovirt-kvm.whichelo.com) is fixed ip 192.168.0.40 on my 1st nic (Enp0s7)
ovirt-engine.whichelo.com - 192.168.0.50
and ovirt-gluster.whichelo.com on 192.168.0.60 - I created I VLAN linked to the nic i want to use for gluster (Enp0s8) and gluster install worked.
So now hosted engine won't install,, and pretty sure it's because I don't know how to set the network up properly. I'm seeing virbr0 coming up with different ip's - sometimes 192.168.1.1, sometimes 192.168.222.1. From what I've read, this is something to do with the Engine's network, but I really don't know!
Am I still missing something? I can't find any decent instructions on how to do this - how (exactly) to configure the 2 'minimum required' nics?
I came to Ovirt after realizing Oracle were dumping their own Virtualization platform in favour of KVM. Couldn't set it up from Oracle so moved to Red Hat - that was a no, and I was at the point where it made most sense to just run an Ovirt node for my KVM. I've got much further with Ovirt, but instructions do not work as easily as they looked! (example 'just click on single node hyperconverged' which didn't work straight off the bat until removing that LVM filter, which took days to find out!
The single node HC server is a great match for a home lab/server like mine. I don't want another server, let alone another 2! I'm doing this partly as hobby, but also to update my skills during lockdown. Surely if we can get people using things like this at home, they're more likely to end up using it for work one day?
Any help, or just pointing in the right direction, gratefully received! Hopefully I'm a biit clearer here. Happy to provide any logs or anything else....
Thank you!
3 years, 10 months
