This patch partially reverts commit 1b5706cd168fedc5e494e24300069ee4ff25761f,
by reintroducing the old format for return values (key, value, pending,
delete), but drops the "force-delete" return value. Right now, this
endpoint does not conform to its own format, because the return values
are as fol
--- Begin Message ---
No, this dataset not added as “dir” - it’s mounted as ZFS filesystem inside
container so it’s not a file. And about proxmox provided zfs backend - I
understand that it’s better to just use existing option, but there is use cases
where existing mechanism isn’t usable - for e
> As we know, ProxMox have only three possible "categories" of mount points:
> ProxMox storage provider supplied, block device and bind mount. I've prepared
> a little patch for pve-container package which adds a fourth "category" named
> "zfs" - so with this patch it's possible to add such ZFS
For nodes, VMs and CTs we can show the user a list of available network
interfaces (as that information is available) when creating a new
firewall rule, much like it is already done in similar places.
Adds a lot of convenience when creating new firewall rules if they are
interface-specific, as you
This makes it optional to specify a specific type of bridge/network and
renames the component to `NetworkInterfaceSelector`, to better fit it's
new role.
Allows reusing the component in other places, where the user should be
presented a choice of e.g. all available network interfaces on a node.
N
For nodes, VMs and CTs we can show the user a list of available network
interfaces (as that information is available) when creating a new
firewall rule, much like it is already done in similar places.
Adds a lot of convenience when creating new firewall rules if they are
interface-specific, as you
This series introduces basic cloudinit support for containers. All in
all, it works quite similar to VMs, with the caveat that we only allow
network configuration through the alrady existing systems, and not via
cloud-init.
These patches should still be seen as WIP, but they are in a workable
stat
Signed-off-by: Leo Nunner
---
www/manager6/qemu/CloudInit.js | 4 ++--
www/manager6/qemu/Config.js| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/www/manager6/qemu/CloudInit.js b/www/manager6/qemu/CloudInit.js
index 77ff93d4..14117ff6 100644
--- a/www/manager6/qemu/Clou
The code to generate the actual configuration works pretty much the same
as with the VM system. We generate an instance ID by hashing the user
configuration, causing cloud-init to run every time said configuration
changes.
Instead of creating a config drive, we write files directly into the
volume
Introduce a 'pct cloudinit dump ' command to dump the
generated cloudinit configuration for a section.
Signed-off-by: Leo Nunner
---
src/PVE/API2/LXC.pm | 33 +
src/PVE/CLI/pct.pm | 4
src/PVE/LXC/Cloudinit.pm | 11 +++
3 files changed, 4
Introduce configuration parameters for cloud-init. Like with VMs, it's
possible to specify:
- user
- password
- ssh keys
- enable/disable updates on first boot
It's also possible to pass through custom config files for the user and
vendor settings. We don't allow configuring the ne
based on the already existing panel for VMs. Some things have been
changed, there is no network configuration, and a separate "enable"
options toggles cloud-init (simillar to adding/removing a cloud-init
drive for VMs).
Signed-off-by: Leo Nunner
---
www/manager6/Makefile | 1 +
www/man
thanks for your feedback @fabian, @wolfgang!
so the consensus seems to be to simply expose the array in the api schema and
always have the client send the whole array over, like in pbs updater
(not a problem for my series, since in the gui we have the whole info anyway,
also if one want a custom
There is no 'smm' flag for the 'virt' machine type.
Signed-off-by: Fiona Ebner
---
PVE/QemuServer.pm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index c1d0fd2d..ab33aa37 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@
> Konstantin hat am 11.05.2023 13:56 CEST geschrieben:
>
>
> Hello,
> > nit: for single patches, there is no need to add a coverletter. also,
> > please include relevant information in the commit message!
> I'm new here, so sorry - will follow rules in future.
no worries! check out https://pve
for convenience. These options do not influence the QEMU instance
directly, but are only used for migration, so no need to keep them in
pending.
Signed-off-by: Fiona Ebner
---
PVE/QemuServer.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 4f34
Signed-off-by: Fiona Ebner
---
PVE/QemuServer.pm | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index c1d0fd2d..4f3418ae 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -4906,16 +4906,16 @@ sub foreach_volid {
}
my $
17 matches
Mail list logo
