Re: libvirt with modified QEMU and OVMF

Re: libvirt with modified QEMU and OVMF

[Lars Böckel]

So to follow this up now. I tried these: 
     (simple-service 'qemu-conf etc-service-type
                   `(("libvirt/qemu.conf"
                      ,(mixed-text-file "qemu.conf"
                                         "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin \n
user='1000'"))))

    (extra-special-file "/etc/libvirt/qemu.conf"
                    (plain-file
		      "etc/libvirt/qemu.conf"
			     "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin \n
user='1000'"))


also i tried to edit the libvirt package by doing this:
         (replace 'install
           ;; Since the sysconfdir and localstatedir should be /etc
and /var ;; at runtime, we must prevent writing to them at installation
           ;; time.
           (lambda _
             (invoke "make" "install"
                            "sysconfdir=/tmp/etc"
                            "localstatedir=/tmp/var")))
	 (add-after 'install 'ovmf-stuff
		       (lambda* (#:key outputs #:allow-other-keys)
             (let* ((output (assoc-ref outputs "out"))
                    (etclibvirt (string-append output "/etc/libvirt")))
               (mkdir-p etclibvirt)
               (with-output-to-file
                   (string-append etclibvirt "/qemu.conf")
                 (lambda _
                   (format #t
                           "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin user='1000'"
                           output))))))

         (add-after 'ovmf-stuff 'wrap-libvirtd
           (lambda* (#:key inputs outputs #:allow-other-keys)
             (let ((out (assoc-ref outputs "out")))
               (wrap-program (string-append out "/sbin/libvirtd")
                 `("PATH" = (,(string-append (assoc-ref inputs
         "iproute") "/sbin")
                             ,(string-append (assoc-ref inputs "qemu")
                                             "/bin"))))

i really hope that after my mail client butchered it it is still
readable. to summarize: an etc-service-type will not work because it
links to /etc/libvirt which alredy exist and an extra-special-file will
not work because "invalid character `/' in name
`etc/libvirt/qemu.conf'". The file created in the package does not
exist in /etc but in /run/current-system/profile/etc where libvirt
probably does not read. At least it does not work as expected. 





> Thanks for sharing your idea about it. I cannot pull right now but i 
> think ...nvram = " ovmf "/F... would not work since you would have to 
> call the complete path of the package. Though something like "nvram = 
> /run/current-system/profile/share/firmware/ovmf_x64.bin" COULD work.
> I don't know how it would react to the massive wall of symlinks. That
> is probably the reason why NixOS calls it with ${pkgs.OVMF}. The
> produced file in NixOS (/var/lib/libvirt/qemu.conf) points
> to /nix/store/.... For usability something you can just put in
> libvirt-service-type with #t would be good for usability. As well as
> the user variable. Configurations like these are probably more common
> than changing tls-ports and would simplify the migration of people
> running different systems since they could more easily configure VMs
> with UEFI support.
> 
> When my internet is running again i will pull and try this config.
> But since its saturday that might take some time... You can easily
> check for UEFI support in libvirt with either virt-install --boot
> uefi or in virt-manager when you create a vm and edit it beforehand
> you have a dropdown menu for BIOS/UEFI. If someone could test it out
> and report back that would be great!
> 
>   
> >> i would like to push the issue with OVMF in libvirt again:
> >>
> >> I would like to have 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" '';
> >>
> >> 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.    
> > I don’t know about OVMF but IIUC, what you need here is to create
> > /etc/libvirt/qemu.conf.  To do that, you can something along these
> > lines:
> >
> >    (simple-service 'qemu-conf etc-service-type
> >                    `(("libvirt/qemu.conf"
> >                       ,(mixed-text-file "qemu.conf"
> >                                          "nvarm = "
> >                                          ovmf "/FV/OVMF.fd:…'))))
> >
> > Would that work?
> >
> > (Actually the “libvirt/” bit is only possible since commit
> > 5dec93bb8ba89605bce2f9a5ee9c4dbadeee3b58, a few minutes ago…)
> >
> > We could provide a proper abstraction on top of that if needed, but
> > I’m not familiar with libvirt.  If you have ideas on how to improve
> > this, that’d be great!
> >
> > Thanks,
> > Ludo’.    

libvirt with modified QEMU and OVMF

[Lars Böckel]

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"
    '';

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    ];
        }
     );
   };

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.

Re: libvirt with modified QEMU and OVMF

[Gábor Boskovits]

[-- 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 --]

Re: libvirt with modified QEMU and OVMF

[Ricardo Wurmus]

Gábor Boskovits <boskovits@gmail.com> writes:

> 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.

Qemu is indeed an input to libvirt.

-- 
Ricardo

Re: libvirt with modified QEMU and OVMF

[Ludovic Courtès]

Hi Lars,

Lars Böckel <listdump@larf.space> skribis:

> 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    ];
>        }
>     );
>   };
>
> to the QEMU package, i don't think this is possible in GuixSD.

As Gábor suggested, you would do it along these lines:

  (define qemu-patched
    (package
      (inherit qemu)
      …))

  (define custom-libvirt
    (package
      (inherit libvirt)
      (inputs `(("qemu" ,qemu-patched)
                ,@(alist-delete "qemu" (package-inputs libvirt))))))

  (operating-system
    ;; …
    (services (cons (service libvirt-service-type
                             (libvirt-configuration
                               (libvirt custom-libvirt)))
                    %base-services)))


It’s not equivalent to the above Nix snippet because it only affects the
libvirt service, but it addresses this particular need.

HTH,
Ludo’.

Re: libvirt with modified QEMU and OVMF

[Ludovic Courtès]

Hello,

(+Cc: guix-devel.)

Lars Böckel <listdump@larf.space> skribis:

> thanks for the suggestion. I had success with a snipplet similiar to
> yours. So i would call that issue "fixed" even though its not pretty.

Cool.

> i would like to push the issue with OVMF in libvirt again:
>
> I would like to have 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"
>    '';
>
> 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.

I don’t know about OVMF but IIUC, what you need here is to create
/etc/libvirt/qemu.conf.  To do that, you can something along these
lines:

  (simple-service 'qemu-conf etc-service-type
                  `(("libvirt/qemu.conf"
                     ,(mixed-text-file "qemu.conf"
                                        "nvarm = "
                                        ovmf "/FV/OVMF.fd:…'))))

Would that work?

(Actually the “libvirt/” bit is only possible since commit
5dec93bb8ba89605bce2f9a5ee9c4dbadeee3b58, a few minutes ago…)

We could provide a proper abstraction on top of that if needed, but I’m
not familiar with libvirt.  If you have ideas on how to improve this,
that’d be great!

Thanks,
Ludo’.

Re: libvirt with modified QEMU and OVMF

[Lars Böckel]

Thanks for sharing your idea about it. I cannot pull right now but i 
think ...nvram = " ovmf "/F... would not work since you would have to 
call the complete path of the package. Though something like "nvram = 
/run/current-system/profile/share/firmware/ovmf_x64.bin" COULD work. I 
don't know how it would react to the massive wall of symlinks. That is 
probably the reason why NixOS calls it with ${pkgs.OVMF}. The produced 
file in NixOS (/var/lib/libvirt/qemu.conf) points to /nix/store/....
For usability something you can just put in libvirt-service-type with #t 
would be good for usability. As well as the user variable. 
Configurations like these are probably more common than changing 
tls-ports and would simplify the migration of people running different 
systems since they could more easily configure VMs with UEFI support.

When my internet is running again i will pull and try this config. But 
since its saturday that might take some time... You can easily check for 
UEFI support in libvirt with either virt-install --boot uefi or in 
virt-manager when you create a vm and edit it beforehand you have a 
dropdown menu for BIOS/UEFI. If someone could test it out and report 
back that would be great!


>> i would like to push the issue with OVMF in libvirt again:
>>
>> I would like to have 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"
>>     '';
>>
>> 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.
> I don’t know about OVMF but IIUC, what you need here is to create
> /etc/libvirt/qemu.conf.  To do that, you can something along these
> lines:
>
>    (simple-service 'qemu-conf etc-service-type
>                    `(("libvirt/qemu.conf"
>                       ,(mixed-text-file "qemu.conf"
>                                          "nvarm = "
>                                          ovmf "/FV/OVMF.fd:…'))))
>
> Would that work?
>
> (Actually the “libvirt/” bit is only possible since commit
> 5dec93bb8ba89605bce2f9a5ee9c4dbadeee3b58, a few minutes ago…)
>
> We could provide a proper abstraction on top of that if needed, but I’m
> not familiar with libvirt.  If you have ideas on how to improve this,
> that’d be great!
>
> Thanks,
> Ludo’.

Re: libvirt with modified QEMU and OVMF

[Ricardo Wurmus]

Lars Böckel <listdump@larf.space> writes:

> Thanks for sharing your idea about it. I cannot pull right now but i
> think ...nvram = " ovmf "/F... would not work since you would have to
> call the complete path of the package.

“ovmf” is a package variable.  It would automatically be replaced with
the full path to the package.

--
Ricardo

Re: libvirt with modified QEMU and OVMF

[Lars Böckel]

So to follow this up now. I tried these: 
     (simple-service 'qemu-conf etc-service-type
                   `(("libvirt/qemu.conf"
                      ,(mixed-text-file "qemu.conf"
                                         "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin \n
user='1000'"))))

    (extra-special-file "/etc/libvirt/qemu.conf"
                    (plain-file
		      "etc/libvirt/qemu.conf"
			     "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin \n
user='1000'"))


also i tried to edit the libvirt package by doing this:
         (replace 'install
           ;; Since the sysconfdir and localstatedir should be /etc
and /var ;; at runtime, we must prevent writing to them at installation
           ;; time.
           (lambda _
             (invoke "make" "install"
                            "sysconfdir=/tmp/etc"
                            "localstatedir=/tmp/var")))
	 (add-after 'install 'ovmf-stuff
		       (lambda* (#:key outputs #:allow-other-keys)
             (let* ((output (assoc-ref outputs "out"))
                    (etclibvirt (string-append output "/etc/libvirt")))
               (mkdir-p etclibvirt)
               (with-output-to-file
                   (string-append etclibvirt "/qemu.conf")
                 (lambda _
                   (format #t
                           "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin user='1000'"
                           output))))))

         (add-after 'ovmf-stuff 'wrap-libvirtd
           (lambda* (#:key inputs outputs #:allow-other-keys)
             (let ((out (assoc-ref outputs "out")))
               (wrap-program (string-append out "/sbin/libvirtd")
                 `("PATH" = (,(string-append (assoc-ref inputs
         "iproute") "/sbin")
                             ,(string-append (assoc-ref inputs "qemu")
                                             "/bin"))))

i really hope that after my mail client butchered it it is still
readable. to summarize: an etc-service-type will not work because it
links to /etc/libvirt which alredy exist and an extra-special-file will
not work because "invalid character `/' in name
`etc/libvirt/qemu.conf'". The file created in the package does not
exist in /etc but in /run/current-system/profile/etc where libvirt
probably does not read. At least it does not work as expected. 





> Thanks for sharing your idea about it. I cannot pull right now but i 
> think ...nvram = " ovmf "/F... would not work since you would have to 
> call the complete path of the package. Though something like "nvram = 
> /run/current-system/profile/share/firmware/ovmf_x64.bin" COULD work.
> I don't know how it would react to the massive wall of symlinks. That
> is probably the reason why NixOS calls it with ${pkgs.OVMF}. The
> produced file in NixOS (/var/lib/libvirt/qemu.conf) points
> to /nix/store/.... For usability something you can just put in
> libvirt-service-type with #t would be good for usability. As well as
> the user variable. Configurations like these are probably more common
> than changing tls-ports and would simplify the migration of people
> running different systems since they could more easily configure VMs
> with UEFI support.
> 
> When my internet is running again i will pull and try this config.
> But since its saturday that might take some time... You can easily
> check for UEFI support in libvirt with either virt-install --boot
> uefi or in virt-manager when you create a vm and edit it beforehand
> you have a dropdown menu for BIOS/UEFI. If someone could test it out
> and report back that would be great!
> 
> 
> >> i would like to push the issue with OVMF in libvirt again:
> >>
> >> I would like to have 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" '';
> >>
> >> 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.  
> > I don’t know about OVMF but IIUC, what you need here is to create
> > /etc/libvirt/qemu.conf.  To do that, you can something along these
> > lines:
> >
> >    (simple-service 'qemu-conf etc-service-type
> >                    `(("libvirt/qemu.conf"
> >                       ,(mixed-text-file "qemu.conf"
> >                                          "nvarm = "
> >                                          ovmf "/FV/OVMF.fd:…'))))
> >
> > Would that work?
> >
> > (Actually the “libvirt/” bit is only possible since commit
> > 5dec93bb8ba89605bce2f9a5ee9c4dbadeee3b58, a few minutes ago…)
> >
> > We could provide a proper abstraction on top of that if needed, but
> > I’m not familiar with libvirt.  If you have ideas on how to improve
> > this, that’d be great!
> >
> > Thanks,
> > Ludo’.