Re: [pve-devel] [PATCH] PVE/API2/LXC.pm ssh-public-keys alias

2018-01-30 Thread Geert Stappers 
On Wed, Jan 31, 2018 at 12:14:43AM +0100, Geert Stappers wrote:
> Parameter name 'ssh-public-keys' causes trouble
> when written as ssh-public-keys. Because it can read as
> arthmetic expression ssh minus public minus keys.
> 
> So an alias to the rescue.
> Parameter name is 'ssh_public_keys'.
> 
> Signed-off-by: Geert Stappers 
> ---
>  src/PVE/API2/LXC.pm |   12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
> index 733826e..ae3cbd8 100644
> --- a/src/PVE/API2/LXC.pm
> +++ b/src/PVE/API2/LXC.pm

It is from repository  git://git.proxmox.com/git/pve-container.git


> @@ -161,6 +161,11 @@ __PACKAGE__->register_method({
>   description => "Setup public SSH keys (one key per line, " .
>   "OpenSSH format).",
>   },
> + 'ssh_public_keys' => {
> + optional => 1,
> + type => 'string',
> + description => "Alias for ssh-public-keys",
> + },
>   }),
>  },
>  returns => {
> @@ -204,7 +209,12 @@ __PACKAGE__->register_method({
>  
>   my $password = extract_param($param, 'password');
>  
> - my $ssh_keys = extract_param($param, 'ssh-public-keys');
> + my $ssh_keys;
> + my $ssh_keys_orig = extract_param($param, 'ssh-public-keys');
> + my $ssh_keys_alias = extract_param($param, 'ssh_public_keys');
> + $ssh_keys = $ssh_keys_alias if defined($ssh_keys_alias);
> + # Allow the original 'ssh-public-keys' parameter to win
> + $ssh_keys = $ssh_keys_orig if defined($ssh_keys_orig);
>   PVE::Tools::validate_ssh_public_keys($ssh_keys) if defined($ssh_keys);
>  
>   my $pool = extract_param($param, 'pool');
> -- 
> 1.7.10.4
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [PATCH] PVE/API2/LXC.pm ssh-public-keys alias

2018-01-30 Thread Geert Stappers 
Parameter name 'ssh-public-keys' causes trouble
when written as ssh-public-keys. Because it can read as
arthmetic expression ssh minus public minus keys.

So an alias to the rescue.
Parameter name is 'ssh_public_keys'.

Signed-off-by: Geert Stappers 
---
 src/PVE/API2/LXC.pm |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
index 733826e..ae3cbd8 100644
--- a/src/PVE/API2/LXC.pm
+++ b/src/PVE/API2/LXC.pm
@@ -161,6 +161,11 @@ __PACKAGE__->register_method({
description => "Setup public SSH keys (one key per line, " .
"OpenSSH format).",
},
+   'ssh_public_keys' => {
+   optional => 1,
+   type => 'string',
+   description => "Alias for ssh-public-keys",
+   },
}),
 },
 returns => {
@@ -204,7 +209,12 @@ __PACKAGE__->register_method({
 
my $password = extract_param($param, 'password');
 
-   my $ssh_keys = extract_param($param, 'ssh-public-keys');
+   my $ssh_keys;
+   my $ssh_keys_orig = extract_param($param, 'ssh-public-keys');
+   my $ssh_keys_alias = extract_param($param, 'ssh_public_keys');
+   $ssh_keys = $ssh_keys_alias if defined($ssh_keys_alias);
+   # Allow the original 'ssh-public-keys' parameter to win
+   $ssh_keys = $ssh_keys_orig if defined($ssh_keys_orig);
PVE::Tools::validate_ssh_public_keys($ssh_keys) if defined($ssh_keys);
 
my $pool = extract_param($param, 'pool');
-- 
1.7.10.4

___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH cluster] datacenter.cfg: add bwlimit

2018-01-30 Thread Dietmar Maurer 
I think this is the wrong place to add defaults.

We need default for various different task, so we should use a more generic
concept?


> On January 30, 2018 at 4:34 PM Wolfgang Bumiller 
> wrote:
> 
> 
> This will define the global defaults which can be overridden
> by per-storage limits.
> 
> Signed-off-by: Wolfgang Bumiller 
> ---
>  data/PVE/Cluster.pm | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/data/PVE/Cluster.pm b/data/PVE/Cluster.pm
> index 5fc7d86..b49fd94 100644
> --- a/data/PVE/Cluster.pm
> +++ b/data/PVE/Cluster.pm
> @@ -1398,6 +1398,7 @@ my $datacenter_schema = {
>   pattern => qr/[a-f0-9]{2}(?::[a-f0-9]{2}){0,2}:?/i,
>   description => 'Prefix for autogenerated MAC addresses.',
>   },
> + bwlimit => PVE::JSONSchema::get_standard_option('bwlimit'),
>  },
>  };
>  
> -- 
> 2.11.0
> 
> 
> ___
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ?

2018-01-30 Thread Herman Bos 
On 30 January 2018 at 14:32, Alexandre DERUMIER  wrote:

> >>I understand what your getting at, but to avoid confusion I would suggest
> >>to skip the term symmetric routing here (which would suggest that data
> >>to/from follows the same path),
> >>routed traffic is usually very asymmetric.
>
> I mean symetric because egress/ingress on the proxmox node where the vm is
> located.
> of course if you have multiple routers/links, traffic could come back from
> another router.
> But always on the same proxmox node.
>
>
It always has to ingress/egress on the node running the vm? else it won't
work. ;-)
Just nitpicking.

If you put up your poc configs, please let me know.
I can schedule some time on our end to test, review and contribute where
needed.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] applied: [PATCH v2] improve serial terminal handling

2018-01-30 Thread Wolfgang Bumiller 
applied whole series

On Fri, Jan 26, 2018 at 11:57:58AM +0100, Dominik Csapak wrote:
> this series adds the ability to show serial ports on the gui,
> and disabling the xtermjs button when no serial device exists for the vm
> 
> changes from v1:
> * rebase on current master
> * changed icon to thomas version, thanks :)
> 
> qemu-server:
> 
> Dominik Csapak (1):
>   add serial:1 to vmstatus when config has a serial device configured
> 
>  PVE/QemuServer.pm | 14 ++
>  1 file changed, 14 insertions(+)
> 
> pve-manager:
> 
> Dominik Csapak (4):
>   add icon/class for serial ports
>   change group of unused to 99 to that we can add things in between
>   show serial ports on the gui
>   enable/disable xtermjs depending on the existance of a serial port
> 
>  www/css/ext6-pve.css |  7 
>  www/images/Makefile  |  7 +++-
>  www/images/icon-serial.svg   | 65 
> 
>  www/manager6/button/ConsoleButton.js |  8 +
>  www/manager6/qemu/Config.js  |  3 ++
>  www/manager6/qemu/HardwareView.js| 11 +-
>  6 files changed, 99 insertions(+), 2 deletions(-)
>  create mode 100644 www/images/icon-serial.svg
> 
> -- 
> 2.11.0

___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [PATCH common] schema: add bwlimit standard option and format

2018-01-30 Thread Wolfgang Bumiller 
Signed-off-by: Wolfgang Bumiller 
---
This is the single place where new task types can be added. Feel free to
comment on the ones below.

 src/PVE/JSONSchema.pm | 36 
 1 file changed, 36 insertions(+)

diff --git a/src/PVE/JSONSchema.pm b/src/PVE/JSONSchema.pm
index 4bc7cbb..9861a8f 100644
--- a/src/PVE/JSONSchema.pm
+++ b/src/PVE/JSONSchema.pm
@@ -406,6 +406,42 @@ sub pve_verify_startup_order {
 die "unable to parse startup options\n";
 }
 
+my %bwlimit_opt = (
+optional => 1,
+type => 'number', minimum => '0',
+format_description => 'LIMIT',
+);
+
+my $bwlimit_format = {
+   default => {
+   %bwlimit_opt,
+   description => 'default bandwidth limit in MiB/s',
+   },
+   restore => {
+   %bwlimit_opt,
+   description => 'bandwidth limit in MiB/s for restoring guests from 
backups',
+   },
+   migration => {
+   %bwlimit_opt,
+   description => 'bandwidth limit in MiB/s for migrating guests',
+   },
+   clone => {
+   %bwlimit_opt,
+   description => 'bandwidth limit in MiB/s for cloning disks',
+   },
+   move => {
+   %bwlimit_opt,
+   description => 'bandwidth limit in MiB/s for moving disks',
+   },
+};
+register_format('bwlimit', $bwlimit_format);
+register_standard_option('bwlimit', {
+description => "Set bandwidth/io limits various operations.",
+optional => 1,
+type => 'string',
+format => $bwlimit_format,
+});
+
 sub pve_parse_startup_order {
 my ($value) = @_;
 
-- 
2.11.0


___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [PATCH storage] add Storage::get_bandwidth_limit helper

2018-01-30 Thread Wolfgang Bumiller 
Takes an operation, an optional requested bandwidth
limit override, and a list of storages involved in the
operation and lowers the requested bandwidth against global
and storage-specific limits unless the user has permissions
to change those.
This means:
 * Global limits apply to all users without Sys.Modify on /
   (as they can change datacenter.cfg options via the API).
 * Storage specific limits apply to users without
   Datastore.Allocate access on /storage/X for any involved
   storage X.

Signed-off-by: Wolfgang Bumiller 
---
 PVE/Storage.pm   |  84 
 PVE/Storage/DRBDPlugin.pm|   1 +
 PVE/Storage/DirPlugin.pm |   2 +
 PVE/Storage/GlusterfsPlugin.pm   |   1 +
 PVE/Storage/ISCSIDirectPlugin.pm |   1 +
 PVE/Storage/ISCSIPlugin.pm   |   1 +
 PVE/Storage/LVMPlugin.pm |   1 +
 PVE/Storage/LvmThinPlugin.pm |   1 +
 PVE/Storage/NFSPlugin.pm |   1 +
 PVE/Storage/RBDPlugin.pm |   1 +
 PVE/Storage/SheepdogPlugin.pm|   1 +
 PVE/Storage/ZFSPlugin.pm |   1 +
 PVE/Storage/ZFSPoolPlugin.pm |   1 +
 test/Makefile|   5 +-
 test/run_bwlimit_tests.pl| 163 +++
 15 files changed, 264 insertions(+), 1 deletion(-)
 create mode 100755 test/run_bwlimit_tests.pl

diff --git a/PVE/Storage.pm b/PVE/Storage.pm
index 73b21e1..7c07500 100755
--- a/PVE/Storage.pm
+++ b/PVE/Storage.pm
@@ -1534,4 +1534,88 @@ sub complete_volume {
 return $res;
 }
 
+# Various io-heavy operations require io/bandwidth limits which can be
+# configured on multiple levels: The global defaults in datacenter.cfg, and
+# per-storage overrides. When we want to do a restore from storage A to storage
+# B, we should take the smaller limit defined for storages A and B, and if no
+# such limit was specified, use the one from datacenter.cfg.
+sub get_bandwidth_limit {
+my ($operation, $override, $storage_list) = @_;
+
+# called for each limit (global, per-storage) with the 'default' and the
+# $operation limit and should udpate $override for every limit affecting
+# us.
+my $was_limited = 0;
+my $apply_limit = sub {
+   my ($max) = @_;
+   if (defined($max) && (!defined($override) || $max < $override)) {
+   $override = $max;
+   $was_limited = 1;
+   return 1;
+   }
+   return 0;
+};
+
+my $rpcenv = PVE::RPCEnvironment->get();
+my $authuser = $rpcenv->get_user();
+
+# Apply per-storage limits - if there are storages involved.
+if (@$storage_list) {
+   my $config = config();
+
+   # The Datastore.Allocate permission allows us to modify the per-storage
+   # limits, therefore it also allows us to override them.
+   # Since we have most likely multiple storages to check, do a quick 
check on
+   # the general '/storage' path to see if we can skip the checks entirely:
+   return $override if $rpcenv->check($authuser, '/storage', 
['Datastore.Allocate'], 1);
+
+   my %done;
+   my $enforce_global_limits = 0;
+   foreach my $storage (@$storage_list) {
+   # Avoid duplicate checks:
+   next if $done{$storage};
+   $done{$storage} = 1;
+
+   # Otherwise we may still have individual /storage/$ID permissions:
+   if (!$rpcenv->check($authuser, "/storage/$storage", 
['Datastore.Allocate'], 1)) {
+   # And if not: apply the limits.
+   my $storecfg = storage_config($config, $storage);
+   if (defined(my $bwlimit = $storecfg->{bwlimit})) {
+   my $limits = 
PVE::JSONSchema::parse_property_string('bwlimit', $bwlimit);
+   $apply_limit->($limits->{$operation})
+   or $apply_limit->($limits->{default});
+   } else {
+   # In case this storage has no limits, remember we *must*
+   # apply the global limits in its place
+   $enforce_global_limits = 1;
+   }
+   } else {
+   # we were specificially allowed to override the storage's limit
+   # and if no other storages are used we can skip global defaults
+   # unless $enforce_global_limits is set
+   $was_limited = 1;
+   }
+   }
+
+   # Storage limits take precedence over the datacenter defaults, so if
+   # a limit was applied:
+   return $override if $was_limited && !$enforce_global_limits;
+}
+
+# Sys.Modify on '/' means we can change datacenter.cfg which contains the
+# global default limits.
+if (!$rpcenv->check($authuser, '/', ['Sys.Modify'], 1)) {
+   # So if we cannot modify global limits, apply them to our currently
+   # requested override.
+   my $dc = cfs_read_file('datacenter.cfg');
+   if (defined(my $bwlimit = $dc->{bwlimit})) {
+   my $limits = PVE::JSONSchema::parse_property_string('bwlimit',

[pve-devel] [PATCH cluster] datacenter.cfg: add bwlimit

2018-01-30 Thread Wolfgang Bumiller 
This will define the global defaults which can be overridden
by per-storage limits.

Signed-off-by: Wolfgang Bumiller 
---
 data/PVE/Cluster.pm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/data/PVE/Cluster.pm b/data/PVE/Cluster.pm
index 5fc7d86..b49fd94 100644
--- a/data/PVE/Cluster.pm
+++ b/data/PVE/Cluster.pm
@@ -1398,6 +1398,7 @@ my $datacenter_schema = {
pattern => qr/[a-f0-9]{2}(?::[a-f0-9]{2}){0,2}:?/i,
description => 'Prefix for autogenerated MAC addresses.',
},
+   bwlimit => PVE::JSONSchema::get_standard_option('bwlimit'),
 },
 };
 
-- 
2.11.0


___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [PATCH 0/3] generic bandwidth limit schema & helper

2018-01-30 Thread Wolfgang Bumiller 
This series should be the beginning for bringing some consistency into
the whole bandwidth/io/rate limiting we have all over the place
(vzdump.conf, replication, migration) and allow creating limits for
particular tasks, globally and per-storages, since those are usually
affected by eg. long tasks such as restoring bigger backups

See #853, #460.

-- 
2.11.0


___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] git repo with PVE/API2/LXC.pm

2018-01-30 Thread Geert Stappers 
On Tue, Jan 30, 2018 at 02:18:10PM +0100, Andreas Steinel wrote:
> On Tue, Jan 30, 2018 at 2:05 PM, Geert Stappers wrote:
> 
> > Which git repository has the file PVE/API2/LXC.pm ?
> >
> 
> Check via dpkg:
> 
> root@proxmox ~ > dpkg -S PVE/API2/LXC.pm
> pve-container: /usr/share/perl5/PVE/API2/LXC.pm
> 
> so
> 
} https://git.proxmox.com/?p=pve-container.git;f=src/PVE/API2/LXC.pm;hb=HEAD


Ah, Okay. So Debian package matches git repo name.


  git clone git://git.proxmox.com/git/pve-container.git


Yes, got it, thanks.


Groeten
Geert Stappers
-- 
Leven en laten leven
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ?

2018-01-30 Thread Alexandre DERUMIER 
>>I understand what your getting at, but to avoid confusion I would suggest
>>to skip the term symmetric routing here (which would suggest that data
>>to/from follows the same path),
>>routed traffic is usually very asymmetric.

I mean symetric because egress/ingress on the proxmox node where the vm is 
located.
of course if you have multiple routers/links, traffic could come back from 
another router.
But always on the same proxmox node.



- Mail original -
De: "Herman Bos" 
À: "pve-devel" 
Envoyé: Mardi 30 Janvier 2018 11:08:54
Objet: Re: [pve-devel] proxmox 2018 : add support for "virtual" network and 
network plugins ?

On Jan 30, 2018 09:19, "Alexandre DERUMIER"  wrote: 


2)if a routing protocol exist between the proxmox nodes and the router, the 
router can send directly 
traffic to the correct proxmox node. (symetric routing). 


I understand what your getting at, but to avoid confusion I would suggest 
to skip the term symmetric routing here (which would suggest that data 
to/from follows the same path), 
routed traffic is usually very asymmetric. 
___ 
pve-devel mailing list 
pve-devel@pve.proxmox.com 
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 

___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] git repo with PVE/API2/LXC.pm

2018-01-30 Thread Andreas Steinel 
On Tue, Jan 30, 2018 at 2:05 PM, Geert Stappers 
wrote:

> Which git repository has the file PVE/API2/LXC.pm ?
>

Check via dpkg:

root@proxmox ~ > dpkg -S PVE/API2/LXC.pm
pve-container: /usr/share/perl5/PVE/API2/LXC.pm

so


https://git.proxmox.com/?p=pve-container.git;a=history;f=src/PVE/API2/LXC.pm;h=733826e0f23ecd04d906e02eaf2ec4ef4fa212c3;hb=HEAD
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] git repo with PVE/API2/LXC.pm

2018-01-30 Thread Geert Stappers 
Hi,

Which git repository has the file PVE/API2/LXC.pm ?


Cheers
Geert Stappers
-- 
Leven en laten leven
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ?

2018-01-30 Thread Herman Bos 
On Jan 30, 2018 09:19, "Alexandre DERUMIER"  wrote:


2)if a routing protocol exist between the proxmox nodes and the router, the
router can send directly
traffic to the correct proxmox node. (symetric routing).


I understand what your getting at, but to avoid confusion I would suggest
to skip the term symmetric routing here (which would suggest that data
to/from follows the same path),
routed traffic is usually very asymmetric.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [PATCH manager] fix #1635: correctly change maxIds in ControllerSelector in wizard

2018-01-30 Thread Dominik Csapak 
we want to change the maxIds value even when not rendered, since
in the wizard, the controller can change from a different panel in the
tabpanel

Signed-off-by: Dominik Csapak 
---
 www/manager6/form/ControllerSelector.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/www/manager6/form/ControllerSelector.js 
b/www/manager6/form/ControllerSelector.js
index bc00eebf..66e41579 100644
--- a/www/manager6/form/ControllerSelector.js
+++ b/www/manager6/form/ControllerSelector.js
@@ -107,7 +107,7 @@ Ext.define('PVE.form.ControllerSelector', {
flex: 2,
listeners: {
change: function(t, value) {
-   if (!me.rendered || !value) {
+   if (!value) {
return;
}
var field = me.down('field[name=deviceid]');
-- 
2.11.0


___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] applied: [PATCH ha-manager 0/8] simulate and cope with unavailable cfs

2018-01-30 Thread Thomas Lamprecht 
applied

with Dominik's R-b and T-b tags and very minor whitespace cleanup.

Much thanks for the review and testing!!

___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ?

2018-01-30 Thread Alexandre DERUMIER 
I have thinked about the external gateway with vxlan ebgp, it's not so 
difficult,

1)if the upstream router can't do bgp or other routing protocol, we simply need 
to manage 
an ha vip on our side (vrrp) for the ingress traffic from the router and routed 
inside the vxlan.
the egress traffic will directly go out from the proxmox nodes.

This is asymetric routing.

This should work with a public hosting, like ovh. (you have your failover ip, 
which is the ha vip,
and your differents ripe block are routed in proxmox vxlan).



2)if a routing protocol exist between the proxmox nodes and the router, the 
router can send directly
traffic to the correct proxmox node. (symetric routing).


I have attached a schema to this mail.




- Mail original -
De: "aderumier" 
À: "dietmar" 
Cc: "pve-devel" 
Envoyé: Mardi 30 Janvier 2018 00:02:55
Objet: Re: [pve-devel] proxmox 2018 : add support for "virtual" network and 
network plugins ?

>>Looks we simply need a flexible plugin architecture ... 

I think, first, we can try to implement only the virtual network, without focus 
on external gateway. 


I'm seeing 2 good candidate: 

for linux bridge : vxlan ebgp-vpn 
for ovs : ovn network 
(http://openvswitch.org/support/slides/OVN_LinuxCon_Toronto.pdf) 


Both have almost the same architecture. 

-a distributed controlplane controller. (vxlan ebgp: a routing daemon like 
frr/quagga, ovn : ovn controller). 
It can be deployed on all proxmox nodes 

-a distributed "anycast" local router 
-vm can used them as gateway. we can implement dhcp,dns,cloudinit. 
-we can get ip/mac from control plane. (could be used to add auto ipfiltering 
on vm firewall for example, maybe other stuff) 

So 

1) implement the "network" create (create bridge/ovs, configure the 
controllers) 
2) configure the local router and services 



When this is implemented, we could focus on external network access. 

- ovn need a gateway node 
- linux evpn-bgp can peer with external router if bgp is supported, 
or use 1 gateway node with a simple default gw.(+ a backup gateway node) 

then implement s-nat and floating ip as option if user want them. 


and finally (next year ;) maybe other stuff like loadbalancing as a service, 
vpn as a service, 


what do you think about this ? 


- Mail original - 
De: "dietmar"  
À: "Alexandre Derumier" , "pve-devel" 
 
Envoyé: Lundi 29 Janvier 2018 12:22:09 
Objet: Re: [pve-devel] proxmox 2018 : add support for "virtual" network and 
network plugins ? 

> It's not difficult if we can do bgp to the router. but I think Dietmar want 
> something 
> for user with a simple router/default gw. (so with some proxy-arp trick). 

No, I still do not know what I want - too many options ;-) 

Looks we simply need a flexible plugin architecture ... 

___ 
pve-devel mailing list 
pve-devel@pve.proxmox.com 
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 

___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ?

2018-01-30 Thread Alexandre DERUMIER 

I have thinked about the external gateway with vxlan ebgp, it's not so 
difficult, 

1)if the upstream router can't do bgp or other routing protocol, we simply need 
to manage 
an ha vip on our side (vrrp) for the ingress traffic from the router and routed 
inside the vxlan. 
the egress traffic will directly go out from the proxmox nodes. 

This is asymetric routing. 

This should work with a public hosting, like ovh. (you have your failover ip, 
which is the ha vip, 
and your differents ripe block are routed in proxmox vxlan). 



2)if a routing protocol exist between the proxmox nodes and the router, the 
router can send directly 
traffic to the correct proxmox node. (symetric routing). 


I have attached an svg schema to this mail. 




- Mail original - 
De: "aderumier"  
À: "dietmar"  
Cc: "pve-devel"  
Envoyé: Mardi 30 Janvier 2018 00:02:55 
Objet: Re: [pve-devel] proxmox 2018 : add support for "virtual" network and 
network plugins ? 

>>Looks we simply need a flexible plugin architecture ... 

I think, first, we can try to implement only the virtual network, without focus 
on external gateway. 


I'm seeing 2 good candidate: 

for linux bridge : vxlan ebgp-vpn 
for ovs : ovn network 
(http://openvswitch.org/support/slides/OVN_LinuxCon_Toronto.pdf) 


Both have almost the same architecture. 

-a distributed controlplane controller. (vxlan ebgp: a routing daemon like 
frr/quagga, ovn : ovn controller). 
It can be deployed on all proxmox nodes 

-a distributed "anycast" local router 
-vm can used them as gateway. we can implement dhcp,dns,cloudinit. 
-we can get ip/mac from control plane. (could be used to add auto ipfiltering 
on vm firewall for example, maybe other stuff) 

So 

1) implement the "network" create (create bridge/ovs, configure the 
controllers) 
2) configure the local router and services 



When this is implemented, we could focus on external network access. 

- ovn need a gateway node 
- linux evpn-bgp can peer with external router if bgp is supported, 
or use 1 gateway node with a simple default gw.(+ a backup gateway node) 

then implement s-nat and floating ip as option if user want them. 


and finally (next year ;) maybe other stuff like loadbalancing as a service, 
vpn as a service, 


what do you think about this ? 


- Mail original - 
De: "dietmar"  
À: "Alexandre Derumier" , "pve-devel" 
 
Envoyé: Lundi 29 Janvier 2018 12:22:09 
Objet: Re: [pve-devel] proxmox 2018 : add support for "virtual" network and 
network plugins ? 

> It's not difficult if we can do bgp to the router. but I think Dietmar want 
> something 
> for user with a simple router/default gw. (so with some proxy-arp trick). 

No, I still do not know what I want - too many options ;-) 

Looks we simply need a flexible plugin architecture ... 

___ 
pve-devel mailing list 
pve-devel@pve.proxmox.com 
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 

___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel