Upgraded LXC to Bullseye, Console extremely slow

[Tropaion]

Hallo,
I'm running the latest ProxMox VE7 version and now wanted to start upgrading some uncomplicated LXCs (Debian10).
I now upgraded three containers and all of them basically work, but some shell commands are extremly slow.
For example, logging in, after entering the credentials, it takes up to a minute for the login to finished.
Same with apt commands, after pressing 'Y' for installing something, it doens't show any progress, but after a while it's done.
So it looks like the LXC is doing the work in the background, but doesn't display it, or greatly delayed.

Does someone have an idea what it could be?
Thanks, Tropaion

 

[vesalius]

Hallo,
I'm running the latest ProxMox VE7 version and now wanted to start upgrading some uncomplicated LXCs (Debian10).
I now upgraded three containers and all of them basically work, but some shell commands are extremly slow.
For example, logging in, after entering the credentials, it takes up to a minute for the login to finished.
Same with apt commands, after pressing 'Y' for installing something, it doens't show any progress, but after a while it's done.
So it looks like the LXC is doing the work in the background, but doesn't display it, or greatly delayed.

Does someone have an idea what it could be?
Thanks, Tropaion

Had the same issue with my 2 Debian buster to bullseye LXC upgrades. Eventually just scrapped them and moved over to a new Debian bullseye LXC and all works well now. Would not recommend the upgrade on an LXC.

 

[Stoiko Ivanov]

So it looks like the LXC is doing the work in the background, but doesn't display it, or greatly delayed.

On a hunch is nesting enabled on those containers?
(with the newer systemd version used in debian bullseye (inside the container) nesting is needed in order for the container to run smoothly - nesting should not present a security risk for an unprivileged container)

I hope this helps!

 

[vesalius]

Nesting was not enabled on my LXC prior to the Proxmox 7 upgrade and I just checked it is automatically on the LXC I created after the upgrade. That may very well have been the issue. Did I just miss this as a recommended change for pre-existing LXC post PVE7 upgrade?

 

[Dunuin]

nesting should not present a security risk for an unprivileged container

Can you explain that? What happens if I want to upgrade a privileged Debian LXC from 10 to 11? If nesting is required but nesting isn't safe to be enabled on an privileged LXC?

 

[Tropaion]

Activating nesting helped solving my problem, thanks. Now its running smoothly. Didn't know that with the new proxmox version, enabling nesting for unprivileged containers is possible.

 

[Dunuin]

Activating nesting helped solving my problem, thanks. Now its running smoothly. Didn't know that with the new proxmox version, enabling nesting for unprivileged containers is possible.

That already worked with PVE6. Was for example needed if you wanted to run docker inside a unprivileged LXC.

 

[vesalius]

That already worked with PVE6. Was for example needed if you wanted to run docker inside a unprivileged LXC.

Yup, I knew it was possible, but was not aware it was basically now a requirement for optimum function of LXC.

 

[Stoiko Ivanov]

Can you explain that? What happens if I want to upgrade a privileged Debian LXC from 10 to 11? If nesting is required but nesting isn't safe to be enabled on an privileged LXC?

Put shortly nesting allows mounting of the hosts' /proc and /sys inside the container - unprivileged containers run in their own user namespace - thus root inside the container is only an unprivileged user on the host -> having access to /proc and /sys is acceptable
privileged containers do run as root on the host -> access to /proc and /sys can be quite problematic.

If possible in any way I'd strongly suggest to use unprivileged containers - if not - consider migrating the workload to a qemu vm
as long as the OS inside the container does not need nesting (distros not using systemd (alpine, devuan), older distros with older systemd) - a privileged container does pose less of a risk


In principle privileged containers always have been problematic from a security point of view - nesting just makes it a bit more problematic

I hope this explains it

 

[Stoiko Ivanov]

Yup, I knew it was possible, but was not aware it was basically now a requirement for optimum function of LXC.

I'd rather say, that it's a requirement for newer OS/systemd inside the container - it's not a consequence of LXC (or any other part of the hypervisor) being in a newer version