usernames are allowed to start with '@', so adding a user '@test@pve'
and adding it to an ACL should work, instead of ignoring that part of
the ACL entry.
note: there is no potential for user and group to be confused, since a
username must end with '@REALM', and a group reference in an ACL can
onl
On 10/3/19 10:33 AM, Fabian Grünbichler wrote:
> usernames are allowed to start with '@', so adding a user '@test@pve'
> and adding it to an ACL should work, instead of ignoring that part of
> the ACL entry.
>
> note: there is no potential for user and group to be confused, since a
> username must
- Rename both buttons to a single word as it is clear where they belong
to. Use "Reset" instead of "Clear" as you can rather "Reset a saved
user name" than "Clear a layout".
- Use container instead of panels as they are simpler (e.g. no "border:
false" necessary) and sufficient.
- Align the b
On the one hand this introduces a new locked() mechanism allowing to enclose
locked sections in a cleaner way. There's only two types of locks namely
one for state and cron (they are always read together and almost always
written together) and one for sync.
On the other hand it improves checks rega
this will be used for vm/ct tag-lists, so that (config) management systems
or similar add additional information that does not reside in the
description
putting it here, since we want to eventually have it also for
nodes,storages,etc.
Signed-off-by: Dominik Csapak
---
src/PVE/JSONSchema.pm | 12
helpers to
* generate a color from a string consistently
* generate a html tag for a tag
* related css classes
Signed-off-by: Dominik Csapak
---
www/css/ext6-pve.css | 13 +
www/manager6/Utils.js | 34 ++
2 files changed, 47 insertions(+)
diff --git
it seems that this is not needed anymore, at least i cannot
see any difference with/without it here (chromium 76)
Signed-off-by: Dominik Csapak
---
this is necessary for the TagSelector to be shown properly in
chrome/chromium, otherwise it is only a single line
if anyone tests this and sees an e
this makes use of extjs TagField to be able to add Tags
we have to adapt some things for our custom color scheme and
list splitting behaviour
also atm, we do not preload the store so we have no tag suggestions,
this will come in a later patch, when we have a global taglist
(e.g. in the resource a
this is useful as meta information for e.g., provisioning or config
management systems
adding the info also to the 'status' api call to make it easier to show
it in the gui
Signed-off-by: Dominik Csapak
---
PVE/API2/Qemu.pm | 1 +
PVE/QemuServer.pm | 14 +-
2 files changed, 14 ins
this is useful as meta information for e.g., provisioning or config
management systems
adding the info also to the 'status' api call to make it easier to show
it in the gui
Signed-off-by: Dominik Csapak
---
src/PVE/LXC.pm| 6 ++
src/PVE/LXC/Config.pm | 9 +++--
2 files changed,
this way they are always visible when a user has selected a vm
Signed-off-by: Dominik Csapak
---
www/manager6/lxc/Config.js | 12 +---
www/manager6/qemu/Config.js | 11 +--
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/www/manager6/lxc/Config.js b/www/manager6/
this series lets users add tags to guest configs
these do not have any concrete meaning but are intended to be used
by management software such as config management systems
this is the basic implementation of this feature, in the next step
i want to do:
* get the tags in the /cluster/resources api
so that the user can edit the tags in the gui
Signed-off-by: Dominik Csapak
---
www/manager6/lxc/Options.js | 13 +
www/manager6/qemu/Options.js | 13 +
2 files changed, 26 insertions(+)
diff --git a/www/manager6/lxc/Options.js b/www/manager6/lxc/Options.js
index 234099
hi,
On Wed, Oct 02, 2019 at 01:49:23PM +0200, Fabian Grünbichler wrote:
> On September 30, 2019 2:44 pm, Oguz Bektas wrote:
> > since this method will be both used by qemu and lxc config GET calls, it
> > makes sense to move it into AbstractConfig. only difference is that qemu
> > also hides the c
On Wed, Oct 02, 2019 at 01:52:58PM +0200, Fabian Grünbichler wrote:
> On September 30, 2019 2:44 pm, Oguz Bektas wrote:
> > we don't need to extract 'delete' here, instead we pass it all as $param
> > and extract 'delete', 'revert' and most other things in
> > update_pct_config
>
> I already asked
Signed-off-by: Thomas Lamprecht
---
Note: a patch which moved this all to a submodule build similar to our other
projects was done in front of this to remove the big tarball/pathces-of-patches
PITA
...mknet-Disable-forwarding-on-shutdown.patch | 55 +
...dd-CS_PRI_NODE_ID-and-CS_PRI_RING_ID.p
To avoid hardcoding even more CPU-flag related things for custom CPU
models, introduce a dynamic approach to resolving flags.
resolve_cpu_flags takes a list of hashes (as documented in the
comment) and resolves them to a valid "-cpu" argument without
duplicates. This also helps by providing a reas
located at /usr/share/kvm/cpu-flags-understood-$arch
This file can be read by qemu-server's "query_understood_cpu_flags"
function, avoiding a more expensive call to QEMU.
For now, only x86_64 is implemented, since aarch64 doesn't print any flags when
called this way.
Signed-off-by: Stefan Reiter
Based on the RFC and following on- and off-list discussion about custom CPU
models [0].
In essence, this revised patch allows a user to specify custom CPU models in
/etc/pve/cpu-models.conf (section-config style [1]), where VMs using that CPU
model inherit details from the definition. This removes
Can be specified for a particular VM or via a custom CPU model (VM takes
precedence).
QEMU's default limit only allows up to 1TB of RAM per VM. Increasing the
physical address bits available to a VM can fix this.
Signed-off-by: Stefan Reiter
---
v2 -> v3:
* add minimum to phys-bits (8)
PVE/Q
Requires a mock CPU-model config, which is given as a raw string to also
test parsing capabilities.
Signed-off-by: Stefan Reiter
---
test/cfg2cmd/custom-cpu-model.conf | 8
test/run_config2command_tests.pl | 21 +
2 files changed, 29 insertions(+)
create mode 100
The package will be used for custom CPU models as a SectionConfig, hence
the name. For now we simply move some CPU related helper functions and
declarations over from QemuServer to reduce clutter there.
qemu_machine_feature_enabled is moved to avoid a cyclic module dependency.
Signed-off-by: Stef
$cpu_fmt is being reused for custom CPUs as well as VM-specific CPU
settings. The "pve-vm-cpu-conf" format is introduced to verify a config
specifically for use as VM-specific settings.
Signed-off-by: Stefan Reiter
---
v2 -> v3:
* move $cpu_fmt->{flags} changes here, to avoid having broken check
* query_understood_cpu_flags returns all flags that QEMU/KVM knows about
* query_supported_cpu_flags returns all flags that QEMU/KVM can use on
this particular host.
To get supported flags, a temporary VM is started with QEMU, so we can
issue the "query-cpu-model-expansion" QMP command. This is
Add two overrides to avoid writing redundant information to the config
file.
get_model_by_name is used to return a cpu config with default values
filled out.
Signed-off-by: Stefan Reiter
---
v2 -> v3:
* add validity checks to write_config
PVE/QemuServer/CPUConfig.pm | 61
pvestatd will check if the KVM version has changed using
kvm_user_version (which automatically clears its cache if QEMU/KVM
updates), and if it has, query supported CPU flags and broadcast them as
key-value pairs to the cluster.
If detection fails, we clear the kv-store and set up a delay (120s),
Turn CPUConfig into a SectionConfig with parsing/writing support for
custom CPU models. IO is handled using cfs.
The "built-in" parameter provides differentiation between custom and
default types, even if the name is the same ('namespacing').
Signed-off-by: Stefan Reiter
---
v3: I changed the "
If the "built-in" property on the cpu config is not set, try to load the
cputype from the custom CPU model config, and set values accordingly.
While at it, extract currently hardcoded values into seperate sub and add
reasonings.
Since the new flag resolving outputs flags in sorted order for
consi
On 10/3/19 4:56 PM, Stefan Reiter wrote:
> "built-in", you have to explicitly set a value in the config to 0, which looks
> weird - basically "unsetting" something to use a feature), but I'm very much
> fine with either.
but it does not really needs to be set in the config at all, or?
I mean you c
On 10/3/19 5:10 PM, Thomas Lamprecht wrote:
On 10/3/19 4:56 PM, Stefan Reiter wrote:
"built-in", you have to explicitly set a value in the config to 0, which looks
weird - basically "unsetting" something to use a feature), but I'm very much
fine with either.
but it does not really needs to be
On 10/3/19 5:19 PM, Stefan Reiter wrote:
> On 10/3/19 5:10 PM, Thomas Lamprecht wrote:
>> On 10/3/19 4:56 PM, Stefan Reiter wrote:
>>> "built-in", you have to explicitly set a value in the config to 0, which
>>> looks
>>> weird - basically "unsetting" something to use a feature), but I'm very much
On 30.08.19 17:36, Oguz Bektas wrote:
> Signed-off-by: Oguz Bektas
> ---
> Makefile | 2 +-
> debian/changelog | 6 ++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 014851c..b58177c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,5 +1
32 matches
Mail list logo
