Proxmox Virtual Environment 9.1 available!

nautilus7 said:
Plus I noticed that console is not available for such containers. Is it a bug or a feature?
Click to expand...
Currently by design, it basically shows the stdout/in of the main init process, but not buffered.
We want to explore making that output a ringbuffer, that saves the last few KiB of output and provides that as read-only view, and additionally providing shell access to the CT insides as options to improve that experience.
 
  • Like
Reactions: der_baer, lucius_the and nautilus7
t.lamprecht said:
Currently by design, it basically shows the stdout/in of the main init process, but not buffered.
We want to explore making that output a ringbuffer, that saves the last few KiB of output and provides that as read-only view, and additionally providing shell access to the CT insides as options to improve that experience.
Click to expand...
I think having a buffer of stdout is a great idea - especially if the user can specify the buffer size and there is a way to allow it to be read/processed by other containers or VMs for log review.

However - you still need some form of console access (similar to "docker exec") for troubleshooting and managing your containers. It doesn't have to be complex but it is necessary.
 
  • Like
Reactions: lucius_the and nautilus7
PigLover said:
However - you still need some form of console access (similar to "docker exec") for troubleshooting and managing your containers. It doesn't have to be complex but it is necessary.
Click to expand...
Yes, that's what I meant with:
t.lamprecht said:
additionally providing shell access to the CT insides as options to improve that experience.
Click to expand...
 
  • Like
Reactions: nautilus7
  • Like
Reactions: nautilus7
Hello!

I did create a Jackett container (https://hub.docker.com/r/linuxserver/jackett) and it is up and running!

No I'm trying to create a bazarr container (https://hub.docker.com/r/linuxserver/bazarr) and I'm receiving this error:

Code: 
Detected OCI archive
TASK ERROR: unable to create CT 6767 - Invalid argument

I tried to change some parameters but nothing has changed.

So... which "argument" is this?

Is there any log somewhere?

Thanks.
Regards.
 
What's the issue with Nvidia vGPU drivers not able to compile in 6,17 kernel? The recommendation is to use 6.14. How long before we can start using 19.,x release branch drivers with Proxmox 9.1?
 
The ChangeLog of QEMU 10.1 states

Network​


  • QEMU now attempts to arrange for larger buffers when using NBD over Unix sockets, which dramatically improves throughput. On MacOS, this works out of the box; but on Linux, the system administrator must make the following changes:

$ cat /etc/sysctl.d/net-mem-max.conf
net.core.wmem_max = 2097152
$ sudo sysctl -p /etc/sysctl.d/net-mem-max.conf
Click to expand...
Following this a relevant gain in speed is possible (for disk migrations).
Is the suggested bigger buffer part of the update or do I have to set in manually?
 
  • Like
Reactions: ebiss
Just deployed 9.1 in my staging cluster for testing. Running into odd backup behavior where I'm getting a ton of timeouts, the VM will hardlock and it takes a full reset of the VM to bring it back.

3x Nodes, Ceph, 20GB LAGG's between all. Zero issues on 8.X and 9.0.X.. So its new with 9.1. Running PBS 9.0.20 with SSD's for storage. Can go into more technical detail and specifics if needed.

Random VM's every time

INFO: 39% (49.6 GiB of 127.0 GiB) in 3m 25s, read: 222.0 MiB/s, write: 126.7 MiB/s
INFO: 40% (50.9 GiB of 127.0 GiB) in 3m 31s, read: 214.0 MiB/s, write: 92.7 MiB/s
INFO: 41% (52.2 GiB of 127.0 GiB) in 3m 35s, read: 353.0 MiB/s, write: 0 B/s
ERROR: VM 117 qmp command 'query-backup' failed - got timeout
INFO: aborting backup job
ERROR: VM 117 qmp command 'backup-cancel' failed - unable to connect to VM 117 qmp socket - timeout after 5979 retries
INFO: resuming VM again
ERROR: Backup of VM 117 failed - VM 117 qmp command 'cont' failed - unable to connect to VM 117 qmp socket - timeout after 450 retries
INFO: Failed at 2025-11-20 21:34:39
INFO: Starting Backup of VM 128 (qemu)
INFO: Backup started at 2025-11-20 21:34:39
 
PigLover said:
I think having a buffer of stdout is a great idea - especially if the user can specify the buffer size and there is a way to allow it to be read/processed by other containers or VMs for log review.

However - you still need some form of console access (similar to "docker exec") for troubleshooting and managing your containers. It doesn't have to be complex but it is necessary.
Click to expand...
Just tried it. On the host, using
Code: 
pct enter <id>
works.

Code: 
~ # pct enter 100
~ # ps aufx
PID   USER     TIME  COMMAND
    1 root      0:00 ./podinfo
   29 root      0:00 /bin/sh
   32 root      0:00 ps aufx
 
Hi,
fba said:
The ChangeLog of QEMU 10.1 states

Following this a relevant gain in speed is possible (for disk migrations).
Is the suggested bigger buffer part of the update or do I have to set in manually?
Click to expand...
manually. Currently, Proxmox VE does not modify the net.core.wmem_max setting automatically.
 
Zamana said:
Hello!

I did create a Jackett container (https://hub.docker.com/r/linuxserver/jackett) and it is up and running!

No I'm trying to create a bazarr container (https://hub.docker.com/r/linuxserver/bazarr) and I'm receiving this error:

Code: 
Detected OCI archive
TASK ERROR: unable to create CT 6767 - Invalid argument

I tried to change some parameters but nothing has changed.

So... which "argument" is this?

Is there any log somewhere?

Thanks.
Regards.
Click to expand...
I'm getting this error when trying to create a privileged container.
 
Hi,
JCNED said:
Just deployed 9.1 in my staging cluster for testing. Running into odd backup behavior where I'm getting a ton of timeouts, the VM will hardlock and it takes a full reset of the VM to bring it back.

3x Nodes, Ceph, 20GB LAGG's between all. Zero issues on 8.X and 9.0.X.. So its new with 9.1. Running PBS 9.0.20 with SSD's for storage. Can go into more technical detail and specifics if needed.

Random VM's every time

INFO: 39% (49.6 GiB of 127.0 GiB) in 3m 25s, read: 222.0 MiB/s, write: 126.7 MiB/s
INFO: 40% (50.9 GiB of 127.0 GiB) in 3m 31s, read: 214.0 MiB/s, write: 92.7 MiB/s
INFO: 41% (52.2 GiB of 127.0 GiB) in 3m 35s, read: 353.0 MiB/s, write: 0 B/s
ERROR: VM 117 qmp command 'query-backup' failed - got timeout
INFO: aborting backup job
ERROR: VM 117 qmp command 'backup-cancel' failed - unable to connect to VM 117 qmp socket - timeout after 5979 retries
INFO: resuming VM again
ERROR: Backup of VM 117 failed - VM 117 qmp command 'cont' failed - unable to connect to VM 117 qmp socket - timeout after 450 retries
INFO: Failed at 2025-11-20 21:34:39
INFO: Starting Backup of VM 128 (qemu)
INFO: Backup started at 2025-11-20 21:34:39
Click to expand...
please run apt install pve-qemu-kvm-dbgsym gdb to install debugger and debug symbols and the next time it happens, please share the output of the following commands
Code: 
qm config 117
qm status 117 --verbose
gdb --batch --ex 't a a bt' -p $(cat /var/run/qemu-server/117.pid)
using the correct ID instead of 117 each time. Any messages in the system journal around the time of the issue?
 
Is it a good idea to combine kernel 6.17.2 with ZFS 2.3.4? ZFS 2.3.4 has no official support for 6.17 kernel and ZFS 2.3.5 with 6.17 kernel support is already released.
 
Howaner said:
Is it a good idea to combine kernel 6.17.2 with ZFS 2.3.4? ZFS 2.3.4 has no official support for 6.17 kernel and ZFS 2.3.5 with 6.17 kernel support is already released.
Click to expand...

We distribute ZFS ourselves and backported the relevant patches for full compatibility with the 6.17 kernel.

So ZFS 2.3.5 would not provide any benefit here, and it was released only very recently, so including it in the release was not a possibility, especially as we do not want to release with such a freshly tagged version without significant testing and production exposure.
 
  • Like
Reactions: meyergru, morph027, Howaner and 1 other person
fiona said:
Hi,

please run apt install pve-qemu-kvm-dbgsym gdb to install debugger and debug symbols and the next time it happens, please share the output of the following commands
Code: 
qm config 117
qm status 117 --verbose
gdb --batch --ex 't a a bt' -p $(cat /var/run/qemu-server/117.pid)
using the correct ID instead of 117 each time. Any messages in the system journal around the time of the issue?
Click to expand...

Thanks! WIll do this evening off hours. Nothing in system journal that I can find, but I'll give it another glance.
 
You must log in or register to reply here.
Top Bottom