Apparently, it's not guaranteed that _libosinfo_ always supports even
the version of Fedora it's installed on: there's no _fedora42_ in
_libosinfo-1.12.0-2.fc42_ 🤦🏻♂️.
Fortunately, it makes almost no difference what OS variant is selected
at install time, and we probably want the latest features anyway. Thus,
we can just use _fedora-rawhide_ instead of any particular version and
not worry about it.
The Anaconda runtime is _way_ bigger in Fedora 41, presumably
because of the new web UI. Even though we use text-only automated
installs, we still need enough space for the whole thing to fit in RAM.
If `virt-install` fails before the VM starts for the first time; the
`virsh event` process running in the background will never terminate and
therefore the main process will `wait` forever. We can avoid this by
killing the background process if `virt-install` fails.
Although the `newvm.sh` script had a `--vcpus` argument, its value was
never being used.
The `--cpu host` argument for `virt-install` is deprecated in favor of
`--cpu host`.
VMs don't really need graphical consoles; serial terminals are good
enough, or even better given that they are logged. For the few cases
where a graphical console is actually necessary, the `newvm.sh` script
can add one with the `--graphics` argument.
Since the kickstart scripts are now generated from templates by Jenkins,
we need to fetch the final rendered artifacts from the PXE server,
rather than the source files from Gitea.
There are some groups that all hosts should belong to in almost all
cases. Rather than have to remember to add the `--group` arguments for
each of these, the `newvm.sh` script will now enable them by default.
For hosts that should _not_ belong to (at least one of) these groups,
the `--no-default-groups` argument can be provided to suppress that
behavior.
The default groups, initially, are _chrony_ and _collectd_.
The script that runs on first boot of a new machine that triggers
host provisioning can read the name of the configuration policy branch
to checkout from the QEMU firmware configuration option. This commit
adds a `--cfg-branch` argument to `newvm.sh` that sets that value. This
will be useful for testing new policy on a new VM.
This commit adds a new `--group` argument to the `newvm` script, which
adds the host to an Ansible group by listing it in the _libvirt_ domain
metadata. Multiple groups can be specified by repeating the argument.
Additionally, the VM title is now always set to machine's FQDN, which
is what the dynamic inventory plugin uses to determine the inventory
hostname.
The dynamic inventory plugin parses the _libvirt_ domain metadata and
extracts group membership from the `<dch:groups>` XML element. Each
`<dch:group>` sub-element specifies a group to which the host belongs.
Unfortunately, `virt-install` does not support modifying the
`<metadata>` element in the _libvirt_ domain XML document, so we have
to resort to using `virsh`. To ensure the metadata are set before the
guest OS boots and tries to access them, we fork and run `virsh` in
a separate process.
Now that we have multiple domains (_pyrocufflink.blue_ for AD domain
members and _pyrocufflink.black_ for the new machines), we need a way to
specify the domain for new machines when they are created. Thus, the
`newvm.sh` script accepts either an FQDN or a `--domain` argument. The
DHCP server will register the DNS name in the zone containing the
machine's domain name.
When a VM uses a serial port for its default console, kernel messages
(e.g. panics) are lost if no console client is connected at the time.
This is a major disadvantage when compared to a graphical console, which
usually at least keeps a "screenshot" of the console when the kernel
crashes.
While researching the available console device types to determine how
best to implement a tool that would both log the output from the serial
console at all times, while still allowing interactive connections to
it, I discovered that _libvirt_ actually already has this exact
functionality built-in:
https://libvirt.org/formatdomain.html#consoles-serial-parallel-channel-devices
Although the `newvm.sh` script had a variable to configure the value
specified for the `--network` argument to `virt-install`, it didn't
expose a way to set it. We need this ability so we can e.g. create VMs
on non-default networks like `camera` or `mgmt`.
For the longest time, whenever I needed to create a new virtual machine,
I just used `Ctrl+R` to find the last `virt-install` command I had run
and tweaked it for the new machine. At some point, my `~/.zsh_history`
overflowed, though, so the command I had been running got lost. To
avoid this silliness in the future, I've created a script that runs
`virt-manager` for me. As a bonus, it has some configuration flags for
the parameters that often vary between machines. For most machines,
though, the script can be run as simply as `newvm.sh name`.
Dustin