The new MTU field and the rate limit field are now in the advanced
section of the NetworkInputPanel to parallel the layout of the
NetworkEdit for VMs.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Reviewed-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
The option to set the mtu parameter for lxc containers already exists
in the backend. It just has to be exposed in the web UI as well.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Reviewed-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
we already have the 'mtu' option in the API, so we can just expose
that option inside the 'Advanced' menu for virtio network interfaces.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Moved the message tooltip below the advanced columns to avoid the line
break and make it more visually pleasing.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Since all tasks succeeded, previously no mail was sent in that case.
Note that the error passed to $self->sendmail() is added to the
subject of the mail if it is a single line or the beginning of the
mail otherwise. Thus changing the mail slightly compared to previously
for the case where the job-start hook fails and the case where the
job-end hook fails with mailnotification=always. But can be considered
an improvement, because the user sees the error right away.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
When the mode changes, we set the pool selector visible/hidden, but
we never disabled/enabled it. This tripped up the dirty state of the
form always showing the reset button as enabled.
Properly enabling and disabling the pool field fixes the dirty state
tracking.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
so that the default value and limits actually correspond to what will
be used. Defaults to values for cgroup v2, because that is the more
common scenario.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
so the frontend has the information readily available.
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Planned to be used for static resource scheduling in the HA manager.
It's enough to broadcast the values whenever they are outdated or not
set in the node's local kv store, because pmxcfs will re-broadcast the
local kv store whenever the quorate partition changes. This is already
relied upon for the 'ceph-versions' kv pair.
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
for backwards compatibility. Otherwise, e.g. listing backup jobs with
pvesh get /cluster/backup is broken. And suddenly not having the
property anymore would be a breaking API change.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
previously the widget toolkit was not scanned when creating the
mapping between `onlineHelp` keys and pve-doc anchors. this could
lead to cases where help buttons didn't work because the necessary
mapping wasn't present in `OnlineHelpInfo.js`.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
we may want to even do this only once, before the loop, but for now
this is basically the same as it was previously but avoids the need
for every (future) plugin to do this manually; which is just the
wrong place.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
in the backend, we allow up to 14 usb ports, but only if the vm can
use the qemu-xhci controller which is only possible since machine
version 7.1 and if the ostype is l26 or windows > 7
for this we introduce two helpers:
* qemu_min_version: modeled after the signature of 'min_version' from
qemu-server, expects two arrays of versions and returns true if
the first parameter is equal or greater than the second version
* get_max_usb_count looks at the given ostype and machine string
and returns the proper maximum number
since we don't currently have the actual running version of the vm in
the gui, this is only a heuristic for running vms. but since the actual
running version could only be lower if none is set (e.g. for
migrated/long-running vms) we allow more in the gui and the backend will
do the proper thing (either hotplug it, or make it a pending change)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Now that the pvemailforward binary was dropped, there is a lintian
warning that it's not defined anymore.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
proxmox-mail-forward is a new helper binary in Rust intended to behave
essentially the same on PVE installations. It can also handle mixed
PBS+PVE installations.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Existing disks are not changed by this.
Especially in benchmarks, iothreads significantly improve IO performance.
Signed-off-by: Matthias Heiserer <m.heiserer@proxmox.com>
by adding the javascript files as prerequisites, the
`OnlineHelpInfo.js` will get re-generated if a new `onlineHelp` key
is used. thus, this avoids an issue were valid keys might not get
mapped correctly because the info in `OnlineHelpInfo.js` wasn't
updated.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
This makes it slightly clearer that it's a default value (not being
written to the config explicitly). It's also in preparation to bind
the default based on the cgroup version, where it's a bit nicer to
bind the emptyText instead of the value (or a user set value would be
overwritten when the binding updates).
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
For lxc, commit 53395db1 ("lxc/ResoureEdit: move some cpu fields to
advanced options") made the fields available in the create wizard, so
the comment is also wrong.
Both wizards do a 'delete kv.delete' in their onSubmit() function, so
it didn't actually matter in practice.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Commit bf96f60d ("use IntegerField from widget toolkit") switched to
using an Promxox IntegerField with 'deleteEmpty: true'. This means
that a value of '' already is removed from 'values' and added to
'delete' before onGetValues() is called here.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
One could also think about showing something like '% of N CPUs', but
this can be inaccurate for older data, because the number of CPUs can
change.
Reported in the community forum:
https://forum.proxmox.com/threads/117362/
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
