kvm plugin - during update - correct response to "Installing new version of config file /etc/libvirt/qemu.conf"?

1st Official Post

    I stumbled over "updates available" in dashboard, but when I tried to apply them

    "The following packages have been kept back: libvirt-clients libvirt-daemon libvirt-daemon-config-network libvirt-daemon-config-nwfilter libvirt-daemon-driver-qemu libvirt-daemon-system libvirt-daemon-system-systemd libvirt0 qemu-system-arm qemu-system-common qemu-system-data qemu-system-mips qemu-system-ppc qemu-system-x86 qemu-utils

    0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded."

    was reported


    I assume these are packages installed via kvm plugin but might be wrong.

    To find the reason I was manually running "sudo apt-get install libvirt-clients".

    This command asked:


    "

    Installing new version of config file /etc/apparmor.d/abstractions/libvirt-qemu ...

    Installing new version of config file /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper ...

    Installing new version of config file /etc/apparmor.d/usr.sbin.libvirtd ...

    Installing new version of config file /etc/libvirt/libvirtd.conf ...


    Configuration file '/etc/libvirt/qemu.conf'

    ==> Modified (by you or by a script) since installation.

    ==> Package distributor has shipped an updated version.

    What would you like to do about it ? Your options are:

    Y or I : install the package maintainer's version

    N or O : keep your currently-installed version

    D : show the differences between the versions

    Z : start a shell to examine the situation

    The default action is to keep your current version.

    *** qemu.conf (Y/I/N/O/D/Z) [default=N] ?

    "

    the relevant differences are from my view:


    "

    *** qemu.conf (Y/I/N/O/D/Z) [default=N] ? d

    --- /etc/libvirt/qemu.conf 2022-04-26 14:27:17.468125705 +0200

    +++ /etc/libvirt/qemu.conf.dpkg-new 2022-01-14 15:05:54.000000000 +0100


    -vnc_listen = "0.0.0.0"

    +#vnc_listen = "0.0.0.0"


    -nvram = [

    - "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",

    - "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd",

    - "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd",

    - "/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd"

    -]

    +#nvram = [

    +# "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",

    +# "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd",

    +# "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd",

    +# "/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd"

    +#]

    "



    I wonder what is the correct answer, any hints?

    omv 6.1.4-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 5.15.84-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 5.6.21-1 (usul) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    Edited 2 times, last by mi-hol: differences added ().

    • Official Post

    You want to accept the default which is what installing the updates from the Updates tab would do. If you change the file to the new settings, your vnc viewer might not work. I might need to test that now that the plugin isn't running vnc in docker though.

    omv 6.3.4-1 Shaitan | 64 bit | 6.1 proxmox kernel

    plugins :: omvextrasorg 6.1.1 | kvm 6.2.9 | compose 6.6.1 | cputemp 6.1.3 | mergerfs 6.3.5 | zfs 6.0.12


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Quote from ryecoaaron

    You want to accept the default which is what installing the updates from the Updates tab would do.

    Thanks, that was my conclusion too.
    As customization of configuration file '/etc/libvirt/qemu.conf' is required for the plugin to work as intended, would flagging the file as an intentional "deviation" avoid the confusion?

    omv 6.1.4-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 5.15.84-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 5.6.21-1 (usul) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    • Official Post
    Quote from mi-hol

    would flagging the file as an intentional "deviation" avoid the confusion?

    The deviations OMV is currently using have been more trouble than they are worth. So, no. I am going to see if the changes are needed at all though.

    omv 6.3.4-1 Shaitan | 64 bit | 6.1 proxmox kernel

    plugins :: omvextrasorg 6.1.1 | kvm 6.2.9 | compose 6.6.1 | cputemp 6.1.3 | mergerfs 6.3.5 | zfs 6.0.12


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login