Is it possible to configure libvirt's MAC generation?
by Ian Pilcher
Is it possible to configure libvirt to generate "predictable" MAC
addresses for virtual NICS? (A configuration which accomplishes this
by limiting the pool of available addresses would be acceptable for
my use case.)
Read on for why I want to do this ...
I have a somewhat unusual use case. I am working with the OpenShift
bare metal "IPI" installation process, which is documented here:
https://openshift-kni.github.io/baremetal-deploy/4.4/Deployment.html
At a high level, the installation process goes like this:
1. Install RHEL 8 on the "provisioner" node.
2. Configure a couple of bridges on the provisioner node, which will be
used by the "bootstrap VM" (see below).
3. Create a configuration file & do various other things.
4. Run the installer
a. Installer creates a "bootstrap VM" on the provisioning node, which
does the actual work of kicking off the OpenShift installation.
The bootstrap VM runs Red Hat Enterprise Linux CoreOS (RHCOS).
b. Bootstrap VM requests an IP address via DHCP. <====== ******
Step 4b is problematic in this environment. Because of routing and
firewall rules, I really need the bootstrap VM to have a predictable IP
address.
It is possible to configure a static IP address on the bootstrap VM via
the CoreOS ignition file, and we've successfully done this, but ...
RHCOS requests an IP address via DHCP *before* it processes the ignition
file. If this fails, it appears to simply give up. So we need to have
our DHCP server provide an address to the bootstrap VM, even if it isn't
ever used. And of course, we're not allowed to configure the DHCP
server to respond to any old MAC address that comes along; we're only
allowed to respond to known MAC addresses.
Hopefully this all makes sense, and hopefully it explains why being
able to configure libvirt's MAC pool/sequence would allow things to work
in this environment.
Thanks!
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
5 years
Reintroduce modern CPU in model selection
by Gionatan Danti
Hi list,
in virt-manager ver. 2.2.1 (fully upgraded CentOS 8.1), the CPU model
list only shows ancient CPU (the most recent is Nehalem-IBRS).
On the other hand, in virt-manager 1.5.x (fully upgraded CentOS 7.8) we
have a rich selection of CPU (as recent as Icelake).
Why was the list in newer virt-manager so much trimmed? Is it possible
to enlarge it?
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it [1]
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8
5 years
Live migration to another volume at the same host
by Paul van der Vlis
Hello,
I am looking for a way to migrate a VM live to another location.
The qcow2 images are now on /data , but I want to move some of them to a
volume mounted on /data2 what's faster.
Is this possible without downtime?
With regards,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
5 years
Migrate to a bigger disk possible?
by Paul van der Vlis
Hello,
I have a qcow2 disk what needs to become increased.
I don't have space on the location where it is now to have it two time,
so I want to live-migrate it to another host.
On the other host I have to create a qcow2 disk before I can migrate.
What would happen when I would create there a bigger qcow2 disk then the
original one? Can I resize the filesystem after the migration?
With regards,
Paul van der Vlis
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
5 years
Fwd: Hello
by K. Kahurani
---------- Forwarded message ---------
From: K. Kahurani <k.kahurani(a)gmail.com>
Date: Sun, May 31, 2020 at 2:26 PM
Subject: Hello
To: <eblake(a)redhat.com>
Hello,
Hopefully this finds you well.
This is not a bug report but more or less an inquiry as based on the
information acquired from Jim Fehlig a while back, it is possible you would
have some important information regarding this.
It is currently not possible for me to compile libvirt right from the word
go while configuring with the error [1]. From the look of it and a bit of
searching on the internet, it does look like the package portablexdr is
obsolete.
Could it be that this is a known issue? Could it be there already is a
workaround this? Do you suppose this should go into the mailing list?
Sincerely,
David.
[1]
checking for WIRESHARK_DISSECTOR... no
checking for xdrmem_create in -lportablexdr... no
checking for library containing xdrmem_create... no
configure: error: Cannot find a XDR library
5 years
Disable virtlockd
by Felix Queißner
Hello!
Is it possible to disable the virtlockd daemon or VM file locking? I
start qemu with a -snapshot option which prevents and changes to the
disk image anyways.
Using <readonly /> is not supported for IDE disks.
Another option would be to not require locking on the NFS share, but i
have no idea how.
Can someone help me with that?
Regards
Felix Queißner
5 years
No outbound connectivity from guest VM(fedora 32)
by Justin Stephenson
Hi,
I recently installed a fresh install of Fedora 32 and I am having
trouble with my virtual machine networking, I can ssh and connect into
my guest VMs from my host, but the guest VMs cannot ping out to the
internet.
I am using the "default" NAT virtual network, the interesting thing is
I have made no configuration changes on my host or in the guest VMs,
simply created and installed two VMs(Fedora and RHEL8) in Fedora where
the VMs are having the same issue.
I am happy to provide any logs or command output if that would help.
-Justin
5 years
Permission to disk set wrong when restoring from memory snapshot?
by Liran Rotenberg
Hi all,
Passing on Bug 1840609 <https://bugzilla.redhat.com/show_bug.cgi?id=1840609>
- Wake up from hibernation failed:internal error: unable to execute QEMU
command 'cont': Failed to get "write" lock.
In Ovirt/RHV there is a specific flow that prevents the VM from starting on
the first host.
The result is:
2020-06-09T12:12:58.111610Z qemu-kvm: Failed to get "write" lock
Is another process using the image
[/rhev/data-center/3b67fb92-906b-11ea-bb36-482ae35a5f83/4fd23357-6047-46c9-aa81-ba6a12a9e8bd/images/0191384a-3e0a-472f-a889-d95622cb6916/7f553f44-db08-480e-8c86-cbdeccedfafe]?
2020-06-09T12:12:58.668140Z qemu-kvm: terminating on signal 15 from pid
177876 (<unknown process>)
We have a rerun mechanism. Therefore the VM starts again on another host if
available. On the second try the VM does succeed to run.
After looking in the debug logs (attached in the bug), I have seen this on
the first host:
2020-06-09 12:12:46.288+0000: 177879: debug :
qemuSetupImageCgroupInternal:139 : Not updating cgroups for disk path
'<null>', type: file
2020-06-09 12:12:46.288+0000: 177879: debug : qemuSetupImagePathCgroup:75 :
Allow path
/rhev/data-center/3b67fb92-906b-11ea-bb36-482ae35a5f83/4fd23357-6047-46c9-aa81-ba6a12a9e8bd/images/0191
384a-3e0a-472f-a889-d95622cb6916/7f553f44-db08-480e-8c86-cbdeccedfafe,
perms: rw
*2020-06-09 12:12:46.288+0000: 177879: debug : qemuSetupImagePathCgroup:75
: Allow path
/rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Compute__NFS_GE_compute-ge-4_nfs__0/4fd23357-6047-46c9-aa81-ba6a12a9e8bd/images/0191384a-3e0a-472f-a889-d95622cb6916/7f553f44-db08-480e-8c86-cbdeccedfafe,
perms: r*
And immediately after retry on the second host:
2020-06-09 12:13:01.839+0000: 15781: debug : qemuSetupImagePathCgroup:75 :
Allow path /rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Compute__NFS_GE_compute-ge-4_nfs__0/4fd23357-60
47-46c9-aa81-ba6a12a9e8bd/images/0191384a-3e0a-472f-a889-d95622cb6916/7f553f44-db08-480e-8c86-cbdeccedfafe,
perms: rw
Is it intended and might cause the QEMU error?
Regards,
Liran.
5 years
