Edit UEFI varstores

See end of post for an important update

UEFI firmware has a concept of persistent variables. They are used to control the boot order amongst other things. They are stored in non-volatile RAM on the system board, or for virtual machines in a host file.

When a UEFI machine is running you can edit these variables using various tools, such as Peter Jones’s efivar library, or the efibootmgr program.

These programs don’t actually edit the varstore directly. They access the kernel /sys/firmware/efi interface, but even the kernel doesn’t edit the varstore. It just redirects to the UEFI runtime “Variable Services”, so what is really running is UEFI code (possibly proprietary, but more usually from the open source TianoCore project).

So how can you edit varstores offline? The NVRAM file format is peculiar to say the least, and the only real specification is the code that writes it from Tianocore. So somehow you must reuse that code. To make it more complicated, the varstore NVRAM format is tied to the specific firmware that uses it, so varstores used on aarch64 aren’t compatible with those on x86-64, nor are SecureBoot varstores compatible with normal ones.

virt-efivars is an attempt to do that. It’s rather “meta”. You write a small editor program (an example is included), and virt-efivars compiles it into a tiny appliance. You then boot the appliance using qemu + UEFI firmware + varstore combination, the editor program runs and edits the varstore, using the UEFI code.

It works .. at least on aarch64 which is the only convenient machine I have that has virtualized UEFI.

Git repo: http://git.annexia.org/?p=virt-efivars.git;a=summary

Update:

After studying this problem some more, Laszlo Ersek came up with a different and better plan:

  1. Boot qemu with only the OVMF code & varstore attached. No OS or appliance.
  2. This should drop you into a UEFI shell which is accessible over qemu’s serial port.
  3. Send appropriate setvar commands to update the variables. Using expect this should be automatable.

Leave a comment

Filed under Uncategorized

Restarting squid results in deleting all files in hard-drive

An awful lot of noise and nonsense is being made about this bug. Here are a couple of facts:

  1. The bug was never in any released version of RHEL.
  2. It was caught during Red Hat’s internal QA process. The bug report is filed by a Red Hat tester.

In other words, the system works. Anyone who says this is a bug in RHEL or Red Hat is releasing buggy software that will eat your hard drive is lying to you.

Leave a comment

Filed under Uncategorized

Mini Cloud/Cluster v2.0

Last year I wrote and rewrote a little command line tool for managing my virtualization cluster.

Of course I could use OpenStack RDO but OpenStack is a vast box of somewhat working bits and pieces. I think for a small cluster like mine you can get the essential functionality of OpenStack a lot more simply — in 1300 lines of code as it turns out.

The first thing that small cluster management software doesn’t need is any permanent daemon running on the nodes. The reason is that we already have sshd (for secure management access) and libvirtd (to manage the guests) out of the box. That’s quite sufficient to manage all the state we care about. My Mini Cloud/Cluster software just goes out and queries each node for that information whenever it needs it (in parallel of course). Nodes that are switched off are handled by ignoring them.

The second thing is that for a small cloud we can toss features that aren’t needed at all: multi-user/multi-tenant, failover, VLANs, a nice GUI.

The old mclu (Mini Cluster) v1.0 was written in Python and used Ansible to query nodes. If you’re not familiar with Ansible, it’s basically parallel ssh on steroids. This was convenient to get the implementation working, but I ended up rewriting this essential feature of Ansible in ~ 60 lines of code.

The huge down-side of Python is that even such a small program has loads of hidden bugs, because there’s no safety at all. The rewrite (in OCaml) is 1,300 lines of code, so a fraction larger, but I have a far higher confidence that it is mostly bug free.

I also changed around the way the software works to make it more “cloud like” (and hence the name change from “Mini Cluster” to “Mini Cloud”). Guests are now created from templates using virt-builder, and are stateless “cattle” (although you can mix in “pets” and mclu will manage those perfectly well because all it’s doing is remote libvirt-over-ssh commands).

$ mclu status
ham0                     on
                           total: 8pcpus 15.2G
                            used: 8vcpus 8.0G by 2 guest(s)
                            free: 6.2G
ham1                     on
                           total: 8pcpus 15.2G
                            free: 14.2G
ham2                     on
                           total: 8pcpus 30.9G
                            free: 29.9G
ham3                     off

You can grab mclu v2.0 from the git repository.

Leave a comment

Filed under Uncategorized

Random numbers in virtual machines

My colleague Amit Shah wrote this interesting article about getting random numbers inside virtual machines.

Leave a comment

Filed under Uncategorized

How to boot a Fedora 21 aarch64 UEFI guest on x86_64

You can use virt-builder to make Fedora 21 aarch64 guests easily:

$ virt-builder --arch aarch64 fedora-21

but unless you have real aarch64 hardware, how do you boot them?

Well the latest qemu supports working system emulation for 64 bit ARM. So assuming you (a) have compiled a very new qemu-system-aarch64 (I recommend qemu from git), and (b) you have the AAVMF (UEFI for aarch64) firmware, then:

$ qemu-system-aarch64 \
    -nodefconfig -nodefaults -display none \
    -M virt -cpu cortex-a57 -machine accel=tcg -m 2048 \
    -drive if=pflash,format=raw,file=AAVMF_CODE.fd,readonly \
    -drive if=pflash,format=raw,file=vars.fd \
    -drive file=fedora-21.img,format=raw,if=none,id=hd0 \
    -device virtio-blk-device,drive=hd0 \
    -netdev user,id=usernet \
    -device virtio-net-device,netdev=usernet \
    -serial stdio

And that will boot the aarch64 guest.

Edit: If using Gerd’s AAVMF repo, replace AAVMF_CODE.fd with /usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw

3 Comments

Filed under Uncategorized

100 core ARM 64 bit chip

http://www.prnewswire.com/news-releases/ezchip-introduces-tile-mx100-worlds-highest-core-count-arm-processor-optimized-for-high-performance-networking-applications-293647261.html

They claim “linear scaling of application performance” which I rather doubt unless your application is web serving.

Leave a comment

Filed under Uncategorized

virt-builder: Fedora 21 aarch64 image available

Why has wordpress.com decided to break all inline images in postings?

If you have ARM 64 bit hardware, you can now use virt-builder to create Fedora 21 guests …

$ virt-builder fedora-21
[   1.0] Downloading: http://libguestfs.org/download/builder/fedora-21-aarch64.xz
[   5.0] Planning how to build this image
[   5.0] Uncompressing
[  12.0] Opening the new disk
[  44.0] Setting a random seed
[  44.0] Setting passwords
virt-builder: Setting random password of root to JRjjjDxEfsZuCWca
[  47.0] Finishing off
                   Output file: fedora-21.img
                   Output size: 4.0G
                 Output format: raw
            Total usable space: 5.2G
                    Free space: 4.4G (85%)

I’m thankful to Pino Toscano for adding multi-architecture support to virt-builder a while back.

As shown above, virt-builder will pick the right architecture corresponding to the host, or you can override its choice by using --arch.

2 Comments

Filed under Uncategorized