--- Begin Message ---
Hi Stefan,
looks good for me so far and indeed, on very large system when VMs eat
up >2TB this could hit the limit very soon.
but shouldn't we add some newline , as the original "print sum" prints one ?
root@s740:/usr/sbin# seq 1 10 | awk '{ sum += $1 }; END { print su
--- Begin Message ---
oh, and shouldn't we also add that to total and free_memory calculation,
even chances are less that the limit is hit there ?
total=`awk '/^MemTotal:/ {print $2}' /proc/meminfo`
free_memory () {
awk '/^(MemFree|Buffers|Cached):/ {free += $2}; END {print free}' \
On Wed, Feb 28, 2024 at 08:03:08PM +0100, Stoiko Ivanov wrote:
> Thanks for the catch and fix! applied it!
Thanks!
>
> (nit: pmg-de...@list.proxmox.com is preferred for pmg-docs patches)
Saw it unfortunately only when it was already to late - sorry for the
noise!
>
> On Wed, 28 Feb 2024 19:08:2
Original patch series by Jillian Morgan
I've refrained from adding arbitrary bond names in this patch series, since
that would require a bigger amount of changes in the firewall simulator. I'll
look into adding that in a future patch series.
Changes from v2 -> v3:
* limit bridge names to 10 ch
Allow the web UI to accept bridge interfaces with any valid interface
name, rather than being limited to the arbitrary "vmbr" prefix.
Limiting to at most 10 characters, since SDN possibly adds a .
prefix for Vlans. Since the hard limit for network interface names is
15 characters, limiting it
Signed-off-by: Stefan Hanreich
---
www/manager6/sdn/zones/QinQEdit.js | 3 +++
www/manager6/sdn/zones/VlanEdit.js | 3 +++
2 files changed, 6 insertions(+)
diff --git a/www/manager6/sdn/zones/QinQEdit.js
b/www/manager6/sdn/zones/QinQEdit.js
index 795ff9dfd..de177d7cb 100644
--- a/www/manager6/s
We now allow bridges without the vmbr prefix, so we need to allow them
here in the simulator as well.
Signed-off-by: Stefan Hanreich
---
src/PVE/FirewallSimulator.pm| 29 +++--
src/PVE/Service/pve_firewall.pm | 5 +++--
2 files changed, 22 insertions(+), 12 deletions
Similar to other interface types, we can detect a bridge by the
presence of its bridge_ports attribute, rather than solely relying on
the "vmbr" ifname prefix heuristic. For OVS bridges we need to examine
the OVS type instead.
The check needs to be moved up since other prefixes could
theoretically
Signed-off-by: Stefan Hanreich
---
pve-network.adoc | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/pve-network.adoc b/pve-network.adoc
index d1ec64b..a5ad9b4 100644
--- a/pve-network.adoc
+++ b/pve-network.adoc
@@ -13,11 +13,12 @@ page contains the complete fo
Signed-off-by: Stefan Hanreich
---
www/manager6/sdn/zones/VlanEdit.js | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/www/manager6/sdn/zones/VlanEdit.js
b/www/manager6/sdn/zones/VlanEdit.js
index 7f7ccca41..0bef5c8ec 100644
--- a/www/manager6/sdn/zones/VlanEdit.js
+++
Signed-off-by: Stoiko Ivanov
---
tested with the packages from our internal repository yesterday evening
all looked ok.
debian-12-bookworm-pmg-8-64/dab.conf | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/debian-12-bookworm-pmg-8-64/dab.conf
b/debian-12-bookworm-pmg-8-
--- Begin Message ---
On Fri, Feb 23, 2024 at 10:24:36AM +0100, Roland Kammerer wrote:
> This passes the well known $scfg to parse_volname and bumps the API
> versions accordingly. This allows plugins to access their configuration
> if necessary.
Hi devs,
just a ping as this did not get any feedb
Am 23.02.24 um 10:24 schrieb Roland Kammerer:
> This passes the well known $scfg to parse_volname and bumps the API
> versions accordingly. This allows plugins to access their configuration
> if necessary.
>
Hi,
can you please describe your use case in more detail? Why does parsing
the volume nam
--- Begin Message ---
On Thu, Feb 29, 2024 at 02:29:51PM +0100, Fiona Ebner wrote:
> Am 23.02.24 um 10:24 schrieb Roland Kammerer:
> > This passes the well known $scfg to parse_volname and bumps the API
> > versions accordingly. This allows plugins to access their configuration
> > if necessary.
>
Roland writes:
> oh, and shouldn't we also add that to total and free_memory calculation,
> even chances are less that the limit is hit there ?
>
> total=`awk '/^MemTotal:/ {print $2}' /proc/meminfo`
>
> free_memory () {
> awk '/^(MemFree|Buffers|Cached):/ {free += $2}; END {print free}' \
>
Roland writes:
> oh, and shouldn't we also add that to total and free_memory calculation,
> even chances are less that the limit is hit there ?
>
> total=`awk '/^MemTotal:/ {print $2}' /proc/meminfo`
total does not require the printf fix because it does not do any
calculation.
The "print $2" ope
Roland writes:
> Hi Stefan,
>
> looks good for me so far and indeed, on very large system when VMs eat
> up >2TB this could hit the limit very soon.
>
> but shouldn't we add some newline , as the original "print sum" prints one ?
>
> root@s740:/usr/sbin# seq 1 10 | awk '{ sum += $1 }; END { p
--- Begin Message ---
FWIW, depending on how the sum is used it might actually make even more
sense to use PSS, i.e., the proportional set size which better accounts
for shared memory by dividing that part between all its users, as if
e.g. 10 QEMU processes have 100 MB of shared code and what not
18 matches
Mail list logo
