QEMU 6.2 available on no-subscription as of now

t.lamprecht · Apr 14, 2022

FYI: The next PVE 7.2 (2022/Q2) release will default to QEMU 6.2. Internal testing for that version started in February, and it has been made available on the pvetest repository and used for our production work loads since start of March. Besides some initial regression fixes, we saw no actual new issues coming up.

To upgrade ensure you got valid Proxmox VE repositories configured and then use the standard:

Bash:

apt update
apt full-upgrade

or use the upgrade functionality of the web-interface.

pveversion -v (or the web-interface's Node Summary -> Packages versions) should then include something like pve-qemu-kvm: 6.2.0-2

Note, as with all QEMU updates: A VM needs to be either fully restarted (shutdown/start or using restart via the CLI or web-interface) or, to avoid downtime, live-migrated to an already upgraded host to actually run with the newer QEMU version.

While we successfully run our production and lots of testing loads on this version since a while, no software is bug free, and often such issues are related to the specific setup. So, if you run into regressions that are definitively caused by installing the new QEMU version (and not some other change), please always include the affcted VM config and some basic HW and Storage details.

Spirog · Apr 14, 2022

t.lamprecht said:
FYI: The next PVE 7.2 (2022/Q2) release will default to QEMU 6.2. Internal testing for that version started in February, and it has been made available on the pvetest repository and used for our production work loads since start of March. Besides some initial regression fixes, we saw no actual new issues coming up.

To upgrade ensure you got valid Proxmox VE repositories configured and then use the standard:

Bash:

apt update apt full-upgrade

or use the upgrade functionality of the web-interface.

pveversion -v (or the web-interface's Node Summary -> Packages versions) should then include something like pve-qemu-kvm: 6.2.0-2

Note, as with all QEMU updates: A VM needs to be either fully restarted (shutdown/start or using restart via the CLI or web-interface) or, to avoid downtime, live-migrated to an already upgraded host to actually run with the newer QEMU version.

@t.lamprecht

Do we need to update qemu-guest-agent as well on the VM's OS or does this not go hand in hand ?
just wondering if and when there is an update to newer version of qemu, if there is an extra step to upgrade the OS qemu-guest-agent as well.

I am new to Proxmox so forgive my Noob question(s)

Thanks
Kind Regards,
Spiro

t.lamprecht · Apr 14, 2022

Spirog said:
Do we need to update qemu-guest-agent as well on the VM's OSor does this not go hand in hand ?

No, the QEMU Guest Agent (QGA) and QEMU versions do not need to be strictly synced, they aren't closely coupled at all.
Older QGAs will continue to work just fine, the only thing they'll miss is fixes and possible new commands from the newer QGA release, but that's unrelated to the QEMU version the VMs are using.

Spirog · Apr 14, 2022

t.lamprecht said:
the only thing they'll miss is fixes and possible new commands from the newer QGA release, but that's unrelated to the QEMU version the VMs are using.

oh perfect, but in case we want to upgrade to newer (QGA) what would be the command for;

(AlmaLinux OS )?

and (Ubuntu OS)?

Thanks
Spiro

kofik · Apr 14, 2022

Ideally you install the package containing QGA from the repositories for your operating system. For Debian and derived distributions like Ubuntu the package is called qemu-guest-agent, and it seems for EL distributions it's the same.

While you can compile just QGA from upstream (I've done it for fun), I suggest you stick to a version shipped through your OS package repositories. Debian sometimes provides a slightly newer agent in the backports repository, that doesn't seem to be the case for Ubuntu though. But as as t.lamprecht mentioned: "Older QGAs will continue to work just fine."

Spirog · Apr 14, 2022

kofik said:
I suggest you stick to a version shipped through your OS package repositories.

Hello @kofik ,

Thanks, so it will update when the OS repository has a new update. Example

dnf update
dnf upgrade
or
apt update
apt full-upgrade
basically.

That answers my question.

thanks so much @kofik
and @t.lamprecht and the Whole ProxMox Team.

Best Regards,
Spiro

kofik · Apr 14, 2022

Spirog said:
Thanks, so it will update when the OS repository has a new update. Example

But don't be disappointed if it i.e. remains on version 6.0 as i.e. Ubuntu often keeps major version as is during the lifecycle of a major Ubuntu version and all you get is backported critical and security fixes. On the flipside you get less churn by introducing new and possibly less tested features - unless you upgrade to a new major version of Ubuntu.

EL distribution sometimes make some exemptions from that rule in parts where Red Hat / Oracle / (InsertNameHere) decide they prefer to update a component to a newer version i.e. with (usually) at a point release i.e. between RHEL 8.4 -> 8.5.

Spirog · Apr 14, 2022

t.lamprecht said:
pveversion -v (or the web-interface's Node Summary -> Packages versions) should then include something like pve-qemu-kvm: 6.2.0-2

@t.lamprecht Ok I see this now on the Node

Code:

proxmox-ve: 7.1-1 (running kernel: 5.13.19-6-pve)
pve-manager: 7.1-12 (running version: 7.1-12/b3c09de3)
pve-kernel-helper: 7.1-14
pve-kernel-5.13: 7.1-9
pve-kernel-5.4: 6.4-11
pve-kernel-5.13.19-6-pve: 5.13.19-15
pve-kernel-5.13.19-5-pve: 5.13.19-13
pve-kernel-5.13.19-2-pve: 5.13.19-4
pve-kernel-5.4.157-1-pve: 5.4.157-1
pve-kernel-5.4.73-1-pve: 5.4.73-1
ceph-fuse: 16.2.7
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: 0.8.36+pve1
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.1
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-7
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.1-5
libpve-guest-common-perl: 4.1-1
libpve-http-server-perl: 4.1-1
libpve-storage-perl: 7.1-2
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.12-1
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-2
proxmox-backup-client: 2.1.5-1
proxmox-backup-file-restore: 2.1.5-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-7
pve-cluster: 7.1-3
pve-container: 4.1-4
pve-docs: 7.1-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.3-6
pve-ha-manager: 3.3-3
pve-i18n: 2.6-2
pve-qemu-kvm: 6.2.0-2
pve-xtermjs: 4.16.0-1
qemu-server: 7.1-4
smartmontools: 7.2-pve2
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.4-pve1

t.lamprecht said:
Note, as with all QEMU updates: A VM needs to be either fully restarted (shutdown/start or using restart via the CLI or web-interface)

I did this:

Shutdown then start on all VM in the Node.

I then created a backup for each one and then when I select each VM and click (Show Configuration) for that backup
I see;
meta: creation-qemu=6.1.1,ctime=1649828545

does this mean this VM is not using latest update of qemu 6.2 ?

Code:

agent: 1,fstrim_cloned_disks=1
boot: order=scsi0;ide2;net0
cores: 20
cpu: host
ide2: local:iso/AlmaLinux-8.5-x86_64-minimal.iso,media=cdrom
memory: 48096
meta: creation-qemu=6.1.1,ctime=1649828545
name: AlmaCPwlook
net0: virtio=7A:38:4E:93:D0:58,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: l26
scsi0: local-lvm:vm-101-disk-0,discard=on,size=250G
scsihw: virtio-scsi-pci
smbios1: uuid=13a1b6f4-643a-4530-b474-ab66743b4962
sockets: 2
vmgenid: ed8f2295-ac6a-444e-81a5-6fbf92016c76
#qmdump#map:scsi0:drive-scsi0:local-lvm:raw:

Thanks
Spiro

t.lamprecht · Apr 14, 2022

Spirog said:
does this mean this VM is not using latest update of qemu 6.2 ?

No, this is just meta info about the QEMU version from the time the VM was initially created. It won't update ever after initial creation by design.

You can get the current major.minor.patch version of a running VM by navigating to the VM's Monitor panel in the web-interface and issuing a info version command there.

Spirog · Apr 14, 2022

t.lamprecht said:
ou can get the current major.minor.patch version of a running VM by navigating to the VM's Monitor panel in the web-interface and issuing a info version command there.

Ok thanks for that Excellent update went good then..

Code:

Type 'help' for help.
# info version
6.2.0pve-qemu-kvm_6.2.0

where can I find a list of commands for the Monitor panel ?
just so I can read on it and know what's available to check if ever needed.

Thanks so much you are................................. AWESOME

Kind Regards,
Spiro

Spirog · Apr 14, 2022

Spirog said:
where can I find a list of commands for the Monitor panel ?
just so I can read on it and know what's available to check if ever needed.

Disregard.... DUH Im sleepy

Code:

Type 'help' for help.

lol

ok all good thanks again

Kind Regards,
Spiro

aurantius · Apr 14, 2022

Thanks for the upgrade!

One of my virtual machines is being affected by this regression in the -acpitable option on QEMU 6.2: https://gitlab.com/qemu-project/qemu/-/issues/786

It appears to have already been fixed by upstream in 7.0, but I don't know whether the fix can be backported to 6.2.

t.lamprecht · Apr 14, 2022

aurantius said:
Thanks for the upgrade!

One of my virtual machines is being affected by this regression in the -acpitable option on QEMU 6.2: https://gitlab.com/qemu-project/qemu/-/issues/786

It appears to have already been fixed by upstream in 7.0, but I don't know whether the fix can be backported to 6.2.

Can you please post the VM config?

The fix seems relatively straight forward to backport, we'll look into it.

aurantius · Apr 14, 2022

t.lamprecht said:
Can you please post the VM config?

The fix seems relatively straight forward to backport, we'll look into it.

Sure, here's the config:

Code:

agent: 1
args: -acpitable file=/mnt/pve/local-raid-ssd/images/101/slic-table
audio0: device=ich9-intel-hda,driver=spice
bios: ovmf
boot: order=scsi0;ide0;net0
cores: 8
ide0: local:iso/virtio-win.iso,media=cdrom,size=528322K
machine: pc-q35-6.1
memory: 16384
meta: creation-qemu=6.1.1,ctime=1648844774
name: winserver
net0: virtio=62:ED:95:19:23:3B,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: win10
scsi0: local-raid-ssd:101/vm-101-disk-0.qcow2,discard=on,size=350G
scsihw: virtio-scsi-pci
smbios1: uuid=4c4c4544-0053-4d10-8044-cac04f4b3033,manufacturer=RGVsbCBJbmMu,product=UG93ZXJFZGdlIFI3NDB4ZA==,serial=SlNNREswMw==,sku=U0tVPTA3Mzc7TW9kZWxOYW1lPVBvd2VyRWRnZSBSNzQweGQ=,family=UG93ZXJFZGdl,base64=1
sockets: 1
startup: order=1
vga: vmware
vmgenid: 2870f941-9ac3-4947-9935-ad90b90cbab1

Thanks for looking into backporting the fix!

t.lamprecht · Apr 15, 2022

aurantius said:

Sure, here's the config:

Code:

agent: 1
args: -acpitable file=/mnt/pve/local-raid-ssd/images/101/slic-table
audio0: device=ich9-intel-hda,driver=spice
bios: ovmf
boot: order=scsi0;ide0;net0
cores: 8
ide0: local:iso/virtio-win.iso,media=cdrom,size=528322K
machine: pc-q35-6.1
memory: 16384
meta: creation-qemu=6.1.1,ctime=1648844774
name: winserver
net0: virtio=62:ED:95:19:23:3B,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: win10
scsi0: local-raid-ssd:101/vm-101-disk-0.qcow2,discard=on,size=350G
scsihw: virtio-scsi-pci
smbios1: uuid=4c4c4544-0053-4d10-8044-cac04f4b3033,manufacturer=RGVsbCBJbmMu,product=UG93ZXJFZGdlIFI3NDB4ZA==,serial=SlNNREswMw==,sku=U0tVPTA3Mzc7TW9kZWxOYW1lPVBvd2VyRWRnZSBSNzQweGQ=,family=UG93ZXJFZGdl,base64=1
sockets: 1
startup: order=1
vga: vmware
vmgenid: 2870f941-9ac3-4947-9935-ad90b90cbab1

Thanks for looking into backporting the fix!

Thanks, could nicely reproduce this here and with that verify that the backport then actually works. A build with that fix included is available as of now on the pvetest repository as pve-qemu-kvm version 6.2.0-3 .

aurantius · Apr 15, 2022

t.lamprecht said:
Thanks, could nicely reproduce this here and with that verify that the backport then actually works. A build with that fix included is available as of now on the pvetest repository as pve-qemu-kvm version 6.2.0-3 .

I've just upgraded to pve-qemu-kvm 6.2.0-3 and the VM starts up correctly now, thanks a lot!

Dunuin · Apr 15, 2022

I guess Q35 v6.2 still won't be usable with german Win VMs because of NIC driver errors?

Cebolix00 · Apr 15, 2022

hello cant upgrade it says

Starting system upgrade: apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

System not fully up to date (found 1 new packages)

starting shell
root@pve:/#

t.lamprecht · Apr 15, 2022

Dunuin said:
I guess Q35 v6.2 still won't be usable with german Win VMs because of NIC driver errors?

No changes there. That probably needs to be addressed by the VirtIO drivers, not QEMU.

t.lamprecht · Apr 15, 2022

Cebolix00 said:
hello cant upgrade it says

Starting system upgrade: apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

System not fully up to date (found 1 new packages)

starting shell
root@pve:/#

Please post the apt update output, you probably do not have the correct repositories configured.

QEMU 6.2 available on no-subscription as of now

Proxmox Staff Member

Member

Proxmox Staff Member

Member

Active Member

Member

Active Member

Member

Proxmox Staff Member

Member

Member

New Member

Proxmox Staff Member

New Member

Proxmox Staff Member

New Member

Distinguished Member

New Member

Proxmox Staff Member

Proxmox Staff Member