Oguz Bektas [Tue, 6 Apr 2021 11:56:16 +0000 (13:56 +0200)]
pct: fix edge case for 'pct push' with root uid/gid
we should check if the variable is defined in the end (because root
uid:gid is 0:0, this causes perl to get confused and die, eventhough the
uid:gid was obtained correctly)
Fabian Ebner [Thu, 11 Mar 2021 10:26:50 +0000 (11:26 +0100)]
vmstatus: make lock property optional again
Commit d02262048cbbe91ca8b12f98e3dc7bbab28e4c64 made the property de-facto
non-optional. Partially revert this and instead adapt the printing, making the
behavior match the API description again. The conditional assignment is
already there further down the vmstatus function.
Fabian Ebner [Thu, 11 Mar 2021 10:26:49 +0000 (11:26 +0100)]
config: parse: also allow empty values
because they are valid for '-list' formats and it makes the behavior match with
what we do for VM configs. The new pattern is the same that is used for VM
configs. Because it is a non-greedy pattern, trailing whitespaces will not be
included in the value anymore. This /should/ cause no problems and the '\s*$'
at the end suggests that that is how it was intended in the first place.
Oguz Bektas [Thu, 25 Feb 2021 14:11:16 +0000 (15:11 +0100)]
fix #3313: restore: keep unprivileged status from archive config
Since pct defaults to privileged containers, it restores the
container as privileged when `--unprivileged 1` is not passed.
Instead we should check the old configuration and retrieve it from
there.
This way, when one creates an unprivileged container, it will be
still be unprivileged after restore, if not overwritten by API
arguments.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Making the CT and VM API more stream lined. But, we do not use the
same dangerous default than the VM API does, as we only have it there
for backward compatibility.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Mon, 25 Jan 2021 19:15:24 +0000 (20:15 +0100)]
mkfs: make less noisy
Easiest and cleanest would be to pass the -q quiet parameter, but
that drops also possible relevant information when rescuing such a
filesystem (super block backup positions, UUID, ...)
Will let thorugh something like:
> Creating filesystem with 262144 4k blocks and 65536 inodes
> Filesystem UUID: 3a6f3548-baf6-45fa-93d2-b61212668d23
> Superblock backups stored on blocks:
> 32768, 98304, 163840, 229376
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Fabian Ebner [Fri, 20 Nov 2020 14:50:45 +0000 (15:50 +0100)]
vzdump: pass along exclude patterns to proxmox-backup-client
to make the behavior consistent across modes.
Previously vzdump's exclude-path option only had an effect for suspend mode
backups, as then the exclusion already happens when rsync copies the data
during an earlier stage in the backup.
Fabian Ebner [Fri, 20 Nov 2020 14:50:44 +0000 (15:50 +0100)]
vzdump: allow relative exclude patterns for snapshot and stop mode
to make the behavior consistent across modes.
For suspend mode, relative patterns worked for a long time, because the
exclusion already happens when rsync copies the data during an earlier stage of
the backup.
For the other two methods, the way the patterns are passed to tar (after the
'--anchored' option and prefixed with a dot) meant that relative patterns
had no effect previously.
Users which have a relative exclude path by accident (if it's not by accident
then this fixes the behavior) and did not use suspend mode (if they did use
suspend mode, they hopefully would have noticed the unintended exclusion then)
will be affected by this change.
Stoiko Ivanov [Mon, 23 Nov 2020 10:12:29 +0000 (11:12 +0100)]
fix #3161: snapshot creation: only check volumes for fsfreeze
When considering mountpoints for running 'fsfreeze' before snapshot
creation, commit 8463099d99273561c46398bf02206b4d9d431bc5 did not
only consider volumes created by our storage-stack, but also
bindmounts and devmounts (directly mounting a blockdevice).
This led to PVE::Storage::parse_volume_id failing on those
mountpoints.
Since the fsfreeze call is best-effort and only run for specific
storageplugins, we can simply skip non-volume mountpoints, when
gathering the list of volumes to call fsfreeze on.
Stoiko Ivanov [Fri, 6 Nov 2020 14:19:42 +0000 (15:19 +0100)]
snapshot creation: fsfreeze mountpoints, if needed
fixes #2991, #2528.
creating a snapshot with rbd, after the syncfs finished successfully does not
guarantee that the snapshot has the state of the filesystem after syncfs.
suggestion taken from #2528 (running fsfreeze -f/-u before snapshotting on
the mountpoints)
added helper PVE::Storage::volume_snapshot_needs_fsfreeze, to indicate
which volumes need to be frozen/thawed. (and mocked it in the tests here).
Added the freeze to sync_container_namespace, since it needs to run inside the
container's mount namespace.
unfreezing happens in a sub of its own.
tests in #2991 seem to indicate that this helps to successfully create backups.
Stoiko Ivanov [Fri, 6 Nov 2020 14:19:41 +0000 (15:19 +0100)]
add fsfreeze helper:
fsfreeze_mountpoint issues the same ioctls as fsfreeze(8) on the provided
directory (the $thaw parameter deciding between '--freeze' and '--unfreeze')
This is used for container backups on RBD, where snapshots on containers,
which are heavy on IO, are not mountable readonly, because the ext4 is not
consistent.
Needed to fix #2991 and #2528.
The ioctl numbers were found via strace -X verbose (and verified with the
kernel documentation).
setup: heuristically warn if the FS hosting /etc is not mounted
Check for the existence of /etc, use -e as it could also be a symlink
(and it's just a heuristic). But only do so if the expected ostype
from the config does not match the detected one, this normally
indicates that we had a "reals" distro running but detected the
fallback "unmanaged". Only warn though, as a hint for the user.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
alpine: setup net: pass whole config to parent method
We expected the whole $conf to be passed in a call to setup_network,
a bit ago it worked if their where only the netX keys present, for
some plugin that still is the case.
But, in the Debian version, reused by Alpine, we now check if the CT
distro version is recent enough to support (or need) the address in
CIDR format.
So, at least "ostype" needs to be passed to, else we get ugly
warnings in the syslog (or the recently added --debug log CLI switch)
Just pass the whole config, the setup_network method need to cope
with that anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
commit 797e12e8a5df246d8afc53b045e632977cdf0088 got rid of our "just
bind-mount the root /dev to the CT temporarily for some stuff" for
good a while ago (2015), but creating the /dev directory in the CT
root was kept, from what I can tell, by mistake.
This can be a problem if, whyever, the CT rootfs is not mounted, as
we then break a future mount as we create this /dev directory inside
what would be the CTs rootfs mount point. It is then not empty
anymore and a normal mount cannot happen, failing with "directory is
not empty"
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Since it was necessary to switch to 'Type=Simple' in the systemd
service, see 545d6f0a13ac2bf3a8d3f224c19c0e0def12116d,
'systemctl start' would not wait for the 'lxc-start' command anymore.
Thus every container start was reported as a success and the 'post-start'
hook would trigger immediately after the 'systemctl start' command.
Use the monitor socket to get the necessary information and detect
startup failure, and only run the 'post-start' hookscript after
the container is effectively running. If something goes wrong
with the monitor socket, for example if lxc-monitord is not running,
fall back to the old behavior.
currently all volumes for a container are activated in the pre-start hook,
which runs in a separate mount namespace (lxc.monitor.unshare is set to 1
in our container config). This leads to problems with ZFS:
* if a pool is imported by this call the filesystems are mounted only inside
the containers mount namespace
by running the volume activation inside vm_start, right before starting the
container via systemctl the volume activation happens before the unshare.
The other site where a container is started via systemctl is in
'pve-container-stop-wrapper' when a container is rebooted from the inside:
By activating the volumes in 'lxc-pve-poststop-hook' we avoid to try starting
a container with an inactive volume (LVM, kRBD), occuring when having a
mp-addtion pending during such a reboot
Starting a container manually using lxc-start is usually done for obtaining
debug-logs (after starting failed with our tooling) - so the potential for
regression in that case should also be small.
Thomas Lamprecht [Mon, 13 Jul 2020 16:07:33 +0000 (18:07 +0200)]
vzdump: rsync: make less verbose
most of that info we get is just plain noise, which adds 15 lines per
sync, so 30 total! Instead just pull out the total transfer info,
i.e., the delta which should be full CT size in the first sync and
the dirty delta in the second.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Oguz Bektas [Thu, 2 Jul 2020 10:10:23 +0000 (12:10 +0200)]
fix #2820: don't hotplug over existing mpX
check if the given mpX already exists in the config. if it does, then
skip hotplugging and write the changes to [pve:pending] for the next
reboot of CT.
after rebooting the CT, the preexisting mpX will be added as unused and
the mpX will be mounted.
starting with version 0.8.35 of ifupdown (shipped currently with buster)
the configuration using a separate 'netmask' line instead of providing the
cidr in the 'address' line of a interface stanza of /etc/network/interfaces
is deprecated.
This means that some software installed on newer debian versions, which
parses /etc/network/interfaces may not support the format currently written
by PVE::LXC::Setup::Debian::setup_network.
This patch changes the content of the generated file to use the newer format
only for newer versions of debian (alpine, older ubuntu versions and devuan
also rely on the sub to generate the network config)
caught by installing proxmox-backup-server on a debian buster container and
getting a parse-error in the network configuration tab in the GUI.
tested by creating a ubuntu-14.04, debian-6, debian-8 and a debian-10
container and checking the resulting /etc/network/interfaces.
The stop-mode case only worked by luck as then $snapdir == $rootdir.
But for snapshots we rsync over a clean state to a separate
directory, so this has to be used as base for the backup (just like
tar does).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Aaron Lauterer [Mon, 22 Jun 2020 14:34:38 +0000 (16:34 +0200)]
vzdump: move include logic for mountpoints to method
Move the logic which mountpoints are included in the backup job to its
own method and adapt the VZDump code accordingly. This makes it possible
to develop other features around backup jobs.
Oguz Bektas [Thu, 18 Jun 2020 14:42:55 +0000 (16:42 +0200)]
fix #2778: use vm_start instead of systemctl to start/restart container
when a backup task in 'stop' mode is executed, VZDump calls 'start_vm'
sub instead of 'PVE::LXC::vm_start'.
'start_vm' however does not follow our regular process but instead uses
systemctl to start the container, which results in the guest hookscripts
not being executed in 'pre-start' and 'post-start'.
to call the hooks correctly we can just make use of the
PVE::LXC::vm_start routine which already handles them.
Arnout Engelen [Thu, 28 May 2020 20:18:46 +0000 (20:18 +0000)]
lxc: fall back to 'unmanaged' when no OS detected
This is useful when the uploaded CT does not contain a full OS. When the
autodetection detects an OS, that OS is returned. When it does not
successfully detect a supported OS, but /etc/os-release exists and has an ID
other than 'unmanaged', then the setup fails.
projects / pve-container.git / log