Re: [pve-devel] applied: [PATCH pve-network 0/2] improvments

2019-06-06 Thread Alexandre DERUMIER
>> >>As long as we have a clear dependency releationship between the >>packages this could be OK. I.e., probably: >> >>common <- network <- manager >>^ >> `- qemu-server/container <-/ Hi, I have checked in the code, and they are a lot of small sub in Netw

[pve-devel] [PATCH pve-network 1/2] remove vnet bridge delete hook

2019-06-06 Thread Alexandre Derumier
We can check that in local reload when we'll generate config Signed-off-by: Alexandre Derumier --- PVE/Network/Network/VnetPlugin.pm | 72 +-- 1 file changed, 1 insertion(+), 71 deletions(-) diff --git a/PVE/Network/Network/VnetPlugin.pm b/PVE/Network/Networ

[pve-devel] [PATCH pve-network 0/2] prepare for merging other network code

2019-06-06 Thread Alexandre Derumier
- remove vnet delete hook (to remove depend on qemuserver && lxc) - rename Network::Network to Network::SDN Alexandre Derumier (2): remove vnet bridge delete hook rename PVE::Network::Network to PVE::Network::SDN PVE/API2/Network/Makefile | 2 +- PVE/API2/Network/{

[pve-devel] [PATCH pve-network 2/2] rename PVE::Network::Network to PVE::Network::SDN

2019-06-06 Thread Alexandre Derumier
Signed-off-by: Alexandre Derumier --- PVE/API2/Network/Makefile | 2 +- PVE/API2/Network/{Network.pm => SDN.pm}| 62 +++--- PVE/Network/Makefile | 4 +- PVE/Network/{Network.pm => SDN.pm} | 22 +++

[pve-devel] [RFC manager][stable-5] gui: vm: add CPU flag selector with tri-state awareness

2019-06-06 Thread Thomas Lamprecht
This allows to select the tri-state (enforce on, enforce off, default from QEMU+CPU Model) for each CPU flag independently. For this a grid with a widgetcolumn is used hosting tree radio buttons for each state. They're marked '+' for enforce on, '-' for enforce off and the default has no label, as

Re: [pve-devel] applied: [PATCH pve-network 0/2] improvments

2019-06-06 Thread Alexandre DERUMIER
> > I wonder if I could rename this to PVE::Network::SDN instead > PVE::Network::Network, to avoid confusion ? >>OK for me. Ok,I'll send a patch tomorrow >>As long as we have a clear dependency releationship between the >>packages this could be OK. I.e., probably: >>common <- network <---

Re: [pve-devel] [PATCH qemu-server 2/2] add md-clear cpu flag

2019-06-06 Thread Thomas Lamprecht
On 6/3/19 3:17 PM, Oguz Bektas wrote: > Signed-off-by: Oguz Bektas > --- > PVE/QemuServer.pm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm > index 1a22fb4..159a90d 100644 > --- a/PVE/QemuServer.pm > +++ b/PVE/QemuServer.pm > @@ -16

[pve-devel] applied: [PATCH qemu-server 2/2] add md-clear cpu flag

2019-06-06 Thread Thomas Lamprecht
On 6/3/19 3:17 PM, Oguz Bektas wrote: > Signed-off-by: Oguz Bektas > --- > PVE/QemuServer.pm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm > index 1a22fb4..159a90d 100644 > --- a/PVE/QemuServer.pm > +++ b/PVE/QemuServer.pm > @@ -16

[pve-devel] applied: [PATCH v2 qemu/qemu-server] fix for intel MDS CVEs

2019-06-06 Thread Thomas Lamprecht
On 6/6/19 3:11 PM, Oguz Bektas wrote: > cherry-picks mds mitigation related commits from upstream qemu, some > commits are taken to ensure easy backport. > > fixes included for: > * CVE-2018-12126 > * CVE-2018-12127 > * CVE-2018-12130 > * CVE-2019-11091 > > adds the md-clear cpuflag. > > Not inc

[pve-devel] [PATCH v2 qemu/qemu-server] fix for intel MDS CVEs

2019-06-06 Thread Oguz Bektas
cherry-picks mds mitigation related commits from upstream qemu, some commits are taken to ensure easy backport. fixes included for: * CVE-2018-12126 * CVE-2018-12127 * CVE-2018-12130 * CVE-2019-11091 adds the md-clear cpuflag. Not included by default in any Intel CPU model. Must be explicitly t

Re: [pve-devel] applied: [PATCH pve-network 0/2] improvments

2019-06-06 Thread Thomas Lamprecht
On 6/6/19 10:16 AM, Alexandre DERUMIER wrote: >>> On another note, is there any specific reason we have a double "Network" >>> in the module namespace? Or could we change it to >>> >>> PVE/Network.pm >>> PVE/Network/VlanPlugin.pm >>> ... > >>> and respective module name-path changes? As now, with

Re: [pve-devel] [PATCH qemu 1/2] fix #2190: Base64 encode SMBIOS value strings in order to allow more characters

2019-06-06 Thread Tim Marx
looks good as well. > Christian Ebner hat am 4. Juni 2019 um 16:47 > geschrieben: > > > On some occasions e.g. license checking, the manufacturer string in the > SMBIOS settings edit has to allow characters such as whitespaces. > https://forum.proxmox.com/threads/proxmox-and-windows-rok-licens

[pve-devel] applied: [PATCH pve-network] vxlan interface : use vxlan$vnetid

2019-06-06 Thread Thomas Lamprecht
On 6/6/19 2:16 PM, Alexandre Derumier wrote: > vxlan number can be huge (16millions), don't use tag for interface name. > (my last ifupdown2 patch ifdown/ifup vxlan interface on reload) > > Signed-off-by: Alexandre Derumier > --- > PVE/Network/Network/VxlanMulticastPlugin.pm | 6 +++--- > 1 file

[pve-devel] applied: [PATCH qemu-server v2 0/3] add cloudinit config dump

2019-06-06 Thread Thomas Lamprecht
On 6/5/19 11:09 AM, Mira Limbeck wrote: > The ability to dump the generated cloudinit config that's written to the > ISO if no snippet is specified in combination with snippets should be > enough for almost every cloudinit user to get started on custom > cloudinit configs. > > The 2nd patch depend

Re: [pve-devel] [PATCH manager 2/2] fix #2190: Base64 encode SMBIOS value strings in order to allow more characters

2019-06-06 Thread Tim Marx
Looks good. > Christian Ebner hat am 4. Juni 2019 um 16:47 > geschrieben: > > > On some occasions e.g. license checking, the manufacturer string in the > SMBIOS settings edit has to allow characters such as whitespaces. > https://forum.proxmox.com/threads/proxmox-and-windows-rok-license-for-de

[pve-devel] [PATCH pve-network] vxlan interface : use vxlan$vnetid

2019-06-06 Thread Alexandre Derumier
vxlan number can be huge (16millions), don't use tag for interface name. (my last ifupdown2 patch ifdown/ifup vxlan interface on reload) Signed-off-by: Alexandre Derumier --- PVE/Network/Network/VxlanMulticastPlugin.pm | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/PVE

[pve-devel] applied: [PATCH manager 1/5] ceph: make ceph osd create api more readable

2019-06-06 Thread Thomas Lamprecht
On 6/5/19 3:59 PM, Dominik Csapak wrote: > The aim of this patch is to reorder/rework the code of the api call > so that it gets more readable > > it adds comments of what/why something is done, removes > code duplication between db/wal checks/creation > > There are two changes in behaviour: > *

Re: [pve-devel] [PATCH common 1/1] Fix #545: Allow descriptive names for network bridges and bonds

2019-06-06 Thread Alexandre DERUMIER
>>- 11 characters left for hypervisor interfaces (vmbr/vnet/bond all have >> 4 characters) and also it's possible to have 4096 vlans (bondX.4096), so it's 6 characters left for tagged interfaces >>the interface name is used/displayed/supported across the board, the >>alias likely is not (yet)

[pve-devel] [PATCH container v2] Fix #576: Cancelling move disk does not leave useless files anymore

2019-06-06 Thread Dominic Jäger
When cancelling the move disk operation for containers the partly finished destination and thus useless files now get removed. Co-developed-by: Wolfgang Bumiller Signed-off-by: Dominic Jäger --- After a quick offline feedback there is now a v2 v2: System call is not a single string anymore sr

Re: [pve-devel] [PATCH common 1/1] Fix #545: Allow descriptive names for network bridges and bonds

2019-06-06 Thread Fabian Grünbichler
On Thu, Jun 06, 2019 at 07:54:21AM +0200, Alexandre DERUMIER wrote: > Hi, > > I think the main problem could be the 16 characters limit. we currently allow up to 20 characters in our API/the interface standard option, and even more in the actual interface name format ('pve-iface'). 'ip link' sta

[pve-devel] applied: [PATCH common] print defaulttxt as sprintf parameter

2019-06-06 Thread Thomas Lamprecht
On 6/6/19 11:03 AM, Dominik Csapak wrote: > instead of having it verbatim in the format string. > This enables us to have '%' in the defaulttext without getting errors > > Signed-off-by: Dominik Csapak > --- > src/PVE/RESTHandler.pm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > di

[pve-devel] [PATCH container] Fix #576: Cancelling move disk does not leave useless files anymore

2019-06-06 Thread Dominic Jäger
When cancelling the move disk operation for containers the partly finished destination and thus useless files now get removed. Signed-off-by: Dominic Jäger --- src/PVE/LXC.pm | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm index 62b6b8c..3

[pve-devel] [PATCH common] print defaulttxt as sprintf parameter

2019-06-06 Thread Dominik Csapak
instead of having it verbatim in the format string. This enables us to have '%' in the defaulttext without getting errors Signed-off-by: Dominik Csapak --- src/PVE/RESTHandler.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/PVE/RESTHandler.pm b/src/PVE/RESTHandler.pm i

Re: [pve-devel] [PATCH ifupdown2] ifup/ifdown vxlan interface on reload

2019-06-06 Thread Alexandre DERUMIER
>>looks OK for now, I'd wait a bit on upstream commentary as I didn't >>plan to bump ifudown2 really soon, so maybe I can just pull the master, >>or even the current release, as the last one was almost half a year ago, >>so one should probably happen quite soon anyway. >>Or aren't they >>motiva

Re: [pve-devel] applied: [PATCH pve-network 0/2] improvments

2019-06-06 Thread Alexandre DERUMIER
>>On another note, is there any specific reason we have a double "Network" >>in the module namespace? Or could we change it to >> >>PVE/Network.pm >>PVE/Network/VlanPlugin.pm >>... >>and respective module name-path changes? As now, with not much external >>code using this, it would be still relat

Re: [pve-devel] [PATCH common 1/1] Fix #545: Allow descriptive names for network bridges and bonds

2019-06-06 Thread Dominic Jäger
Changing \d to \w was simply the quickest way to adress the bug report. I've already heard some people here speaking favorably about the idea of an alias/custom description, but no final decision has been made as far as I know. > Alexandre DERUMIER hat am 6. Juni 2019 um 07:54 > geschrieben: >