THe cloud image is shipped as a qcow2 file. It has about 3 GB of usable space. I need more.
Continue readingResizing filesystem on A Fedora 43 Cloud image
Reply
Category Archives: Virtualization
Network setup for a custom Qemu Virtual Machine
After building a custom Qemu, there are a couple ways to run a VM to get to it. The older approach to VM management is to create a block device, run the VM with a boot device, do a full install and log in to the serial console. However, if you run the Qemu/KVM machine from the command lilne, hitting control C will stop your VM, and this is annoying. I have found it worth while to set up networking and then to SSH in to the machine.
My notes here suck. I am going to try and document what I have here working, and, over time, reverse engineer how I got here.
Edit: here are the steps
A PCC driver in Qemu
In order to perform test driven development, you need a way to drive your code that can isolate behavior. Linux Kernel drivers that communicate with hardware devices can be hard to test: you might not have access to the hardware from your test systems, or the hardware may be flakey. I have such a set of issues with the Platform Communication Channel (PCC) drivers I am working with.
My primary work has been with a network driver that only exists on the newest hardware. However, I also need to be able to handle some drivers that would only work against old hardware. There are also PCC based drivers for hardware that my company does not support or have access to. I might want to make a test to ensure that changes to the Linux Kernel PCC driver does not change its behavior against these drivers. There exists no system where all of these drivers would be supported. But I can build one with Qemu.
The Qemu based driver might not completely simulate the hardware exactly as implemented, and that is OK: I want to be able to do things with Qemu I cannot do with current hardware. For example, the MCTP-over-PCC driver should be able to handle a wide array of messages, but the hardware I have access to only supports a very limited subset of message types.
The full code for the device is here.
Here is how I went about building a Qemu based PCC driver.
Continue readingInstall a custom Kernel inside a VM
When debugging Qemu, it might be helpoful to instrument Linux Kernel to see when interrupts get received, or see data on the other side of a transfer. If you have to modify the Kernel on a regular basis, it can be faster to build it in place than to build a customer RPM/DEB and install inside the VM. Here is how I have been going about updating the kernel.
Continue readingViewing the Flattened Device Tree from Qemu
The Qemu implementation uses a Flattened Device Tree (FTD) to manage the virtual implementation of the physical devices in a machine. I need to create a FTD entry for the MCTP-PCC implementation I am writing in Qemu. Since this is new to me, and I am working (as I most often do) via Ttrial and error, I want to see the FTD entry after I write it. Here is how I am dumping it.
Continue readingDebugging Qemu with gdb
When developing Linux Kernel code, I have found myself wanting to have a test fixture inside the Firmware that lets me inspect the values communicated out of and into the Linux Kernel. I am currently writing one such fixture in Qemu. And I have an interrupt that is not getting handled by the Linux Kernel, I think because it is not getting delivered.
I have found it quite valuable to run this Qemu process in the Gnu Debugger. Here is how I (with help) got to the bottom of the mystery.
Continue readingOne liner to install Fedora Cloud image in a local VM
sudo virt-install --name fedora40 --os-variant fedora40 --disk /var/lib/libvirt/images/Fedora-Cloud-Base-Generic.x86_64-40-1.14.qcow2 --import --cloud-init root-ssh-key=/home/ayoung/.ssh/id_rsa.pub
Using virt-install and cloud-init
I want to call out a stellar article that told me exactly what I needed to do in order to use virt-install and cloud-init to launch a cloud-image. The only thing I have to add is the caveat that the #cloud-config comment at the top of the user-data file is required. The system will ignore the file if it does not start with that comment. This is the easiest way I know to launch a brand new VM.
XPath for libvirt external snapshop path
The following xmllint XPath query will pull out the name of the backing file for a VM named fedora-server-36 and an external snapshot named fedora-36-post-install,
virsh snapshot-dumpxml fedora-server-36 fedora-server-36-post-install | xmllint --xpath "string(//domainsnapshot/disks/disk[@snapshot='external']/source/@file)" - |
The string function extracts the attribute value.
This value can be used in the process of using or deleting the snapshot.
Parsing libvirt xmldump using xpath
In a recent article, I saw yet another example of using grep to pull information out of xml, and then to manually look for a field. However, XML is structured, and with XPath, we can pull out exactly what we need.
virsh dumpxml fedora-server-36 | xmllint --xpath "//domain/devices/disk[@device='disk']" - |
That will produce output like this:
<disk type="file" device="disk"> <driver name="qemu" type="qcow2" discard="unmap"/> <source file="/var/lib/libvirt/images/fedora-server-36.qcow2"/> <target dev="vda" bus="virtio"/> <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/> </disk> |
Note that I did more in my XPath than required by the original article. I wanted to show an example of querying based on an attribute inside the selected node.
Update: Here is an example for what is done later in the article: pull the path out of the pool xml.
virsh pool-dumpxml default | xmllint --xpath "//pool/target/path/text()" - /var/lib/libvirt/images |