The only expression it appears in short-circuits, because the line
before ensures that $shares is guaranteed to be set.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
from qemu-server, for re-use in pve-container.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Instead, use the one from the initial configuration. The only current
caller is in PMG and the namespace parameter set there agrees with
the one from the initial configuration, so this is not actually a
breaking change.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
All existing callers for functions with namespaced parameters just
re-use the one that's passed in via the initial configuration already,
so there is no need for namespaced parameters currently.
If the need for one PBS client to handle multiple namespaces arises, a
set_namespace() function could be added, or the relevant functions
could take an additional parameter, either for just the namespace or
like $cmd_opts in restore_pxar().
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
For get_snapshots(), also set the default when no namespaced parameter
is present at all.
This would break any callers that have a namespace in the initial
config and explicitly don't set it for a later call, but the only
such caller is restore_pxar() in PMG, which /should/ be using the
namespace!
In other words, this implicitly fixes the restore_pxar() call in PMG
and avoids the need to extract the namespace from the configuration
(which already is present in the client) on the call site for all
functions that currently take a namespaced parameter.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Otherwise, there will be
Result: {
"data": null
}
when calling via a CLI tool for example. This also makes it consistent
with PVE in preparation to switch to using PBSClient there.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
It's currently possible to add a remote in PMG without password (via
API), but deletion of such a remote would fail here.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Based on a patch from Fiona[0] that proposed to move it to
guest-common, rather go for common where the CGroup module resides to
avoid having to touch multiple sites if this changes another time
(hopefully not)
[0]: https://lists.proxmox.com/pipermail/pve-devel/2022-October/054225.html
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Since even in pure unified layouts there may be a `name=systemd` v1
cgroup mounted additionally (manually or potentially via
systemd-nspawn apparently), we should check what's actually mounted
at `/sys/fs/cgroup` rather than whether v1 cgroups exist.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
this has been taken over by Proxmox::RS::Subscription, which is now used
by pve-manager and pmg-api.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
- ovsint port mtu need to be set with ""ovs-vsctl set mtu-request"
- update mtu on already existing interfaces (fwbr,fwln,tap,veth)
if existing tap|veth interface is replugged on a different mtu bridge
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Some vendors also provide a 'name' file here for the type, which, in case of
NVIDIA, is the official name for the vGPU type in their documentation,
so extract and return it too (if it exists).
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
PMG is often run as a container, and in certain environments (like
Virtuozzo 7), the last two values (guest and guest_nice) might not be
present. This led to a division by zero, because the total value was
never updated.
Reported in the community forum:
https://forum.proxmox.com/threads/106896/
Acked-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
this should fix an issue where users with custom id mappings
get bad ownership on intermediate directories caused by the
rootuid/gid being the string "100000" in perl instead of the
number 100000...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Text enclosed in unescaped curly braces will be interpreted as an
attribute reference breaking and e.g. lead to the description not
showing up at all a generated man page further down the line.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
by default, there is only one pci domain ('0000'), but there are systems
where there are more, and they don't need to be exactly 4 characters
long (see [0]), so extend that regex to allow domains 4 characters or
longer
0: https://forum.proxmox.com/threads/problem-with-gpu-passthrough-in-a-virtual-machine.105720/
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Currently, if bridge receive an unknown dest mac (network bug/attack/..),
we are flooding packets to all bridge ports.
This can waste cpu time, even more with firewall enabled.
Also, if firewall is used with reject action, the src mac of RST
packet is the original unknown dest mac.
(This can block the server at Hetzner for example)
So, we can disable learning && unicast_flood on tap|veth|fwln port interface.
Then mac address need to be add statically in bridge fdb.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
The fallback had a "typo" in the realm and used 'root@pve' (pve vs.
pam) since initial import from SVN, but off-list talks with Dietmar
suggest that 'root@pam' was always the intended fallback value.
Call sites without a defined user parameter (found only push_file and
pull_file from pve-container) were logging the task-owner user as
'root@pve' which isn't a default one, so it wouldn't exist in most
setups.
For clarity, add a comment that this is only used for the task logs.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
[ T: Reword/add to commit message slightly ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
currently these are used by qemu-server for mapping source and target
storages, but this mechanism will be extended to network bridge maps and
re-used in pve-container as well, so let's put it next to the schema
definitions/helpers.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
