Re: [pve-devel] [PATCH ksm-control-daemon] ksmtuned: fix large number processing
--- 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 sum }'
5.5e+09
root@s740:/usr/sbin# seq 1 10 | awk '{ sum += $1 }; END { printf
("%.0f", sum) }'
55root@s740:/usr/sbin#
# seq 1 10 | awk '{ sum += $1 }; END { print sum }'|xxd
: 352e 3030 3030 3565 2b30 390a 5.5e+09.
# seq 1 10 | awk '{ sum += $1 }; END { printf ("%.0f", sum) }' |xxd
: 3530 3030 3035 3030 3030 55
# seq 1 10 | awk '{ sum += $1 }; END { printf ("%.0f\n", sum) }' |xxd
: 3530 3030 3035 3030 3030 0a 55.
regards
Roland
Am 25.01.24 um 11:56 schrieb Stefan Lendl:
awk internally uses float for every calculation, printing a large float
with awk results in 1.233e+09 format which causes the script to fail afterwards.
Instead I am printing the float without decimals.
Signed-off-by: Stefan Lendl
---
debian/patches/awk-printf.diff | 16
debian/patches/series | 1 +
2 files changed, 17 insertions(+)
create mode 100644 debian/patches/awk-printf.diff
diff --git a/debian/patches/awk-printf.diff b/debian/patches/awk-printf.diff
new file mode 100644
index 000..11a957f
--- /dev/null
+++ b/debian/patches/awk-printf.diff
@@ -0,0 +1,16 @@
+--- ksm-control-scripts/ksmtuned 2024-01-25 11:33:03.485039813 +0100
ksm-control-scripts.new/ksmtuned 2024-01-25 11:37:40.544751316 +0100
+@@ -72,11 +72,11 @@
+ # calculate how much memory is committed to running qemu processes
+ local progname
+ progname=${1:-kvm}
+-ps -C "$progname" -o vsz= | awk '{ sum += $1 }; END { print sum }'
++ps -C "$progname" -o vsz= | awk '{ sum += $1 }; END { printf ("%.0f",
sum) }'
+ }
+
+ free_memory () {
+-awk '/^(MemFree|Buffers|Cached):/ {free += $2}; END {print free}' \
++awk '/^(MemFree|Buffers|Cached):/ {free += $2}; END { printf ("%.0f",
free) }' \
+ /proc/meminfo
+ }
+
diff --git a/debian/patches/series b/debian/patches/series
index 7aaec2c..63aba40 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ init-script.diff
ksmtuned.diff
adjust-ksm-slepp.diff
use-vsz-instead-of-rsz.diff
+awk-printf.diff
--- End Message ---
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH ksm-control-daemon] ksmtuned: fix large number processing
--- 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}' \
/proc/meminfo
}
Am 25.01.24 um 11:56 schrieb Stefan Lendl:
awk internally uses float for every calculation, printing a large float
with awk results in 1.233e+09 format which causes the script to fail afterwards.
Instead I am printing the float without decimals.
Signed-off-by: Stefan Lendl
---
debian/patches/awk-printf.diff | 16
debian/patches/series | 1 +
2 files changed, 17 insertions(+)
create mode 100644 debian/patches/awk-printf.diff
diff --git a/debian/patches/awk-printf.diff b/debian/patches/awk-printf.diff
new file mode 100644
index 000..11a957f
--- /dev/null
+++ b/debian/patches/awk-printf.diff
@@ -0,0 +1,16 @@
+--- ksm-control-scripts/ksmtuned 2024-01-25 11:33:03.485039813 +0100
ksm-control-scripts.new/ksmtuned 2024-01-25 11:37:40.544751316 +0100
+@@ -72,11 +72,11 @@
+ # calculate how much memory is committed to running qemu processes
+ local progname
+ progname=${1:-kvm}
+-ps -C "$progname" -o vsz= | awk '{ sum += $1 }; END { print sum }'
++ps -C "$progname" -o vsz= | awk '{ sum += $1 }; END { printf ("%.0f",
sum) }'
+ }
+
+ free_memory () {
+-awk '/^(MemFree|Buffers|Cached):/ {free += $2}; END {print free}' \
++awk '/^(MemFree|Buffers|Cached):/ {free += $2}; END { printf ("%.0f",
free) }' \
+ /proc/meminfo
+ }
+
diff --git a/debian/patches/series b/debian/patches/series
index 7aaec2c..63aba40 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ init-script.diff
ksmtuned.diff
adjust-ksm-slepp.diff
use-vsz-instead-of-rsz.diff
+awk-printf.diff
--- End Message ---
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] applied: [PATCH pmg-docs] installation: fix codeblock rendering in zfs performance tips section
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:21 +0100
> Christoph Heiss wrote:
>
> > That slipped through, asciidoc uses 4 not 3 dashes for that.
> >
> > Fixes: c8be3f0 ("installation: align zfs performance tip with PVE
> > documentation")
> > Signed-off-by: Christoph Heiss
> > ---
> > pmg-installation.adoc | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/pmg-installation.adoc b/pmg-installation.adoc
> > index 326fe5b..25d16a7 100644
> > --- a/pmg-installation.adoc
> > +++ b/pmg-installation.adoc
> > @@ -284,9 +284,9 @@ ZFS can use a dedicated drive as write cache, called
> > the ZFS Intent Log (ZIL).
> > Use a fast drive (SSD) for it. It can be added after installation with the
> > following command:
> >
> >
> > +
> > # zpool add log
> >
> > +
> >
> > Adding the `nomodeset` Kernel Parameter
> > ~
>
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 common/docs/widget-toolkit/manager/firewall 0/6] drop vmbr prefix for bridges
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 characters in Web UI * introduce common variable for bridge names in firewall simulator * update docs to reflect changes * add warning for interfaces named vmbrX that are not bridges Changes from v1 -> v2: * limit name to 15 characters * properly validate bridge names in vlan/qinq zones * properly handle OVS bridges * handle new bridge names in firewall simulator common: Stefan Hanreich (1): interfaces: allow arbitrary bridge names in network config src/PVE/INotify.pm | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-) docs: Stefan Hanreich (1): network: update specification for bridge names pve-network.adoc | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) widget-toolkit: Stefan Hanreich (1): network: allow bridges to have any valid interface name src/Toolkit.js | 4 ++-- src/node/NetworkEdit.js | 4 +++- 2 files changed, 5 insertions(+), 3 deletions(-) manager: Stefan Hanreich (2): sdn: qinq: vlan: properly validate bridge name sdn: vlan: fix indentation in vlan edit dialogue www/manager6/sdn/zones/QinQEdit.js | 3 +++ www/manager6/sdn/zones/VlanEdit.js | 11 +++ 2 files changed, 10 insertions(+), 4 deletions(-) firewall: Stefan Hanreich (1): simulator: use new bridge naming scheme src/PVE/FirewallSimulator.pm| 29 +++-- src/PVE/Service/pve_firewall.pm | 5 +++-- 2 files changed, 22 insertions(+), 12 deletions(-) Summary over all repositories: 8 files changed, 61 insertions(+), 38 deletions(-) -- murpp v0.4.0 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 widget-toolkit 3/6] network: allow bridges to have any valid interface name
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 to 10 characters here enables SDN to append
the VLAN prefix in any case.
Originally-by: Jillian Morgan
Signed-off-by: Stefan Hanreich
---
src/Toolkit.js | 4 ++--
src/node/NetworkEdit.js | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/Toolkit.js b/src/Toolkit.js
index 6fd73f5..23d3a36 100644
--- a/src/Toolkit.js
+++ b/src/Toolkit.js
@@ -76,7 +76,7 @@ Ext.apply(Ext.form.field.VTypes, {
MacPrefixText: gettext('Example') + ': 02:8f - ' + gettext('only unicast
addresses are allowed'),
BridgeName: function(v) {
- return (/^vmbr\d{1,4}$/).test(v);
+ return (/^[a-zA-Z][a-zA-Z0-9_]{0,9}$/).test(v);
},
VlanName: function(v) {
if (Proxmox.Utils.VlanInterface_match.test(v)) {
@@ -86,7 +86,7 @@ Ext.apply(Ext.form.field.VTypes, {
}
return true;
},
-BridgeNameText: gettext('Format') + ': vmbrN, where 0 <= N
<= ',
+BridgeNameText: gettext('Format') + ': alphanumeric string starting with a
character',
BondName: function(v) {
return (/^bond\d{1,4}$/).test(v);
diff --git a/src/node/NetworkEdit.js b/src/node/NetworkEdit.js
index bb9add3..33113d9 100644
--- a/src/node/NetworkEdit.js
+++ b/src/node/NetworkEdit.js
@@ -38,6 +38,8 @@ Ext.define('Proxmox.node.NetworkEdit', {
throw "unknown network device type specified";
}
+ let name_max_length = iface_vtype === 'BridgeName' ? 10 : 15;
+
me.subject = Proxmox.Utils.render_network_iface_type(me.iftype);
let column1 = [],
@@ -254,7 +256,7 @@ Ext.define('Proxmox.node.NetworkEdit', {
value: me.iface,
vtype: iface_vtype,
allowBlank: false,
- maxLength: 15,
+ maxLength: name_max_length,
autoEl: {
tag: 'div',
'data-qtip': gettext('For example, vmbr0.100, vmbr0,
vlan0.100, vlan0'),
--
2.39.2
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 manager 4/6] sdn: qinq: vlan: properly validate bridge name
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/sdn/zones/QinQEdit.js
+++ b/www/manager6/sdn/zones/QinQEdit.js
@@ -24,6 +24,9 @@ Ext.define('PVE.sdn.zones.QinQInputPanel', {
name: 'bridge',
fieldLabel: 'Bridge',
allowBlank: false,
+ vtype: 'BridgeName',
+ minLength: 1,
+ maxLength: 10,
},
{
xtype: 'proxmoxintegerfield',
diff --git a/www/manager6/sdn/zones/VlanEdit.js
b/www/manager6/sdn/zones/VlanEdit.js
index 23530bfcf..7f7ccca41 100644
--- a/www/manager6/sdn/zones/VlanEdit.js
+++ b/www/manager6/sdn/zones/VlanEdit.js
@@ -24,6 +24,9 @@ Ext.define('PVE.sdn.zones.VlanInputPanel', {
name: 'bridge',
fieldLabel: 'Bridge',
allowBlank: false,
+ vtype: 'BridgeName',
+ minLength: 1,
+ maxLength: 10,
},
];
--
2.39.2
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 firewall 6/6] simulator: use new bridge naming scheme
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(-)
diff --git a/src/PVE/FirewallSimulator.pm b/src/PVE/FirewallSimulator.pm
index 140c46e..fa5ed0e 100644
--- a/src/PVE/FirewallSimulator.pm
+++ b/src/PVE/FirewallSimulator.pm
@@ -7,6 +7,12 @@ use PVE::Firewall;
use File::Basename;
use Net::IP;
+use base 'Exporter';
+our @EXPORT_OK = qw(
+$bridge_name_pattern
+$bridge_interface_pattern
+);
+
# dynamically include PVE::QemuServer and PVE::LXC
# to avoid dependency problems
my $have_qemu_server;
@@ -27,6 +33,9 @@ my $debug = 0;
my $NUMBER_RE = qr/0x[0-9a-fA-F]+|\d+/;
+our $bridge_name_pattern = '[a-zA-Z][a-zA-Z0-9]{0,9}';
+our $bridge_interface_pattern = "($bridge_name_pattern)/(\\S+)";
+
sub debug {
my $new_value = shift;
$debug = $new_value if defined($new_value);
@@ -397,7 +406,7 @@ sub route_packet {
$pkg->{physdev_in} = $target->{fwln} || die 'internal error';
$pkg->{physdev_out} = $target->{tapdev} || die 'internal error';
- } elsif ($route_state =~ m/^vmbr\d+$/) {
+ } elsif ($route_state =~ m/^$bridge_name_pattern$/) {
die "missing physdev_in - internal error?" if !$physdev_in;
$pkg->{physdev_in} = $physdev_in;
@@ -531,11 +540,6 @@ sub simulate_firewall {
$from_info->{type} = 'host';
$start_state = 'host';
$pkg->{source} = $host_ip if !defined($pkg->{source});
-} elsif ($from =~ m|^(vmbr\d+)/(\S+)$|) {
- $from_info->{type} = 'bport';
- $from_info->{bridge} = $1;
- $from_info->{iface} = $2;
- $start_state = 'from-bport';
} elsif ($from eq 'outside') {
$from_info->{type} = 'bport';
$from_info->{bridge} = 'vmbr0';
@@ -559,6 +563,11 @@ sub simulate_firewall {
$from_info = extract_vm_info($vmdata, $vmid, $netnum);
$start_state = 'fwbr-out';
$pkg->{mac_source} = $from_info->{macaddr};
+} elsif ($from =~ m|^$bridge_interface_pattern$|) {
+ $from_info->{type} = 'bport';
+ $from_info->{bridge} = $1;
+ $from_info->{iface} = $2;
+ $start_state = 'from-bport';
} else {
die "unable to parse \"from => '$from'\"\n";
}
@@ -569,10 +578,6 @@ sub simulate_firewall {
$target->{type} = 'host';
$target->{iface} = 'host';
$pkg->{dest} = $host_ip if !defined($pkg->{dest});
-} elsif ($to =~ m|^(vmbr\d+)/(\S+)$|) {
- $target->{type} = 'bport';
- $target->{bridge} = $1;
- $target->{iface} = $2;
} elsif ($to eq 'outside') {
$target->{type} = 'bport';
$target->{bridge} = 'vmbr0';
@@ -591,6 +596,10 @@ sub simulate_firewall {
my $vmid = $1;
$target = extract_vm_info($vmdata, $vmid, 0);
$target->{iface} = $target->{tapdev};
+} elsif ($to =~ m|^$bridge_interface_pattern$|) {
+ $target->{type} = 'bport';
+ $target->{bridge} = $1;
+ $target->{iface} = $2;
} else {
die "unable to parse \"to => '$to'\"\n";
}
diff --git a/src/PVE/Service/pve_firewall.pm b/src/PVE/Service/pve_firewall.pm
index 30d14d9..65cb2b8 100755
--- a/src/PVE/Service/pve_firewall.pm
+++ b/src/PVE/Service/pve_firewall.pm
@@ -18,6 +18,7 @@ use PVE::Tools qw(dir_glob_foreach file_read_firstline);
use PVE::Firewall;
use PVE::FirewallSimulator;
+use PVE::FirewallSimulator qw($bridge_interface_pattern);
use base qw(PVE::Daemon);
@@ -312,14 +313,14 @@ __PACKAGE__->register_method ({
from => {
description => "Source zone.",
type => 'string',
- pattern => '(host|outside|vm\d+|ct\d+|vmbr\d+/\S+)',
+ pattern =>
"(host|outside|vm\\d+|ct\\d+|$bridge_interface_pattern)",
optional => 1,
default => 'outside',
},
to => {
description => "Destination zone.",
type => 'string',
- pattern => '(host|outside|vm\d+|ct\d+|vmbr\d+/\S+)',
+ pattern =>
"(host|outside|vm\\d+|ct\\d+|$bridge_interface_pattern)",
optional => 1,
default => 'host',
},
--
2.39.2
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 common 1/6] interfaces: allow arbitrary bridge names in network config
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 be included in a bridge name and then would otherwise
get picked up wrongly.
Also added a warning for interfaces named vmbrX that are not bridges
to catch possible misconfigurations.
Originally-by: Jillian Morgan
Signed-off-by: Stefan Hanreich
---
Warning in the read function is a bit awkward, since for one
interfaces multiple warnings are generated - due to multiple calls to
the read function during the apply process. I think it's ok though due
to this being a relatively fringe warning which hopefully shouldn't
come up too often...
src/PVE/INotify.pm | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index bc33a8f..13724f7 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -22,6 +22,7 @@ use PVE::Network;
use PVE::ProcFSTools;
use PVE::SafeSyslog;
use PVE::Tools;
+use PVE::RESTEnvironment qw(log_warn);
use base 'Exporter';
@@ -1033,7 +1034,17 @@ sub __read_etc_network_interfaces {
foreach my $iface (keys %$ifaces) {
my $d = $ifaces->{$iface};
$d->{type} = 'unknown';
- if ($iface =~ m/^bond\d+$/) {
+ if (defined $d->{'bridge_ports'}) {
+ $d->{type} = 'bridge';
+ if (!defined ($d->{bridge_stp})) {
+ $d->{bridge_stp} = 'off';
+ }
+ if (!defined($d->{bridge_fd}) && $d->{bridge_stp} eq 'off') {
+ $d->{bridge_fd} = 0;
+ }
+ } elsif ($d->{ovs_type} && $d->{ovs_type} eq 'OVSBridge') {
+ $d->{type} = $d->{ovs_type};
+ } elsif ($iface =~ m/^bond\d+$/) {
if (!$d->{ovs_type}) {
$d->{type} = 'bond';
} elsif ($d->{ovs_type} eq 'OVSBond') {
@@ -1053,18 +1064,6 @@ sub __read_etc_network_interfaces {
my $tag = &$extract_ovs_option($d, 'tag');
$d->{ovs_tag} = $tag if defined($tag);
}
- } elsif ($iface =~ m/^vmbr\d+$/) {
- if (!$d->{ovs_type}) {
- $d->{type} = 'bridge';
- if (!defined ($d->{bridge_stp})) {
- $d->{bridge_stp} = 'off';
- }
- if (!defined($d->{bridge_fd}) && $d->{bridge_stp} eq 'off') {
- $d->{bridge_fd} = 0;
- }
- } elsif ($d->{ovs_type} eq 'OVSBridge') {
- $d->{type} = $d->{ovs_type};
- }
} elsif ($iface =~ m/^(\S+):\d+$/) {
$d->{type} = 'alias';
if (defined ($ifaces->{$1})) {
@@ -1116,6 +1115,9 @@ sub __read_etc_network_interfaces {
}
}
+ log_warn("detected a interface $iface that is not a bridge!")
+ if !($d->{type} eq 'OVSBridge' || $d->{type} eq 'bridge') && $iface
=~ m/^vmbr\d+$/;
+
# map address and netmask to cidr
if (my $addr = $d->{address}) {
if (_address_is_cidr($addr)) {
--
2.39.2
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 docs 2/6] network: update specification for bridge names
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 format description. All {pve}
tools try hard to keep
direct user modifications, but using the GUI is still preferable, because it
protects you from errors.
-A 'vmbr' interface is needed to connect guests to the underlying physical
-network. They are a Linux bridge which can be thought of as a virtual switch
-to which the guests and physical interfaces are connected to. This section
-provides some examples on how the network can be set up to accomodate different
-use cases like redundancy with a xref:sysadmin_network_bond['bond'],
+A bridge interface (commonly called 'vmbrX') is needed to connect guests to the
+underlying physical network. They are a Linux bridge which can be thought of
as
+a virtual switch to which the guests and physical interfaces are connected to.
+This section provides some examples on how the network can be set up to
+accomodate different use cases like redundancy with a
+xref:sysadmin_network_bond['bond'],
xref:sysadmin_network_vlan['vlans'] or
xref:sysadmin_network_routed['routed'] and
xref:sysadmin_network_masquerading['NAT'] setups.
@@ -75,7 +76,9 @@ We currently use the following naming conventions for device
names:
scheme is used for {pve} hosts which were installed before the 5.0
release. When upgrading to 5.0, the names are kept as-is.
-* Bridge names: `vmbr[N]`, where 0 ≤ N ≤ 4094 (`vmbr0` - `vmbr4094`)
+* Bridge names: Commonly `vmbr[N]`, where 0 ≤ N ≤ 4094 (`vmbr0` - `vmbr4094`),
+but you can use any alphanumeric string that starts with a character and is at
+most 10 characters long.
* Bonds: `bond[N]`, where 0 ≤ N (`bond0`, `bond1`, ...)
--
2.39.2
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 manager 5/6] sdn: vlan: fix indentation in vlan edit dialogue
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
+++ b/www/manager6/sdn/zones/VlanEdit.js
@@ -20,10 +20,10 @@ Ext.define('PVE.sdn.zones.VlanInputPanel', {
me.items = [
{
-xtype: 'textfield',
-name: 'bridge',
-fieldLabel: 'Bridge',
-allowBlank: false,
+ xtype: 'textfield',
+ name: 'bridge',
+ fieldLabel: 'Bridge',
+ allowBlank: false,
vtype: 'BridgeName',
minLength: 1,
maxLength: 10,
--
2.39.2
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH dab-pve-appliances] pmg: update to 8.1
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-64/dab.conf index 166dbd4..fc34d9b 100644 --- a/debian-12-bookworm-pmg-8-64/dab.conf +++ b/debian-12-bookworm-pmg-8-64/dab.conf @@ -5,11 +5,11 @@ Source: http://ftp.debian.org/debian SUITE-updates main contrib Source: http://security.debian.org/debian-security SUITE-security main contrib Source: http://download.proxmox.com/debian/pmg/ SUITE pmg-no-subscription Architecture: amd64 -Name: proxmox-mailgateway-8.0-standard -Version: 8.0-1 +Name: proxmox-mailgateway-8.1-standard +Version: 8.1-1 Section: mail Maintainer: Proxmox Support Team Infopage: https://www.proxmox.com/en/proxmox-mail-gateway/overview -Description: Proxmox Mailgateway 8.0 +Description: Proxmox Mailgateway 8.1 A full featured mail proxy for spam and virus filtering, optimized for container environment. -- 2.39.2 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage 1/1] storage/plugins: pass scfg to parse_volname
--- 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 feedback since Fri last week. Does anything speak against passing $scfg to parse_volname? Regards, rck --- End Message --- ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage 1/1] storage/plugins: pass scfg to parse_volname
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 name depend on something in the storage configuration? Best Regards, Fiona ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage 1/1] storage/plugins: pass scfg to parse_volname
--- 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. > > > > Hi, > can you please describe your use case in more detail? Why does parsing > the volume name depend on something in the storage configuration? Hi, I can try, hopefully not only repeating what I wrote in the cover letter: - We want to implement reassigning disks to different VMs. - this calls the plugin's rename_volume. Usually this renames a disk from vm-100-disk-1 to something like vm-101-disk-1. Great, no changes needed to parse_volume, the (new) VM ID can be parsed from the name with a regex and the actual disk. For us this would mean that we would need to rename the resource in LINSTOR, the DRBD devices on all nodes, the backing device for the DRBD resources on all nodes,... For various reasons that is terribly hard, especially considering cluster wide rollbacks. If you want me to, I can fill some pages about that :). So I came up with this: - Let's not store the VM ID in the name of the resource/device, but let's generate resource/"disk" names like pm-$UUID. The LINSTOR resource is named pm-$UUID, the DRBD device is named pm-$UUID, the backing devices on LVM/ZFS are named /dev/vg/pm-$UUID... - Great, we abstracted away the VM IDs. So where do we then store the VM ID that for example parse_volname needs to return the actual VM ID? - We can store that in meta data that is associated with the LINSTOR/DRBD resource. We have a central component, the LINSTOR controller, the "brain of the SDS", which is needed anyways and it's IP is already in the storage configuration. Just think of it as a "data base". - So in that "data base" we store that pm-123... belongs to VM ID 100. - Reassigning a disk to a new VM (ID) is then trivial, we just update the "data base" entry for pm-$UUID, now pointing to VM ID 101 (or whatever). That is exactly what I do in rename_volume. I don't actually rename the LINSTOR/DRBD/LVM objects/disks, I just update the mapping. When getting called for "reassing disks to a new VM", the plugin is free to generate a name. I return the old/existing name, but the new VM ID. Yes, that is a bit if cheating, but works perfectly fine for that scenario of reassinging disks to VMs. - Whenever we need the VM ID, we don't parse it from the pm-$UUID name, we can't, but we ask our "data base". - In oder to ask the "data base", we need to know its IP. And for that we need a pointer to the storage configuration that (already) contains that IP. - all plugin functions already get a parameter to $scfg. With one exception: parse_volname. All in all, yes, this is specific for our use case, otherwise parse_volname would already have that additional parameter as all the other plugin functions, but I don't see where this would hurt existing code, and it certainly helps us to enable reassigning disks to VMs. Passing in a param all other functions already get access to also does not sound too terrible to me. If there are further questions please feel free to ask. Regards, rck --- End Message --- ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH ksm-control-daemon] ksmtuned: fix large number processing
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}' \
> /proc/meminfo
> }
>
> Am 25.01.24 um 11:56 schrieb Stefan Lendl:
>> diff --git a/debian/patches/awk-printf.diff b/debian/patches/awk-printf.diff
>> new file mode 100644
>> index 000..11a957f
>> --- /dev/null
>> +++ b/debian/patches/awk-printf.diff
>> @@ -0,0 +1,16 @@
>> +--- ksm-control-scripts/ksmtuned2024-01-25 11:33:03.485039813 +0100
>> ksm-control-scripts.new/ksmtuned2024-01-25 11:37:40.544751316
>> +0100
>> +@@ -72,11 +72,11 @@
>> + # calculate how much memory is committed to running qemu processes
>> + local progname
>> + progname=${1:-kvm}
>> +-ps -C "$progname" -o vsz= | awk '{ sum += $1 }; END { print sum }'
>> ++ps -C "$progname" -o vsz= | awk '{ sum += $1 }; END { printf ("%.0f",
>> sum) }'
>> + }
>> +
>> + free_memory () {
>> +-awk '/^(MemFree|Buffers|Cached):/ {free += $2}; END {print free}' \
>> ++awk '/^(MemFree|Buffers|Cached):/ {free += $2}; END { printf ("%.0f",
>> free) }' \
>> + /proc/meminfo
>> + }
>> +
Hi Roland, as you can see in the patch, I am also adding this to the
free_memory function.
The patches are applied during the build process, hence the actual
source file still looks unchanged if you're looking at it in the repo.
If you install the package, the updated files will be placed at
/usr/sbin/ksmtuned where you can inspect the result.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH ksm-control-daemon] ksmtuned: fix large number processing
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" operates on string level and prints the 2nd ($2) part of
the string after splitting at whitespaces.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH ksm-control-daemon] ksmtuned: fix large number processing
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 { print sum }'
> 5.5e+09
> root@s740:/usr/sbin# seq 1 10 | awk '{ sum += $1 }; END { printf
> ("%.0f", sum) }'
> 55root@s740:/usr/sbin#
>
> # seq 1 10 | awk '{ sum += $1 }; END { print sum }'|xxd
> : 352e 3030 3030 3565 2b30 390a 5.5e+09.
>
> # seq 1 10 | awk '{ sum += $1 }; END { printf ("%.0f", sum) }' |xxd
> : 3530 3030 3035 3030 3030 55
>
> # seq 1 10 | awk '{ sum += $1 }; END { printf ("%.0f\n", sum) }' |xxd
> : 3530 3030 3035 3030 3030 0a 55.
>
I see that this appears different in that way.
In the script the result is always assigned to a variable which should
not care about a newline, or should even better be without the newline
in my opinion.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH ksm-control-daemon] ksmtuned: fix large number processing
--- 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 in their
RSS, using RSS one would sum up 900 MB to much compared using PSS, but
what's the correct one here is then depending on how they result is
used.
@Stefan, as you checked this out, would you care checking out the VSS
vs. RSS vs. PSS matter too? I.e. checking what should make more sense to
use and actually testing that out in a somewhat defined workload.
yes, i think PSS looks better for summing up then RSS.
The ZFS ARC thing is something else and might be a bit more complicated,
so I'd focus first one above at that seems to provide better
improvements for less work, or at least with less potential to build an
unstable control system.
mind , that the patch from
https://www.mail-archive.com/pve-devel@lists.proxmox.com/msg02453.html
is not yet complete, imho.
shouldn't we also take arc_min into account , as this can't be
freed/reclaimed from arc ?
i have reworked the memory calculation routine from free_memory ()
little bit
root@s740:~# free
total used free shared buff/cache
available
Mem: 16165308 15489260 787056 30588 165628 676048
Swap: 0 0 0
root@s740:~# ./getfreemem.sh
Memfree: 763 MB
Buffers: 0 MB
Cached: 122 MB
arc_min: 493 MB
arc_size: 4732 MB
Free = Memfree + Buffers + Cached + arc_size - arc_min = 5124 MB
root@s740:~# arcstat
time read ddread ddh% dmread dmh% pread ph% size c avail
00:45:50 0 0 0 0 0 0 0 4.6G 4.7G 156M
#!/bin/bash
exec awk '
{
if ($1 == "MemFree:") {memfree = int($2/1024); printf
"Memfree: %5d MB\n",memfree}
if ($1 == "Buffers:") {buffers = int($2/1024); printf
"Buffers: %5d MB\n",buffers}
if ($1 == "Cached:") {cached = int($2/1024); printf
"Cached: %5d MB\n",cached}
if ($1 == "c_min") {arcmin = int($3/1024/1024); printf
"arc_min: %5d MB\n",arcmin}
if ($1 == "size") {arcsize = int($3/1024/1024); printf
"arc_size: %5d MB\n",arcsize}
}
END {print "Free = Memfree + Buffers + Cached + arc_size -
arc_min = " memfree + buffers + cached + arcsize - arcmin " MB"}
' /proc/meminfo /proc/spl/kstat/zfs/arcstats
--- End Message ---
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
