Valid Generic HTML
SPDX-License-Identifier
CC-BY-SA-4.0

New Virtual Machine on KVM-qemu

James F. Carter <jimc@jfcarter.net>, 2023-01-23

I have a project ( Home Automation Upgrade (2022)) that requires a virtual machine with booting by EFI (Extensible Firmware Interface), and as part of this campaign I needed to upgrade my procedures for creating virtual machines in general. In particular I wanted to burst into the new millennium with a btrfs (binary tree filesystem) for the root, which has been the default for OpenSuSE for several years and which has a lot of technical advantages.

Of course I knew that all this would be a big learning experience, so instead of delaying the upgrade by making the btrfs root a prerequisite for running Home Assistant, I used the Debian x86_64 image for Home Assistant. It's working well and has given no trouble. But the OS and kernel are not going to get updated, just the Home Assistant software, and we don't get root access to the OS, similar to the situation with commercial home automation appliances. [Update: the OS and kernel do get updated, removing my biggest objection to using the H-A OS image.] All my other machines run OpenSuSE Tumbleweed and my system administration software is configured for that distro, so I continued the sub-project to put OpenSuSE's package of Home Assistant Supervised on a second VM running Tumbleweed.

Dramatis personae: this subprojet involves five hosts:

Here's what I did to get OpenSuSE Tumbleweed (with jimc package selection, admin scripts, etc) onto a KVM-qemu virtual machine with EFI booting and a btrfs root filesystem. The reader should keep in mind that, while documenting this installation, my goal is not only to share commonly applicable points with the general community, but also to aid my memory in reproducing my idiosyncratic preferred features on future virtual machines. This to-do list is the union of quite a number of false starts and repair interventions. It was done first on Orion, and again on Ocelot to verify that the procedure was working reliably and/or to shake out remaining bugs. The procedure is described in terms of Ocelot.

Create a New Disc

This is all happening on the VM's host, Jacinth hosting Orion, or Iris hosting Ocelot. On my machines that host VMs I have a partition with a lot of free space, called /s1, a directory /s1/kvm, and within that, a home directory for each guest.

Create the Installation DVD

I knew that I would need to repeat these steps several times (ended up 8 times), so I downloaded the OpenSuSE Tumbleweed installation DVD. Normally the ISO file would go on the VM host, but I've found it convenient to put one copy on my installation server, and let all the hosts get it by NFS. How I use it:

Create New XML for the VM

I'm creating new XML from scratch using virt-manager, rather than copying an old VM's XML, to get the latest best practices and to leave behind accumulated cruft. Then I will compare the new and old XML, and I'll bring forward a few important details.

Booting the Installer DVD

Partitioning and BTRFS

Here we reconcile SuSE and local policies about storage, and develop new policies for btrfs.

More Mundane Setup Steps

Installation Settings Overview

Checkout and Configuration

This particular instance was created just to verify and collect procedures for the initial installation, so I'm not going to go through the full post_jump procedure (install my wanted packages, (re)enable services, remove unwanted packages, online update, install my configuration files). But there are a few items needed before post_jump that should be documented.

Things to Do with Power Off