Friedrich Weber [Mon, 15 May 2023 13:08:23 +0000 (15:08 +0200)]
lxc start: warn in case of conflicting lxc.idmap entries
Users can customize the mapping between host and container uids/gids
by providing `lxc.idmap` entries in the container config. The syntax
is described in lxc.container.conf(5). One source of errors are
conflicting entries for one or more uid/gids. An example:
...
lxc.idmap: u 0 100000 65536
lxc.idmap: u 1000 1000 10
...
Assuming `root:1000:10` is correctly added to /etc/subuid, starting
the container fails with an error that is hard to interpret:
In order to simplify troubleshooting, validate the mapping before
starting the container and print a warning if a conflict is detected.
For the above mapping:
lxc.idmap: invalid map entry 'u 1000 1000 10':
container uid 1000 is also mapped by entry 'u 0 100000 65536'
The warning appears in the task log and in the output of `pct start`.
The validation subroutine considers uid and gid mappings separately.
For each of the two types, it makes one pass to detect container id
conflicts and one pass to detect host id conflicts. The subroutine
dies with the first detected conflict.
A failed validation only prints a warning instead of erroring out, to
make sure buggy (or outdated) validation logic does not prevent
containers from starting.
Note that validation does not take /etc/sub{uid,gid} into account,
which, if misconfigured, could still prevent the container from
starting with an error like
"newuidmap: uid range [1000-1010) -> [1000-1010) not allowed"
If needed, validating /etc/sub{uid,gid} could be added in the future.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Thomas Lamprecht [Wed, 26 Apr 2023 14:21:21 +0000 (16:21 +0200)]
memory: enforce memory.high also on hotplug changes
Factor out the calculation into a method to ensure it keeps in sync
and then use the newly added parameter of the change_memory_limit
PVE::CGroup method, bump the dependency in d/control respectively.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
memory: set cgroupv2 memory.high to ~99.6% of memory.max hard-limit
cgroup memory usage is limited by the hard 'max' limit (OOM-killer
enforced) and the soft 'high' limit (cgroup processes get throttled
and put under heavy reclaim pressure). Set the latter high limit to
1016/1024 (~99.2%) of the 'max' hard limit, this scales with CT
memory allocations, & gives a decent 2^x based rest for 2^y memory
config which is still quite near the upper bound – clamp the maximum
gap between high and max at 128 MiB to avoid that huge container pay
quite an high amount of absolute cost.
A few example for differences between max & high for a few mem sizes:
- 2 MiB lower for 256 MiB max
- 16 MiB lower for 2 GiB max
- 128 MiB for 16 GiB and above
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Wed, 26 Apr 2023 14:22:35 +0000 (16:22 +0200)]
setup: avoid writing truncated machine-id if it didn't exist
Allows an admin to prepare a template that will have the first-boot
condition set on first start, as we only want to disable first-boot
condition but (re)generate also a machine-id on clone if the
machine-id already exist and isn't set to "uninitialized".
Christoph Heiss [Wed, 22 Feb 2023 12:49:02 +0000 (13:49 +0100)]
net: Add `link_down` config to allow setting interfaces as disconnected
If this network option is set, the host-side link will be forced down
and the interface won't be connected to the bridge.
Add a `Disconnect` option for network interfaces on LXC containers, much
like it already exists for VMs. This has been requested in #3413 [0] and
seems useful, especially considering we already support the same thing
for VMs.
One thing to note is that LXC does not seem to support the notion of
setting an interface down. The `flags` property would suggest that this
possible [1], but AFAICS it does not work. I tried setting the value as
empty and to something else than "up" (since that is really the only
supported option [2][3]), which both had absolutely no effect.
Thus force the host-side link of the container network down and avoid
adding it to the designated bridge if the new option is set, effectively
disconnecting the container network.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com> Tested-by: Friedrich Weber <f.weber@proxmox.com>
[ T: paste cover letter as commit message ] Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Friedrich Weber [Mon, 20 Feb 2023 10:04:45 +0000 (11:04 +0100)]
fix #4470: pct fstrim: ignore bind or read-only mountpoints
Currently, `pct fstrim` will run `fstrim` on all mountpoints
of the container, including bind and read-only mountpoints.
However, trimming a bind mountpoint might trim a host
filesystem, which users may not expect. Also, trimming can
be considered a write operation, which users may not expect
to be carried out on a read-only mountpoint.
Hence, exclude bind mointpoints and read-only mountpoints
from trimming.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Friedrich Weber [Wed, 25 Jan 2023 13:07:49 +0000 (14:07 +0100)]
fix: shutdown: if lxc-stop fails, wait for socket closing with timeout
When trying to shutdown a hung container with `forceStop=0` (e.g. via
the Web UI), the shutdown task may run indefinitely while holding a lock
on the container config. The reason is that the shutdown subroutine
waits for the LXC command socket to close, even if the `lxc-stop`
command has failed due to timeout. This prevents other tasks (such as a
stop task) from acquiring the lock. In order to stop the container, the
shutdown task has to be explicitly killed first, which is inconvenient.
This occurs e.g. when trying to shutdown a hung CentOS 7 container (with
systemd <v232) in a cgroupv2 environment.
This fix imposes a timeout on the socket polling operation if the
`lxc-stop` command has failed. Behavior in case `lxc-stop` succeeds is
unchanged. This reintroduces some behavior from b1bad293. The timeout
duration is the given shutdown timeout, meaning that the final task
duration in the scenario above is twice the shutdown timeout.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Friedrich Weber [Mon, 16 Jan 2023 16:52:34 +0000 (17:52 +0100)]
fix #4460: setup: centos: create /etc/hostname if it does not exist
Previously, the CentOS setup only wrote to /etc/hostname if the file
already existed. Many CT templates of Redhat-derived distros do not
contain that file, so the containers ended up without /etc/hostname.
This caused systemd-hostnamed to report the "static hostname" to be
empty. If networking is handled by NetworkManager, the empty static
hostname caused DHCP requests to be sent without the "Hostname"
field, as reported in #4460.
With this fix, the CentOS setup module creates /etc/hostname if it
does not exist, so NetworkManager correctly reads the hostname and
includes it in DHCP requests.
Manually tested with the following CT templates (checking that
/etc/hostname exists and DHCP requests include the hostname):
- Distros using NetworkManager:
- Alma Linux 9 (almalinux-9-default_20221108_amd64.tar.xz)
- CentOS 8 (centos-8-default_20201210_amd64.tar.xz)
- CentOS 9 Stream (centos-9-stream-default_20221109_amd64.tar.xz)
- Rocky Linux 9 (rockylinux-9-default_20221109_amd64.tar.xz)
- Distros using network-scripts (here, DHCP requests already
contained the hostname without this fix, as network-scripts does
not rely on systemd-hostnamed):
- Alma Linux 8 (almalinux-8-default_20210928_amd64.tar.xz)
- CentOS 7 (centos-7-default_20190926_amd64.tar.xz)
- CentOS 8 Stream (centos-8-stream-default_20220327_amd64.tar.xz)
- Rocky Linux 8 (rockylinux-8-default_20210929_amd64.tar.xz)
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
[ T: slightly touch up of commit message format / wording ] Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
restore: also remove firewall config after failed restore
Before, a failed restore would only remove the container config, but
the firewall config would remain.
Now, the firewall config is also removed, except for the case when the
user only has the VM.Backup permission. In this case the firewall
would not have been restored/changed by us and is left as is.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
restore: clean up config when invalid source archive is given
Before, if a non-existent source archive parameter was passed when
restoring a container, the task would fail but leave an empty config
file behind. The same with invalid mount point configurations.
In both cases, the empty config will now be removed.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Thomas Lamprecht [Sun, 20 Nov 2022 15:32:04 +0000 (16:32 +0100)]
network: let the common tap-plug helper add fdb entries
Avoids trying to append some on OVS ports or the like, which won't
work with the bridge util, so let the common tap-plug helper add fdb
entries, if needed _and_ supported.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Sat, 19 Nov 2022 17:12:29 +0000 (18:12 +0100)]
setup: fix using non-plugin methods
ct_is_symlink and ct_readlink_recursive are not defined in
PVE::LXC::Setup::Plugin and thus not available for call in
PVE::LXC::Setup, thus it broke unmanaged CTs which does not descends
from the Base module, put from the abstract Plugin directly to avoid
touching its CTs at all (well, it's unmanaged)
We'd either need to add those symlink helpers to the abstract plugin
or, like we do now, add a new more general get_ct_init_path which
unmanaged can truthfully implement.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Sat, 19 Nov 2022 10:35:38 +0000 (11:35 +0100)]
fix #4355: d/control: depend on binutils to ensure objdump is available
Reported both in BZ and the forum, with the latter posting the
output of `pct start <vmid> --debug` it quickly became obvious that
we miss the binutils dependency here, maybe we can drop that in the
future again by simply parsing the ELF header in rust and use perlmod
but as stop gap for now just ensure that we actually got the tools
available we want to use..
While the template has systemd-networkd enabled, the lack of
/etc/machine-id causes systemd to revert to its "preset",
where now in
/usr/lib/systemd/system-preset/90-default.preset
fedora disables systemd-networkd in favor of NetworkManager.
Without this patch, the first boot of a fresh fedora 37
container would disable networking requiring a
`systemctl enable systemd-networkd` from within the
container once, after which it sticks around (until
/etc/machine-id is deleted).
This patch provides an
`/etc/systemd/system-preset/00-pve.preset` file to keep
systemd-networkd enabled via the `template_fixup` hook.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This patch reworks some mtu settings for LXC containers in the backend
Namely, introducing an absolute maximum for the MTU field of 65535 and
asserting that the MTU setting isn't bigger than the bridge's MTU size
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
[ T: adapt to iface learning-disable being now auto-detected ] Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
for bullseye-based systems, the 'fs.protected_regular'[0] sysctl is set
to '2' by default[1] (as opposed to the old value of '0'). this breaks
rsync's `--inplace` mode for such protected files, since opening them
with O_CREAT is not even possible for the root user anymore.
one example in the wild are debian (-based) containers using PHP, where
the session dir '/var/lib/php/sessions' is sticky, world-writable, owned
by root and contains sessions files usually owned by www-data. if any of
these session files are modified between the first and second rsync run,
the second run and thus the backup will fail.
the downside of this change is that containers with large files that are
updated between the first and second run will now see more (temp) space
usage - but suspend mode is not space efficient anyway and such setups
should consider switching to snapshot mode anyway.
additionaly, this commit drops the now no longer needed $first parameter
previously used to decide between different parameters for first and
second rsync run.
Leo Nunner [Thu, 15 Sep 2022 11:52:28 +0000 (13:52 +0200)]
fix #4192: revamp check for systemd version
Instead of iterating through several folders, it might just be easier to
check the objdump output of /sbin/init and getting the version from there.
Resolving the /sbin/init symlink happens inside the chroot, but the
objdump from the host system is used, as to not run any untrusted
executables.
Fiona Ebner [Fri, 7 Oct 2022 12:41:47 +0000 (14:41 +0200)]
api: create/update vm: clamp cpu unit value
While the clamping already happens before setting the actual
cpu.weight lxc config key, it can be done here too, to avoid writing
new out-of-range values into the config.
Can't use a validator enforcing this, because existing out-of-range
values should not become errors on parsing the config.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Fiona Ebner [Fri, 7 Oct 2022 12:41:44 +0000 (14:41 +0200)]
use helper from common for cpu units/shares
to make behavior more consistent with what we do for VMs. The helper
will clamp the value as needed, rather than dying.
Allows starting existing containers with an out-of-range (for the
relevant cgroup version) value. It's also possible to end up with
out-of-range values via update/create API.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Fiona Ebner [Fri, 7 Oct 2022 12:41:42 +0000 (14:41 +0200)]
change cpu shares: hard-code cgroupv1 default parameter
so that the description of the default can be changed to reflect that
it depends on cgroup version.
Not strictly necessary, because the function currently will ignore the
value anyways. But certainly more future-proof then starting to pass
something invalid.
Until recently perl did not care as those things are only checked
_somewhat_ on "compile" (module load) times, and the one (single?)
call site in PVE::LXC::Config missed the `use PVE::LXC` statement,
and so the module-load did not see the wrong prototype and thus did
not cared, on runtime all is different anyway (what a mess).
The recent commit 11066f6bfdca5225a6f872d5664e6637ccb58dd6 added that
use statement and made package compilation implode, almost like
spooky actions in the time-space distance...
Fixes: b2de4c048ee50094593f4f8ffd18b6c346f7157a Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Fiona Ebner [Mon, 8 Aug 2022 12:36:42 +0000 (14:36 +0200)]
apply pending mountpoint: also hotplug non-volume mount points
Previously, bind and device mount points were applied to the
configuration, but not actually hot-plugged/mounted, causing a
mismatch for running containers.
Reported in the community forum:
https://forum.proxmox.com/threads/113364/
Oguz Bektas [Tue, 19 Jul 2022 11:24:56 +0000 (13:24 +0200)]
fix #4164: use DHCP=yes instead of DHCP=both in systemd-networkd config
"both" option is deprecated, this gets rid of the warning in the journal
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
[Note: 'yes' was introduced with v219 in 2015, deprecated with v242] Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
fix: cloning a locked container creates an empty config
When an attempt was made to clone a locked container the API would
correctly present the error 'CT is locked (disk)' but create the
config files for the new container anyway.
There was also a potential problem when the config of the new ct would
already be present and the creation of the container failed. In this
case the config of the new CT would be incorrectly removed.
The config locks for the new and the old configs should now be
correctly released depending on from which call a problem originates.
Futhermore, I moved some related function calls into the eval block to
avoid similar problems with leftover config files in the future.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Dominik Csapak [Wed, 4 May 2022 08:15:02 +0000 (10:15 +0200)]
move_volume: call deactivate volume for the old volid in any case
not only when we want to remove it. Otherwise, if the old volume is
mapped (e.g. ceph krbd), we don't unmap it when we're finished.
We have to save if we deactivated successfully before attempting to
remove it. If it was not removed (either because we could not
deactivate, or the remove failed), we add it back as unused.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Dominik Csapak [Tue, 3 May 2022 09:42:26 +0000 (11:42 +0200)]
prestart & poststop hook: init REST environment, e.g. for storage activation
Initialize the basic CLI REST environment which is expected on some
PVE methods we may rely on.
This became a specific problem recently when adding better support
for external and/or multiple ceph RBD clusters on a PVE system in
commit cfe46e2d4a97a83f1bbe6ad656e6416399309ba2 from pve-storage,
which added a PVE::Rados call to get the underlying cluster FSID
required to build the /dev-mapped RBD path, and PVE::Rados
requires a initialized RPC/REST environment.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
While NixOS generally overrides any static contents in /etc/hostname
with the hostname defined in `networking.hostname`, it can use the
contents of `/etc/hostname` provided by PVE if this option is not
set.
Signed-off-by: Harikrishnan R <rharikrishnan95@gmail.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Stefan Sterz [Thu, 24 Feb 2022 14:21:50 +0000 (15:21 +0100)]
parse pct config: remove "\s*" from multi-line comment regex
To be consistent with PBS's implementation of multi-line comments
remove "\s*" here too. Since the regex isn't lazy .* matches
everything \s* would anyway. (Note that new lines occurs after "$").
projects / pve-container.git / log