Re: libvirt with modified QEMU and OVMF

["Gábor Boskovits" <boskovits@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

P

Lars Böckel <listdump@larf.space> ezt írta (időpont: 2018. szept. 2., V
3:47):

> Hello Guix,
>
> i wanted to recommend some changes to libvirt which would improve the
> usability of libvirt.
>
> 1) OVMF(UEFI) capability with QEMU. In NixOS you can achieve this with
>
>    virtualisation.libvirtd.enable = true;
>    virtualisation.libvirtd.qemuOvmf = true;
>     virtualisation.libvirtd.qemuVerbatimConfig = ''
>       nvram = [ "${pkgs.OVMF}/FV/OVMF.fd:${pkgs.OVMF}/FV/OVMF_VARS.fd" ]
>       user = "1000"
>     '';
>
I was thinking about getting this done for a while. It would be very
useful. Actually there should be a private writable copy of the ovmf
variable area for each vm, and a shared read only for the rest of ovmf.

>
> the "user" part is not necessary but is required for system VMs in
> combination with qemu's pulseaudio driver. qemuVerbatimConfig is the
> config that is at /etc/libvirt/qemu.conf in traditional GNU/Linux
> distributions.
>
> 2) Using a modified QEMU with libvirt. A modified QEMU could help
> sometimes. A way to specify which QEMU package to use would be helpful
> to resolve issues with newer qemu versions or patches which are not
> upstream. While in NixOS you could add patches like this
>
>      nixpkgs.config.packageOverrides = pkgs: rec {
>      qemu = pkgs.qemu.overrideAttrs (attrs:{
>        patches = (lib.filter (x: ! (lib.hasSuffix
> "fix-hda-recording.patch" (builtins.toString x)))  attrs.patches) ++ [
> /path/to/qemu.patch    ];
>         }
>      );
>    };
> j
> to the QEMU package, i don't think this is possible in GuixSD.
>
> Thank you for your work. Please let me know what you think.
>
The libvirt service accepts a libvirt configuration, where you can specify
the libvirt package in use. I guess it would be easy to provide a similar
mechanism to give the qemu package. If qemu is an input of libvirt then
providing a custom libvirt having the custom qemu would be good enough. I'm
on mobile now, so I can't check.

[-- Attachment #2: Type: text/html, Size: 2652 bytes --]