Re: [pve-devel] applied: [PATCH] ProcFSTools:read_proc_mounts: increase read size

Thanks ! - Mail original - De: "Wolfgang Bumiller" À: "aderumier" Cc: "pve-devel" Envoyé: Mardi 26 Septembre 2017 10:54:53 Objet: applied: [PATCH] ProcFSTools:read_proc_mounts: increase read size Late, but here it goes... On Fri, Dec 16, 2016 at 05:26:10PM +0100, Alexandre Derumier w

Re: [pve-devel] pve api offline during log rotation

Hi, Am 21.09.2017 um 15:30 schrieb Thomas Lamprecht: > On 09/20/2017 01:26 PM, Stefan Priebe - Profihost AG wrote: >> Hi, >> >> >> Am 20.09.2017 um 10:36 schrieb Thomas Lamprecht: >>> On 09/20/2017 06:40 AM, Stefan Priebe - Profihost AG wrote: Nobody? >>> >>> We register the restart comm

[pve-devel] [PATCH v2 firewall 1/4] remove unused $rule_format

--- src/PVE/Firewall.pm | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm index cc81325..5d78686 100644 --- a/src/PVE/Firewall.pm +++ b/src/PVE/Firewall.pm @@ -1648,8 +1648,6 @@ sub enable_bridge_firewall { $bridge_firewall_enabled = 1; } -my $r

[pve-devel] [PATCH v2 firewall 4/4] convert string based rule definitions to hashes

--- src/PVE/Firewall.pm | 220 1 file changed, 117 insertions(+), 103 deletions(-) diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm index f8a9300..179617a 100644 --- a/src/PVE/Firewall.pm +++ b/src/PVE/Firewall.pm @@ -142,6 +142,20 @@ my

[pve-devel] [PATCH v2 firewall 2/4] prepare code for more generic firewall logging

making ruleset generation aware of a match and action part in iptable rules. code will generate the same iptables as before! (except for a few additional spaces between match and action). --- src/PVE/Firewall.pm | 166 ++- src/PVE/FirewallSimulator.

[pve-devel] [PATCH v2 firewall 0/4] Firewall improvements

second version, far from finished but trying to reorganize things without breaking what exists. generates the same rules as before. feedback welcome. Tom Weber (4): remove unused $rule_format prepare code for more generic firewall logging integrate logging into ruleset_addrule convert st

[pve-devel] [PATCH v2 firewall 3/4] integrate logging into ruleset_addrule

--- src/PVE/Firewall.pm | 33 ++--- 1 file changed, 10 insertions(+), 23 deletions(-) diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm index f1aecef..f8a9300 100644 --- a/src/PVE/Firewall.pm +++ b/src/PVE/Firewall.pm @@ -2002,10 +2002,14 @@ sub ruleset_addrule_ol

[pve-devel] [PATCH container] remove --skip-old-files from tar restore options

this breaks ownership of mountpoints in containers (leaves them at root:root) --- src/PVE/LXC/Create.pm | 5 - 1 file changed, 5 deletions(-) diff --git a/src/PVE/LXC/Create.pm b/src/PVE/LXC/Create.pm index 1f21e06..ac632de 100644 --- a/src/PVE/LXC/Create.pm +++ b/src/PVE/LXC/Create.pm @@ -77

[pve-devel] [PATCH container] Fix restore with multiple mountpoints

If you use mountpoints inside a container, and change ownership of these, a restore of the CT will reset them to root:root again. That's because the whole CT FS gets prepared and mounted together with (of course) an owner of root:root for the mp. As tar uses the option --skip-old-files it won't to

[pve-devel] [PATCH v3 container 3/5] use copy_volume for full clones

--- No changes. src/PVE/API2/LXC.pm | 26 +++--- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm index 0397224..ac3eefa 100644 --- a/src/PVE/API2/LXC.pm +++ b/src/PVE/API2/LXC.pm @@ -1191,6 +1191,9 @@ __PACKAGE__->regis

[pve-devel] [PATCH v3 container 0/5] Rebased lxc clone/move disk patches

Changes: Patch 2: * Fixed unmount warnings to refer to the right $src vs $dest variable. Patch 4 is new. Patch 5 (previous 4): * Instead of refusing moves when any snapshots exist, use the new 'is_volume_in_use' variant to check whether the volume is actually used in a snapshot, in which

[pve-devel] [PATCH v3 container 5/5] add move_volume api call

--- Changes: * Instead of refusing moves when any snapshots exist, use the new 'is_volume_in_use' variant to check whether the volume is actually used in a snapshot, in which case we simply don't allow the --delete parameter. * Don't use both 'disk' and 'volume' in the parameter descript

[pve-devel] [PATCH v3 container 1/5] factor out disk allocation+formatting for reuse

--- No changes. src/PVE/LXC.pm | 87 +- 1 file changed, 56 insertions(+), 31 deletions(-) diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm index bce032a..811af21 100644 --- a/src/PVE/LXC.pm +++ b/src/PVE/LXC.pm @@ -1321,6 +1321,59 @@ sub destro

[pve-devel] [PATCH v3 container 4/5] config: is_volume_in_use: ability to search only snapshots

--- This patch is new. src/PVE/LXC/Config.pm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/PVE/LXC/Config.pm b/src/PVE/LXC/Config.pm index c45ce7e..0330d5e 100644 --- a/src/PVE/LXC/Config.pm +++ b/src/PVE/LXC/Config.pm @@ -1176,14 +1176,14 @@ sub classify_mountpoint

[pve-devel] [PATCH v3 container 2/5] implement copy_volume

--- Fixed unmount warnings to refer to the right $src vs $dest variable. src/PVE/LXC.pm | 64 ++ 1 file changed, 64 insertions(+) diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm index 811af21..b424711 100644 --- a/src/PVE/LXC.pm +++ b/src/PVE/

Re: [pve-devel] [PATCH v3 common] CLIHandler: add a default read_password implementation

On Tue, Sep 26, 2017 at 02:01:02PM +0200, Wolfgang Bumiller wrote: > Moved here from pvesh, pveum and pct. They all need the same > functionality currently. 'pvesh' wants to pass the > Term::ReadLine instance, and it's possible we might want to > skip verification in some use cases in the future, i

[pve-devel] [PATCH manager v3 6/8] When inside the wizard, actualize the scsiType display field based on iothread selection

We keep the same logic as before: once the iothread option is selected, the default SCSI controller is switched to virtio-scsi-single until iothread is unselected again. --- www/manager6/qemu/HDEdit.js | 28 ++-- 1 file changed, 22 insertions(+), 6 deletions(-) diff --git

[pve-devel] [PATCH manager v3 5/8] Add a field to show which SCSI controller type we are currently using

--- www/manager6/qemu/HDEdit.js | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/www/manager6/qemu/HDEdit.js b/www/manager6/qemu/HDEdit.js index 8a415d8b..075ad667 100644 --- a/www/manager6/qemu/HDEdit.js +++ b/www/manager6/qemu/HDEdit.js @@ -24,11 +24,12 @@ Ext

[pve-devel] [PATCH manager v3 1/8] Do not use 'autoselect' as a boolean when preselecting a bus

The bus selector is displayed when we add a Hard Disk or CD Drive. When it is displayed, we *always* preselect the next available slot on the controller of our choice. So this test is not needed. We keep the test on the string value of 'autoselect' to select a bus position when adding a CD Drive.

[pve-devel] [PATCH manager v3 7/8] After OS type selection in Wizard, set the appropriate SCSI controller type in the Hard Disk panel

This was done previously without any kind of user visible feedback, so users would not know that they had a Virtio SCSI controller as default controller for Linux VMs. --- www/manager6/qemu/CreateWizard.js | 5 - www/manager6/qemu/OSDefaults.js | 2 +- www/manager6/qemu/OSTypeEdit.js |

[pve-devel] [PATCH manager v3 8/8] Render full name of VirtIO Block controller

This will hopefully reduce confusion with SCSI VirtIO controller --- www/manager6/form/BusTypeSelector.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/www/manager6/form/BusTypeSelector.js b/www/manager6/form/BusTypeSelector.js index ae7c327e..8abdcf4b 100644 --- a/www/manag

[pve-devel] [PATCH manager v3 4/8] Use the noVirtIO ControllerSelector property to build the list of controllers

--- www/manager6/form/ControllerSelector.js | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/www/manager6/form/ControllerSelector.js b/www/manager6/form/ControllerSelector.js index 15023a7a..489b97de 100644 --- a/www/manager6/form/ControllerSelector.js +++ b/www/manager6

[pve-devel] [PATCH manager v3 0/8] Display the SCSI controller type when adding a new drive

Since we switched to the SCSI controller in the Wizard as the recommended controller for hard disks (using VirtIO scsi in the backend) it was not clear for users that they were actually using a paravirtualized driver. An example of user confusion: https://forum.proxmox.com/threads/proxmox-hypervi

[pve-devel] [PATCH manager v3 3/8] Save the components we found via down() in a variable for later reuse.

--- www/manager6/form/ControllerSelector.js | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/www/manager6/form/ControllerSelector.js b/www/manager6/form/ControllerSelector.js index 14ad574e..15023a7a 100644 --- a/www/manager6/form/ControllerSelector.js +++ b/www/m

[pve-devel] [PATCH manager v3 2/8] Remove unused noScsi parameter

SCSI is a valid bus for Disks and CD drives, so it should always be appear in the bus list. --- www/manager6/form/BusTypeSelector.js| 6 +- www/manager6/form/ControllerSelector.js | 6 +- 2 files changed, 2 insertions(+), 10 deletions(-) diff --git a/www/manager6/form/BusTypeSelector.

[pve-devel] [PATCH v3 access-control] pveum: remove read_password

Use the CLIHandler's default. --- PVE/CLI/pveum.pm | 12 1 file changed, 12 deletions(-) diff --git a/PVE/CLI/pveum.pm b/PVE/CLI/pveum.pm index aef7089..5c217c8 100755 --- a/PVE/CLI/pveum.pm +++ b/PVE/CLI/pveum.pm @@ -25,18 +25,6 @@ sub setup_environment { PVE::RPCEnvironment->s

[pve-devel] [PATCH v3 common] CLIHandler: add a default read_password implementation

Moved here from pvesh, pveum and pct. They all need the same functionality currently. 'pvesh' wants to pass the Term::ReadLine instance, and it's possible we might want to skip verification in some use cases in the future, in which case the function can be replaced by one calling this one with $nov

[pve-devel] [PATCH v3] Move read_password to pve-common's CLIHandler

Rebase/redo of the old series. Note that I don't see the need to keep read_password() wrapping an implementation method in all 3 CLI tools when currently they all need to do the same thing. The only thing this did was pass a name to the ReadLine ctor which is not all that useful. If no verification

[pve-devel] [PATCH v3 manager] pvesh: use the CLIHandler's read_password

--- bin/pvesh | 18 ++ 1 file changed, 2 insertions(+), 16 deletions(-) diff --git a/bin/pvesh b/bin/pvesh index 936a849b..0becd4d7 100755 --- a/bin/pvesh +++ b/bin/pvesh @@ -17,6 +17,7 @@ use PVE::INotify; use PVE::RPCEnvironment; use PVE::API2Tools; use PVE::API2; +use PVE::C

[pve-devel] [PATCH v3 container] pct: remove read_password

Use the CLIHandler's default. --- src/PVE/CLI/pct.pm | 11 --- 1 file changed, 11 deletions(-) diff --git a/src/PVE/CLI/pct.pm b/src/PVE/CLI/pct.pm index 3253906..a5b51c4 100755 --- a/src/PVE/CLI/pct.pm +++ b/src/PVE/CLI/pct.pm @@ -6,7 +6,6 @@ use warnings; use POSIX; use Fcntl; use Fi

[pve-devel] [PATCH manager 6/6] ui ProcessorEdit: remove redundancy, 'NUMA' is a checkbox

Signed-off-by: Thomas Lamprecht --- www/manager6/qemu/ProcessorEdit.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/www/manager6/qemu/ProcessorEdit.js b/www/manager6/qemu/ProcessorEdit.js index 80c79236..698234b7 100644 --- a/www/manager6/qemu/ProcessorEdit.js +++ b/www/ma

[pve-devel] [PATCH manager 5/6] ui: merge CPUOptions into ProcessorEdit

It seemed a bit weird that those options were in a seprate edit window as they affect the same backend variable and may cause confusion, an user may not be sure in what way they are related to each other, if at all. This allows us to share the help button, the docs must be updated so that the move

[pve-devel] [PATCH manager 3/6] ui CPUOptions: fix cpu.shares (cpuunits) range and name

`These options take an integer value and control the "cpu.shares" control group attribute. The allowed range is 2 to 262144. Defaults to 1024.' - man systemd.resource-control Signed-off-by: Thomas Lamprecht --- www/manager6/qemu/CPUOptions.js | 6 +++--- 1 file changed, 3 insertions(+), 3 deleti

[pve-devel] [PATCH manager 0/6] ui/qemu: Refactor and merge CPUOptions into ProcessorEdit

First rewrite the ProcessorInputPanel to declarative style Then do some refactoring/cleanups in CPUOptions, prepare ProcessorEdit for the merge and execute said merge. Saves us some lines of code and a separate UI element. First patch is quite straight forward and could be applied even if the rest

[pve-devel] [PATCH manager 1/6] ui: refactor ProcessorInputPanel to declarative style

Signed-off-by: Thomas Lamprecht --- www/manager6/qemu/ProcessorEdit.js | 129 ++--- 1 file changed, 63 insertions(+), 66 deletions(-) diff --git a/www/manager6/qemu/ProcessorEdit.js b/www/manager6/qemu/ProcessorEdit.js index 01da7036..1ac6db26 100644 --- a/www/ma

[pve-devel] [PATCH manager 2/6] ui CPUOptions: cpulimits is not dependend of VM cores

It makes no real sense to set the maximal allowed value to the total count of VM cores as this setting controls how much Host CPU time the whole KVM/QEMU instance can get. This instance does not only contains the VMs CPU threads but also threads for networking, block IO, migration, ... So it can ma

[pve-devel] [PATCH manager 4/6] ui ProcessorEdit: remove total core count displayfield

Make space for merging CPUOptions into ProcessorEdit. Instead, make it clearer that the 'cores' option is really a 'cores per socket' option Signed-off-by: Thomas Lamprecht --- www/manager6/qemu/ProcessorEdit.js | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/www/m

[pve-devel] applied: [PATCH] ProcFSTools:read_proc_mounts: increase read size

Late, but here it goes... On Fri, Dec 16, 2016 at 05:26:10PM +0100, Alexandre Derumier wrote: > I have some servers with a lot of mounts (1 by vm), default read limit is too > small, and activate volume hang at vm start > > Signed-off-by: Alexandre Derumier > --- > src/PVE/ProcFSTools.pm | 2 +

[pve-devel] [PATCH common] schema/cli: allow hyphens for underscores in CLI options

--- Underscores in command line options are stupid. Even more than the inconsistency we have there. And since many of them come from the API backend, changing them breaks stuff (deprecating+aliasing them would work, though, but that's much more work as well...) Next step, make the man page genera