[Forwarding with Laszlo's permission - if ever you wonder whether your work on libvirt makes a difference, it does!] -------- Original Message -------- Message-ID: <528FCF54.6060203(a)redhat.com&gt; Date: Fri, 22 Nov 2013 22:40:36 +0100 From: Laszlo Ersek <lersek(a)redhat.com&gt; Subject: Re: [Qemu-devel] [edk2 PATCH] OvmfPkg: split the variable store to a separate file On 11/22/13 21:51, Jordan Justen wrote: OK. Let's see where the qemu patch goes (I'll have to fix the comment typo that Eric found), and if it is accepted (maybe with modifications), we can return to the OVMF patch. But (thanks to you) we now have a flash driver in OVMF that works *in practice*. The discussion about multiple -pflash flags is not academic any longer. (Hm, sorry, that's maybe too strong -- I can't really say if the discussion used to be academic before. But it cannot have been this practical.) We also know that the libvirt developers prefer the split file. Plus: We're in violent agreement on that -- which emphasizes the need for good libvirt support all the more. Seriously, I refuse to work with the qemu command line day to day. I have an elaborate wrapper script that I insert between qemu and libvirt (specified in the <emulator> libvirt domain XML) that post-processes the arguments composed by libvirt. I need this to test out features that libvirt doesn't yet support. For example, I can set various filenames in the <loader> element -- it specifies the argument to the -bios option. In the script I check the argument against various patterns, and I can turn it into: - -bios "$ARG" - -pflash "$ARG" - -pflash "$ARG" -pflash "$(manipulate "$ARG")" The script handles CSM vs. pure-UEFI for Windows 2008, it can honor upstream vs. RHEL qemu differences, it can turn off the iPXE virtio-net driver. In the single -pflash option case, it does refresh the code part in the VM's copy of OVMF (with dd) from my most recent build. It sets a name-dependent output file for the debug port. Etc. Maintaining this script over months has paid off orders of magnitude better than working with the raw qemu command line would have. (I can compare: on my (occasionally used) AMD desktop that runs Debian I have not bothered to install libvirt, and each time I need to modify the forty line qemu command that I keep in a script file, I cringe. And I can't bring myself to install a second guest.) The convenience/efficiency libvirt gives me is critical. Changing boot order, adding or removing devices, starting & stopping -- these are very fast in virt-manager. Editing the configuration with virsh is nice (and it has some level of automatic verification when you save and exit). Comparing guest configs against each other (using the XMLs) is very convenient. And so on. I depend on these every day, but I need to modify the wrapper script only occasionally. Libvirt still allows me to send custom monitor commands, and I can set it to log all of its *own* commands that it sends to the monitor or the guest agent. I've always wondered how other developers (for example, you :)) can exist without libvirt at all! That is why "keep the qemu command line simple" (== approx. "two -pflash options are inconvenient") is no concern of mine. That ship has sailed. Thanks, Laszlo