[pve-devel] [PATCH manager 1/2] unprivileged:true by default in ct creation

2019-02-12 Thread Oguz Bektas
Signed-off-by: Oguz Bektas --- www/manager6/lxc/CreateWizard.js | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/www/manager6/lxc/CreateWizard.js b/www/manager6/lxc/CreateWizard.js index ea86c6aa..b24d371f 100644 --- a/www/manager6/lxc/CreateWizard.js +++ b/www/manager6/lxc

[pve-devel] [PATCH manager 2/2] unprivileged:true by default in restore window

2019-02-12 Thread Oguz Bektas
Signed-off-by: Oguz Bektas --- www/manager6/window/Restore.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/www/manager6/window/Restore.js b/www/manager6/window/Restore.js index 8927e096..6eac13ef 100644 --- a/www/manager6/window/Restore.js +++ b/www/manager6/window/Restore.

[pve-devel] [PATCH docs] Fixed typo in Ceph Metadata Server documentation

2019-02-12 Thread Christian Ebner
This fixes a typo in the Metadata Server section of the documentation. Signed-off-by: Christian Ebner --- pveceph.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pveceph.adoc b/pveceph.adoc index 2b061e5..d260976 100644 --- a/pveceph.adoc +++ b/pveceph.adoc @@ -460,7 +46

[pve-devel] [PATCH] unprivileged:true by default in ct creation wizard

2019-02-12 Thread Oguz Bektas
Signed-off-by: Oguz Bektas --- www/manager6/lxc/CreateWizard.js | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/www/manager6/lxc/CreateWizard.js b/www/manager6/lxc/CreateWizard.js index ea86c6aa..b24d371f 100644 --- a/www/manager6/lxc/CreateWizard.js +++ b/www/manager6/lxc

[pve-devel] [PATCH docs] Fix double occurrence of be in pveceph docs

2019-02-12 Thread Christian Ebner
This fixes a typo (subsequent occurrence of be) in the CephFS section of the documentation. Signed-off-by: Christian Ebner --- pveceph.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pveceph.adoc b/pveceph.adoc index 2b061e5..f275463 100644 --- a/pveceph.adoc +++ b/pvece

Re: [pve-devel] [PATCH qemu-server] Fix #2062: New timeout switch for guest cmd

2019-02-12 Thread Kamil Trzciński
Does it make sense to make this not forever by default? Maybe like 600 seconds should be good compromise, and if needed, this could be overwritten? On Mon, Feb 11, 2019 at 2:17 PM Rhonda D'Vine wrote: > The guest cmd commands set different timeouts. Some of those might take > longer, so for deb

[pve-devel] [PATCH v2 qemu-server 0/1] Use usb-kbd for q35 in tablet mode

2019-02-12 Thread Kamil Trzciński
The usb-kbd on q35 in tablet mode removes the need for "hotpatching" when trying to install MacOS on Proxmox. Needed for: https://www.nicksherlock.com/2018/06/installing-macos-mojave-on-proxmox/. v2: * Fixed author of patches Kamil Trzciński (1): Use usb-kbd for q35 in tablet mode PVE/QemuS

Re: [pve-devel] [PATCH v2 qemu-server 1/1] Use usb-kbd for q35 in tablet mode

2019-02-12 Thread Kamil Trzciński
Again. Wrong commit author. On Tue, Feb 12, 2019 at 1:36 PM Kamil Trzciński wrote: > The usb-kbd on q35 in tablet mode removes the need for "hotpatching" > when trying to install MacOS on Proxmox. > --- > PVE/QemuServer.pm | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff

[pve-devel] [PATCH v2 qemu-server 1/1] Use usb-kbd for q35 in tablet mode

2019-02-12 Thread Kamil Trzciński
The usb-kbd on q35 in tablet mode removes the need for "hotpatching" when trying to install MacOS on Proxmox. --- PVE/QemuServer.pm | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm index 6dc68a4..7eb6f37 100644 --- a/PVE/QemuServer.pm

[pve-devel] [PATCH qemu-server 0/1] Use usb-kbd for q35 in tablet mode

2019-02-12 Thread Kamil Trzciński
The usb-kbd on q35 in tablet mode removes the need for "hotpatching" when trying to install MacOS on Proxmox. root (1): Use usb-kbd for q35 in tablet mode PVE/QemuServer.pm | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) -- 2.17.1 ___

[pve-devel] [PATCH qemu-server 1/1] Use usb-kbd for q35 in tablet mode

2019-02-12 Thread Kamil Trzciński
From: root The usb-kbd on q35 in tablet mode removes the need for "hotpatching" when trying to install MacOS on Proxmox. --- PVE/QemuServer.pm | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm index 6dc68a4..7eb6f37 100644 --- a/PVE/

Re: [pve-devel] [PATCH qemu-server 1/1] Use nr_hugepages from /proc/cmdline

2019-02-12 Thread Kamil Trzciński
Ignore this one. I sent it wrong from address :) On Tue, Feb 12, 2019 at 12:59 PM root wrote: > From: Kamil Trzciński > > Currently Proxmox VE always deallocates HugePagesTLB > when starting a new machine and it makes it impossible > to preconfigure kernel /proc/cmdline with persistent allocati

[pve-devel] [PATCH qemu-server 0/1] Use nr_hugepages from /proc/cmdline

2019-02-12 Thread Kamil Trzciński
Currently Proxmox VE always deallocates HugePagesTLB when starting a new machine and it makes it impossible to preconfigure kernel /proc/cmdline with persistent allocation. This changes makes deallocation to prefer defaults set by /proc/cmdline, by parsing the cmdline and respecting hugepages= and

[pve-devel] [PATCH qemu-server 1/1] Use nr_hugepages from /proc/cmdline

2019-02-12 Thread Kamil Trzciński
Currently Proxmox VE always deallocates HugePagesTLB when starting a new machine and it makes it impossible to preconfigure kernel /proc/cmdline with persistent allocation. This changes makes deallocation to prefer defaults set by /proc/cmdline, by parsing the cmdline and respecting hugepages= and

[pve-devel] [PATCH qemu-server 1/1] Use nr_hugepages from /proc/cmdline

2019-02-12 Thread ayufan
From: Kamil Trzciński Currently Proxmox VE always deallocates HugePagesTLB when starting a new machine and it makes it impossible to preconfigure kernel /proc/cmdline with persistent allocation. This changes makes deallocation to prefer defaults set by /proc/cmdline, by parsing the cmdline and r

[pve-devel] [PATCH qemu-server 0/1] Use nr_hugepages from /proc/cmdline

2019-02-12 Thread ayufan
From: Kamil Trzciński Currently Proxmox VE always deallocates HugePagesTLB when starting a new machine and it makes it impossible to preconfigure kernel /proc/cmdline with persistent allocation. This changes makes deallocation to prefer defaults set by /proc/cmdline, by parsing the cmdline and r

[pve-devel] [PATCH docs 2/3] Fix #2015: add how to get a auth secret for cephfs

2019-02-12 Thread Alwin Antreich
Signed-off-by: Alwin Antreich --- pve-storage-cephfs.adoc | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/pve-storage-cephfs.adoc b/pve-storage-cephfs.adoc index 2613d64..96f4991 100644 --- a/pve-storage-cephfs.adoc +++ b/pve-storage-cephfs.adoc @@ -71,13 +71,20 @@ Cre

[pve-devel] [PATCH docs 1/3] asciidoc-pve: ignore link targets for non-manpages

2019-02-12 Thread Alwin Antreich
From: Thomas Lamprecht To allow linking from to a chapter/section not included in a manpage allow the manpage link resolver to just return text in a case the link target text is in fact no manpage. If the link is a valid one in general will be checked in a lot of other places, so here we won't r

[pve-devel] [PATCH docs 0/3] cephfs client documentation improvements

2019-02-12 Thread Alwin Antreich
Whit the help of Thomas, this series adds our ceph repositories to the documentation and updates the missing installation information for a working cephfs storage client. Thomas patch is needed to get the Fix #2018 applied, as it references a non-manpage. Alwin Antreich (2): Fix #2015: add how

[pve-devel] [PATCH docs 3/3] Fix #2018: CephFS client needs newer binaries

2019-02-12 Thread Alwin Antreich
To run cephfs client the debian stock packages need to be updated to luminous to get it running. This patch adds a section with our Ceph repositories to our package repo chapter to where the cephfs storage plugin chapter links to. Signed-off-by: Alwin Antreich --- pve-package-repos.adoc | 28 +

Re: [pve-devel] pve-firewall : vm live migration: rules applied only after vm config file move

2019-02-12 Thread Dietmar Maurer
> That mean that when we do a live migration, > the rules are not apply until the config file is moved. (and vm resume just > after). > > So, we can have some seconds where the rules are not yet applied. > > > I'm not sure how we could handle this correctly ? > > 1) force rules update after th