[pve-devel] [PATCH-SERIES storage/docs/guest-common/qemu-server/common] Improve and unify documentation of bwlimit parameter

[pve-devel] [PATCH-SERIES storage/docs/guest-common/qemu-server/common] Improve and unify documentation of bwlimit parameter

[Stefan Hanreich]

While looking through our documentation for the bwlimit parameter
I noticed that the descriptions are inconsistent and sometimes
wrong / unclear about the actual unit used for the parameter. This
patch series fixes some inconsistencies and errors related to this
parameter.



pve-storage:

Stefan Hanreich (1):
  volume export: explicitly state unit of bandwidth limit

 PVE/Storage.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


pve-docs:

Stefan Hanreich (1):
  backup: Fix wrong unit for bandwidth limit

 vzdump.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


qemu-server:

Stefan Hanreich (1):
  qmrestore: improve description of bwlimit parameter

 PVE/CLI/qmrestore.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


pve-guest-common:

Stefan Hanreich (1):
  vzdump: improve description of bwlimit parameter

 src/PVE/VZDump/Common.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


pve-common:

Stefan Hanreich (1):
  json schema: improve description of bwlimit parameter

 src/PVE/JSONSchema.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.30.2

[pve-devel] [PATCH pve-docs 1/1] backup: Fix wrong unit for bandwidth limit

[Stefan Hanreich]

The correct unit for the bwlimit is actually Kibibyte per second
rather than Kibibit per second.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 vzdump.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/vzdump.adoc b/vzdump.adoc
index ce46529..f3eadcd 100644
--- a/vzdump.adoc
+++ b/vzdump.adoc
@@ -398,7 +398,7 @@ limit. A bigger per-job limit will only overwrite the per-storage limit if
 you have `Data.Allocate' permissions on the affected storage.
 
 You can use the `--bwlimit <integer>` option from the restore CLI commands
-to set up a restore job specific bandwidth limit.  Kibit/s is used as unit
+to set up a restore job specific bandwidth limit. KiB/s is used as unit
 for the limit, this means passing `10240' will limit the read speed of the
 backup to 10 MiB/s, ensuring that the rest of the possible storage bandwidth
 is available for the already running virtual guests, and thus the backup
-- 
2.30.2

[pve-devel] [PATCH pve-common 1/1] json schema: improve description of bwlimit parameter

[Stefan Hanreich]

This makes the description consistent with the other places that
have bwlimit as a parameter as well.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 src/PVE/JSONSchema.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/PVE/JSONSchema.pm b/src/PVE/JSONSchema.pm
index 527e409..93dfcf9 100644
--- a/src/PVE/JSONSchema.pm
+++ b/src/PVE/JSONSchema.pm
@@ -670,7 +670,7 @@ my $bwlimit_format = {
 };
 register_format('bwlimit', $bwlimit_format);
 register_standard_option('bwlimit', {
-    description => "Set bandwidth/io limits various operations.",
+    description => "Set I/O bandwidth limit for various operations (in KiB/s).",
     optional => 1,
     type => 'string',
     format => $bwlimit_format,
-- 
2.30.2

[pve-devel] [PATCH qemu-server 1/1] qmrestore: improve description of bwlimit parameter

[Stefan Hanreich]

This makes the description consistent with the other places that
have bwlimit as a parameter as well.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 PVE/CLI/qmrestore.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/PVE/CLI/qmrestore.pm b/PVE/CLI/qmrestore.pm
index 034233a..a47648b 100755
--- a/PVE/CLI/qmrestore.pm
+++ b/PVE/CLI/qmrestore.pm
@@ -54,7 +54,7 @@ __PACKAGE__->register_method({
 		description => "Add the VM to the specified pool.",
 	    },
 	    bwlimit => {
-		description => "Override i/o bandwidth limit (in KiB/s).",
+		description => "Override I/O bandwidth limit (in KiB/s).",
 		optional => 1,
 		type => 'number',
 		minimum => '0',
-- 
2.30.2

[pve-devel] [PATCH pve-storage 1/1] volume export: explicitly state unit of bandwidth limit

[Stefan Hanreich]

Other places like replication explicitly state whether byte or bit
are used as a unit rather than only the abbreviation.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
Could have gone for Bps instead, but I think this is more explicit
and all other places I could find are using the explicit unit as well.
Also, everything else is in lowercase so I decided to stick with that.

 PVE/Storage.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/PVE/Storage.pm b/PVE/Storage.pm
index cec3996..b99ed35 100755
--- a/PVE/Storage.pm
+++ b/PVE/Storage.pm
@@ -752,7 +752,7 @@ my $volume_export_prepare = sub {
     my $cstream;
     if (defined($ratelimit_bps)) {
 	$cstream = [ '/usr/bin/cstream', '-t', $ratelimit_bps ];
-	$logfunc->("using a bandwidth limit of $ratelimit_bps bps for transferring '$volid'") if $logfunc;
+	$logfunc->("using a bandwidth limit of $ratelimit_bps bytes per second for transferring '$volid'") if $logfunc;
     }
 
     volume_snapshot($cfg, $volid, $snapshot) if $migration_snapshot;
-- 
2.30.2

[pve-devel] [PATCH pve-guest-common 1/1] vzdump: improve description of bwlimit parameter

[Stefan Hanreich]

This makes the description consistent with the other places that
have bwlimit as a parameter as well.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 src/PVE/VZDump/Common.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/PVE/VZDump/Common.pm b/src/PVE/VZDump/Common.pm
index 4b0e8e0..1d96061 100644
--- a/src/PVE/VZDump/Common.pm
+++ b/src/PVE/VZDump/Common.pm
@@ -202,7 +202,7 @@ my $confdesc = {
     },
     bwlimit => {
 	type => 'integer',
-	description => "Limit I/O bandwidth (KBytes per second).",
+	description => "Limit I/O bandwidth (in KiB/s).",
 	optional => 1,
 	minimum => 0,
 	default => 0,
-- 
2.30.2

[pve-devel] applied-series: [PATCH-SERIES storage/docs/guest-common/qemu-server/common] Improve and unify documentation of bwlimit parameter

[Thomas Lamprecht]

Am 29/03/2023 um 14:34 schrieb Stefan Hanreich:
> While looking through our documentation for the bwlimit parameter
> I noticed that the descriptions are inconsistent and sometimes
> wrong / unclear about the actual unit used for the parameter. This
> patch series fixes some inconsistencies and errors related to this
> parameter.
> 

applied series, thanks!