[pve-devel] [PATCH pve-manager] api2 : network : use vtysh for frr reload instead systemd

2019-09-09 Thread Alexandre Derumier 
avoid extra dep on frr-pythontools and parse error messages

Signed-off-by: Alexandre Derumier 
---
 PVE/API2/Network.pm | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/PVE/API2/Network.pm b/PVE/API2/Network.pm
index ac5571a7..fa605ba7 100644
--- a/PVE/API2/Network.pm
+++ b/PVE/API2/Network.pm
@@ -578,8 +578,15 @@ __PACKAGE__->register_method({
};
PVE::Tools::run_command(['ifreload', '-a'], errfunc => $err);
 
-   if ($frr_config && -e "/usr/lib/frr/frr-reload.py") {
-   PVE::Tools::run_command(['systemctl', 'reload', 'frr']);
+   my $err_frr = sub {
+   my $line = shift;
+   if ($line =~ /^line (\S+)/) {
+   print "$line \n";
+   }
+   };
+
+   if ($frr_config && -e "/usr/bin/vtysh") {
+   PVE::Tools::run_command(['/usr/bin/vtysh', '-m', '-f', 
'/etc/frr/frr.conf'], outfunc => {}, errfunc => $err_frr);
}
};
return $rpcenv->fork_worker('srvreload', 'networking', $authuser, 
$worker);
-- 
2.20.1

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

Re: [pve-devel] [PATCH qemu-server 4/7] Add CustomCPUConfig for storing/parsing custom CPU models

2019-09-09 Thread Fabian Grünbichler 
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> Inherits from SectionConfig to provide base parsing infrastructure.
> 
> Use with helper functions:
> * config_from_file gives bless'd config
> * get_model_by_name returns a "formatted" hash for a single CPU model
> * config_to_file writes changes back
> 
> File reads are cached in a local hash.

high-level:

use cfs_register/write/read_file please (it's our mechanism for handling 
config files on pmxcfs after all ;))

is there a reason you need a class-like interface here? we usually use 
that if we want to have multiple implementations of a certain interface 
with a common shared code base, but that is not the case here..

> 
> Signed-off-by: Stefan Reiter 
> ---
> 
> This will definitely require some sort of versioning mechanism, otherwise CPU
> definitions could be changed after starting a VM, thus breaking live-migration
> by starting the migration-target with different parameters.
> 
> Hints, ideas, recommendations?

versioning is one possibility (cumbersome with SectionConfig though).

another would be to retrieve the CPU model from the running Qemu 
instance, and convert that back to a '-cpu ...' string for starting the 
target instance. if nothing hot-pluggable can change the generated -cpu 
string, we could also record that somewhere (or take it from 
/proc/$pid/cmdline) and override the target instance with that.

>  PVE/QemuServer/CustomCPUConfig.pm | 129 ++
>  PVE/QemuServer/Makefile   |   1 +
>  2 files changed, 130 insertions(+)
>  create mode 100644 PVE/QemuServer/CustomCPUConfig.pm
> 
> diff --git a/PVE/QemuServer/CustomCPUConfig.pm 
> b/PVE/QemuServer/CustomCPUConfig.pm
> new file mode 100644
> index 000..87ba9e6
> --- /dev/null
> +++ b/PVE/QemuServer/CustomCPUConfig.pm
> @@ -0,0 +1,129 @@
> +package PVE::QemuServer::CustomCPUConfig;
> +
> +use strict;
> +use warnings;
> +use PVE::Tools qw(file_get_contents file_set_contents);
> +
> +use base qw(PVE::SectionConfig);
> +
> +my $defaultData = {
> +propertyList => {
> + basemodel => {
> + description => "Emulated CPU type to inherit defaults from.",
> + type => 'string',
> + format_description => 'string',
> + default => 'kvm64',

should have the same pattern/format as QemuServer's $cpu_fmt->{cputype}.
in other words, it probably makes sense to extract and re-use that ;)

> + },
> + flags => {
> + description => "List of additional CPU flags separated by ';'."
> +  . " Use '+FLAG' to enable, '-FLAG' to disable a flag."
> +  . " Supports all flags supported by QEMU/KVM.",
> + format_description => '+FLAG[;-FLAG...]',
> + type => 'string',
> + pattern => qr/[+-][a-zA-Z0-9\-_\.]+(;[+-][a-zA-Z0-9\-_\.]+)*/,

same here (different description, please just use a single definition 
for both instances)

> + optional => 1,
> + },
> + 'phys-bits' => {
> + type => 'integer',
> + minimum => 1,
> + maximum => 64,
> + optional => 1,
> + description => "The physical memory bits that are reported to the 
> guest OS. Must be smaller or equal to the host.",

this one might make sense to also allow in the regular, per-VM 'cpu' 
option (and then we could again re-use the definition)

> + },
> + 'host-phys-bits' => {
> + type => 'boolean',
> + default => 0,
> + description => "Whether to report the host's physical memory bits. 
> Overrides 'phys-bits' when set.",
> + },

same

> + vendor => {
> + type => 'string',
> + enum => [qw(default AuthenticAMD GenuineIntel)],
> + default => 'default',
> + description => "The CPU vendor to report. 'default' uses the 
> host's.",
> + },
> +}

this probably only makes sense for the custom types. the default value 
means that you never inherit the vendor from your basemodel - is that 
intended?

there are two more from the regular one that we might want to include in 
custom ones as well:

hidden
hv-vendor-id

I am not sure whether just moving some format definitions, or moving 
all/most CPU related stuff to a new module (e.g., 
QemuServer/CPUConfig.pm instead of QemuServer/CustomCPUConfig.pm) is 
more clean / feasible. the latter probably would require moving some 
helpers from QemuServer.pm to another new module as well, as they'd be 
used by the CPU module and QemuServer.pm

I think we all agree that QemuServer.pm is way too big, so a patch 
(series) that adds new features and reduces that bloat would be more 
than welcome :D but if you think it's too much for this series, we can 
also do it as a follow-up since it's mostly about moving code and format 
definitions.

> +};
> +
> +sub private {
> +return $defaultData;
> +}
> +
> +sub options {
> +return {
> + basemodel => { optional => 1 },
> + flags => { optional => 1 },
> + 'phys-bits' => { optional => 1 },
> +

Re: [pve-devel] [PATCH qemu-server 6/7] Handle CPU flags defined in custom CPU type

2019-09-09 Thread Fabian Grünbichler 
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> Special care is taken not to overwrite any special flags, or ones
> manually set on the VM by the user. We warn if a flag is overruled.

hmm. I am unsure whether I like that behaviour or not. it's a bit 
strange that VM specific flags get applied earlier, and then we skip 
those from the models instead of just switching the order around.

maybe we need some other intermediate data structure, or some helper 
methods?

the following seems more logical to me:

1.) add flags from custom model
2.) add flags from VM config
3.) (selectively) add auto-generated flags (based on other settings, OS, ..)

at each step we want to remove conflicting flags from before (this would 
be where a different datastructure or a helper would come into play). 
maybe some of the auto-generated flags should not override explicitly 
set ones, but be skipped instead (at least for explicit negative 
flags, to allow opt-out).

> 
> Signed-off-by: Stefan Reiter 
> ---
>  PVE/QemuServer.pm | 26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index 417bea8..7cc1674 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -3597,6 +3597,7 @@ sub get_cpu_options {
>  }
>  my $hv_vendor_id;
>  my $custom_cpu_config;
> +my @vm_specific_flags;
>  if (my $cputype = $conf->{cpu}) {
>   my $cpuconf = PVE::JSONSchema::parse_property_string($cpu_fmt, $cputype)
>   or die "Cannot parse cpu description: $cputype\n";
> @@ -3624,7 +3625,8 @@ sub get_cpu_options {
>   $hv_vendor_id = $cpuconf->{'hv-vendor-id'};
>  
>   if (defined(my $flags = $cpuconf->{flags})) {
> - push @$cpuFlags, split(";", $flags);
> + @vm_specific_flags = split(";", $flags);
> + push @$cpuFlags, @vm_specific_flags;
>   }
>  }
>  
> @@ -3649,6 +3651,28 @@ sub get_cpu_options {
>  
>  push @$cpuFlags, 'kvm=off' if $kvm_off;
>  
> +if (defined($custom_cpu_config) && defined($custom_cpu_config->{flags})) 
> {
> + my @custom_flags = split(/;/, $custom_cpu_config->{flags});
> + foreach my $flag (@custom_flags) {
> + # find index of $flag in $cpuFlags while ignoring prefix [+-=]
> + $flag =~ m/^[+-=]?(.*)$/;
> + my $match_flag = $1;
> + my @match_index = grep { $cpuFlags->[$_] =~ m/[+-=]?\Q$match_flag/ }
> + 0..scalar(@$cpuFlags)-1;
> +
> + if (@match_index) {
> + my $other_flag = $cpuFlags->[$match_index[0]];
> + # warn only if prefix differs and flag is not vm specific
> + warn "warning: custom CPU model flag '$flag' overruled by 
> '$other_flag' due to either default handling of basemodel or selected OS.\n"

I don't understand that message, so probably users won't either ;) but I 
think the messages would be more clear if we apply the auto-generated 
flags last:

"unsetting flag '$other_flag', not compatible with " (OS foo, CPU bar, 
...)
"not setting flag '$flag', explicit '$other_flag' found." (explicit 
opt-out for auto-generated flags via VM or CPU model config)

> + if (substr $other_flag, 0, 1) ne (substr $flag, 0, 1) &&
> + (!@vm_specific_flags ||
> + !grep(m/[+-=]?\Q$match_flag/, @vm_specific_flags));
> + } else {
> + push(@$cpuFlags, $flag);
> + }
> + }
> +}
> +
>  if (defined($custom_cpu_config) && (my $custom_vendor = 
> $custom_cpu_config->{vendor})) {
>   push @$cpuFlags, "vendor=${custom_vendor}"
>   if $custom_vendor ne 'default';
> -- 
> 2.20.1
> 
> 
> ___
> 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] [PATCH qemu-server 5/7] Support custom CPU types in get_cpu_options

2019-09-09 Thread Fabian Grünbichler 
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> Supports custom basemodels (model shown to QEMU, i.e. must be a default

nit: s/shown/known/ ?

high-level: if we allow basing custom models on other custom models, 
wouldn't we need to compute an effective model first, and then use that?

e.g., if I define the following:

cpu-model: leaf
  basemodel: intermediate
  vendor: intel
  flags: +aes,+pcid
  host-phys-bits: 1

cpu-model: intermediate1
  vendor: amd
  basemodel: intermediate2
  flags: -aes;-ssbd
  phys-bits: 32

cpu-model: intermediate2
  vendor: amd
  basemodel: phenom
  flags: +ssbd;+md-clear
  phys-bits: 48

I'd expect the end result to be:

vendor: intel
flags: phenom +aes +pcid -ssbd +md-clear
phys-bits: host (overriding the one from intermediate)

(ignore that those flags don't make much sense ;))

this patch (series) only looks at the leaf and the last basemodel in the 
chain, and ignores everything inbetween. vendor also can't be 
'inherited' from basemodel, because it is always set.

we can either go full-blown 'inherit properties across multiple 
basemodels', or we limit ourselves to 'basemodel must be a regular cpu 
model'. the former is of course more flexible (allowing stuff like 
re-using a custom model and just adding one flag, without duplication), 
but the latter is a lot more simple (one additional level to check 
instead of recursive walk, loop and conflict detection, no nested 
versioning needed, etc.pp.). something inbetween like the current patch 
does is probably confusing.

> model), vendors and (host-)phys-bits for VMs with large amounts of RAM
> (see bug #2318).
> 
> Signed-off-by: Stefan Reiter 
> ---
>  PVE/QemuServer.pm | 32 +++-
>  1 file changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index 97fa955..417bea8 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -37,6 +37,7 @@ use PVE::QemuServer::PCI qw(print_pci_addr print_pcie_addr);
>  use PVE::QemuServer::Memory;
>  use PVE::QemuServer::USB qw(parse_usb_device);
>  use PVE::QemuServer::Cloudinit;
> +use PVE::QemuServer::CustomCPUConfig;
>  use PVE::SysFSTools;
>  use PVE::Systemd;
>  use Time::HiRes qw(gettimeofday);
> @@ -3595,10 +3596,30 @@ sub get_cpu_options {
>   $cpu = 'cortex-a57';
>  }
>  my $hv_vendor_id;
> +my $custom_cpu_config;
>  if (my $cputype = $conf->{cpu}) {
>   my $cpuconf = PVE::JSONSchema::parse_property_string($cpu_fmt, $cputype)
>   or die "Cannot parse cpu description: $cputype\n";
>   $cpu = $cpuconf->{cputype};
> +
> + if (!defined($cpu_vendor_list->{$cpu})) {
> + # not a default CPU model, read config and see if $cpu is name of
> + # a custom model
> + my $cpu_models = 
> PVE::QemuServer::CustomCPUConfig::config_from_file();
> + if ($cpu_models && ($custom_cpu_config = 
> $cpu_models->get_model_by_name($cpu))) {
> + $cpu = $custom_cpu_config->{basemodel};
> +
> + # 'basemodel' could be custom as well
> + while (!defined($cpu_vendor_list->{$cpu})) {
> + my $custom_base = $cpu_models->get_model_by_name($cpu);
> + die "unknown CPU basemodel: $cpu\n" if !$custom_base;
> + $cpu = $custom_base->{basemodel};
> + }

possible endless loop

> + } else {
> + die "unknown CPU model (neither default nor custom): $cpu\n";
> + }
> + }
> +
>   $kvm_off = 1 if $cpuconf->{hidden};
>   $hv_vendor_id = $cpuconf->{'hv-vendor-id'};
>  
> @@ -3628,13 +3649,22 @@ sub get_cpu_options {
>  
>  push @$cpuFlags, 'kvm=off' if $kvm_off;
>  
> -if (my $cpu_vendor = $cpu_vendor_list->{$cpu}) {
> +if (defined($custom_cpu_config) && (my $custom_vendor = 
> $custom_cpu_config->{vendor})) {
> + push @$cpuFlags, "vendor=${custom_vendor}"
> + if $custom_vendor ne 'default';
> +} elsif (my $cpu_vendor = $cpu_vendor_list->{$cpu}) {
>   push @$cpuFlags, "vendor=${cpu_vendor}"
>   if $cpu_vendor ne 'default';
>  } elsif ($arch ne 'aarch64') {
>   die "internal error"; # should not happen
>  }
>  
> +$cpu .= ",host-phys-bits=true"
> + if defined($custom_cpu_config) && 
> $custom_cpu_config->{'host-phys-bits'};
> +$cpu .= ",phys-bits=$custom_cpu_config->{'phys-bits'}"
> + if defined($custom_cpu_config) && $custom_cpu_config->{'phys-bits'}
> + && !$custom_cpu_config->{'host-phys-bits'};
> +
>  $cpu .= "," . join(',', @$cpuFlags) if scalar(@$cpuFlags);
>  
>  return ('-cpu', $cpu);
> -- 
> 2.20.1
> 
> 
> ___
> 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] [PATCH qemu-server 7/7] Allow custom CPU types in API

2019-09-09 Thread Fabian Grünbichler 
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> Custom CPU types can be specified via the API, but to prevent arbitrary
> ones we have to manually check if the given model exists (as default or
> custom).
> 
> Signed-off-by: Stefan Reiter 
> ---
>  PVE/QemuServer.pm | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index 7cc1674..5bdd729 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -187,7 +187,8 @@ my $cpu_fmt = {
>  cputype => {
>   description => "Emulated CPU type.",
>   type => 'string',
> - enum => [ sort { "\L$a" cmp "\L$b" } keys %$cpu_vendor_list ],
> + format_description => 'string',
> + pattern => qr/[0-9a-zA-Z\-_]+/,

this removes information from our API schema dumps (e.g., API viewer, 
'man qm', ...). we could at least put it into format_description with 
some additional sentence referencing custom types)

>   default => 'kvm64',
>   default_key => 1,
>  },
> @@ -215,6 +216,32 @@ my $cpu_fmt = {
>  },
>  };
>  
> +# we need to verify the "cpu" property of the VM config manually, since a
> +# syntactially valid, but non-existant CPU model might be given
> +PVE::JSONSchema::register_format('pve-cpu-conf', \&verify_cpu);
> +sub verify_cpu {
> +my ($cpu, $noerr) = @_;
> +
> +my $conf;
> +eval {
> + $conf = PVE::JSONSchema::parse_property_string($cpu_fmt, $cpu);
> +};
> +if ($@) {
> + die $@ if !$noerr;
> + return undef;
> +}
> +
> +my $cputype = $conf->{cputype};
> +
> +return $cpu if defined($cpu_vendor_list->{$cputype});
> +
> +my $cpu_models = PVE::QemuServer::CustomCPUConfig::config_from_file();
> +return $cpu if $cpu_models && $cpu_models->get_model_by_name($cputype);

and here I just realized something that affects the whole patch series - 
we probably need to namespace the custom cpu models somehow when 
referencing them in the config. otherwise a future QEMU version might 
add an additional CPU model that conflicts with a defined custom one.

we can either add a flag to 'cpu', just prefix the names in the VM 
config, or prefix the names both in the VM config and in the CPU model 
config. all approaches have pros and cons - maybe there is some other 
clever way to avoid this problem?

> +
> +die "cputype '$cputype' not found\n" if !$noerr;
> +return undef;
> +}
> +
>  my $watchdog_fmt = {
>  model => {
>   default_key => 1,
> @@ -587,7 +614,7 @@ EODESCR
>   optional => 1,
>   description => "Emulated CPU type.",
>   type => 'string',
> - format => $cpu_fmt,
> + format => 'pve-cpu-conf',
>  },
>  parent => get_standard_option('pve-snapshot-name', {
>   optional => 1,
> -- 
> 2.20.1
> 
> 
> ___
> 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] [PATCH 0/7] Add basics for custom CPU models

2019-09-09 Thread Fabian Grünbichler 
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> Based on the RFC and following on- and off-list discussion about custom CPU
> models [0].
> 
> In essence, this revised patch allows a user to specify custom CPU models in
> /etc/pve/cpu-models.conf (section-config style [1]), where VMs using that CPU
> model inherit details from the definition. This removes any fragile
> "auto-magical" CPU flag detection, while still giving the user a way to create
> VMs with the best possible subset of CPU features maintaining live-migration
> compatibility.
> 
> Includes the infrastructure for broadcasting supported CPU flags for each
> cluster-node via the key-value store - this is not necessary for the
> custom-cpu feature in particular, but I think could prove useful for
> implementing the GUI part (e.g. show the user which flags are supported on 
> which
> nodes).
> 
> I intentionally wanted to send this series before starting any GUI or new API
> work, to get some feedback if this approach works better than the cluster-cpu
> one.
> 
> [0]: https://pve.proxmox.com/pipermail/pve-devel/2019-July/038268.html
> [1]: e.g.:
> cpu-model: custom-cpu-name
> host-phys-bits 1
> flags +aes;+avx;+avx2
> basemodel kvm64

some more detailed feedback on individual patches, here a summary of open
questions from my side:
- nested models, or just custom models derived from qemu-provided base model
- namespacing of custom models? where, how, ...?
- versioning/live-migration

and some things for the 'future' part:
- permissions? who can create a custom model?
- is there a security risk associated with any of the flags (besides 
  making the VM itself easier to attack)? do we want to have some global 
  whitelist of flags that we have closely looked at and deemed 
  unproblematic?
- do we want to make the whole CRUD of models root/admin only (probably 
  need to, unless we want to create permission paths for CPU models?)

I like the direction this is going, although a lot of the magic will be 
in how to make it straight-forward to generate a new model using the 
available information, which is not yet part of this series ;)

> 
> 
> qemu: Stefan Reiter (1):
>   Trigger pve-api-updates on update
> 
>  debian/triggers | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 debian/triggers
> 
> manager: Stefan Reiter (1):
>   Broadcast supported CPU flags
> 
>  PVE/Service/pvestatd.pm | 28 ++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
> 
> qemu-server: Stefan Reiter (5):
>   Add QEMU CPU flag querying helpers
>   Add CustomCPUConfig for storing/parsing custom CPU models
>   Support custom CPU types in get_cpu_options
>   Handle CPU flags defined in custom CPU type
>   Allow custom CPU types in API
> 
>  PVE/QemuServer.pm | 173 +-
>  PVE/QemuServer/CustomCPUConfig.pm | 129 ++
>  PVE/QemuServer/Makefile   |   1 +
>  3 files changed, 299 insertions(+), 4 deletions(-)
>  create mode 100644 PVE/QemuServer/CustomCPUConfig.pm
> 
> -- 
> 2.20.1
> 
> ___
> 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

[pve-devel] [PATCH qemu-server] add check to resize disk if current size could not be determined

2019-09-09 Thread Tim Marx 
This check ensures that disks aren't unintentionally shrunken, if the
size is zero due to an underlying problem.
---
 PVE/API2/Qemu.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 245de80..a0692da 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -3511,6 +3511,8 @@ __PACKAGE__->register_method({
PVE::Storage::activate_volumes($storecfg, [$volid]);
my $size = PVE::Storage::volume_size_info($storecfg, $volid, 5);
 
+   die "volume $volid does not exists\n" if !$size;
+
die "internal error" if $sizestr !~ 
m/^(\+)?(\d+(\.\d+)?)([KMGT])?$/;
my ($ext, $newsize, $unit) = ($1, $2, $4);
if ($unit) {
-- 
2.20.1

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

[pve-devel] [PATCH container 1/2] whitespace cleanup

2019-09-09 Thread Tim Marx 
---
 src/PVE/API2/LXC.pm | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
index 6ddff9c..faec445 100644
--- a/src/PVE/API2/LXC.pm
+++ b/src/PVE/API2/LXC.pm
@@ -35,7 +35,7 @@ BEGIN {
 
 __PACKAGE__->register_method ({
 subclass => "PVE::API2::LXC::Config",
-path => '{vmid}/config', 
+path => '{vmid}/config',
 });
 
 __PACKAGE__->register_method ({
@@ -212,7 +212,7 @@ __PACKAGE__->register_method({
if ($restore) {
# fixme: limit allowed parameters
}
-   
+
my $force = extract_param($param, 'force');
 
if (!($same_container_exists && $restore && $force)) {
@@ -257,9 +257,9 @@ __PACKAGE__->register_method({
 
my $archive;
if ($ostemplate eq '-') {
-   die "pipe requires cli environment\n" 
-   if $rpcenv->{type} ne 'cli'; 
-   die "pipe can only be used with restore tasks\n" 
+   die "pipe requires cli environment\n"
+   if $rpcenv->{type} ne 'cli';
+   die "pipe can only be used with restore tasks\n"
if !$restore;
$archive = '-';
die "restore from pipe requires rootfs parameter\n" if 
!defined($param->{rootfs});
@@ -675,7 +675,7 @@ __PACKAGE__->register_method({
};
 
my $realcmd = sub { PVE::LXC::Config->lock_config($vmid, $code); };
-   
+
return $rpcenv->fork_worker('vzdestroy', $vmid, $authuser, $realcmd);
 }});
 
-- 
2.20.1

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

[pve-devel] [PATCH container 2/2] add check to resize disk if current size could not be determined

2019-09-09 Thread Tim Marx 
This check ensures that disks aren't unintentionally shrunken, if the
size is zero due to an underlying problem.
---
 src/PVE/API2/LXC.pm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
index faec445..f08b6a5 100644
--- a/src/PVE/API2/LXC.pm
+++ b/src/PVE/API2/LXC.pm
@@ -1639,6 +1639,9 @@ __PACKAGE__->register_method({
PVE::Storage::activate_volumes($storage_cfg, [$volid]);
 
my $size = PVE::Storage::volume_size_info($storage_cfg, $volid, 5);
+
+   die "volume $volid does not exists\n" if !$size;
+
$newsize += $size if $ext;
$newsize = int($newsize);
 
-- 
2.20.1

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

[pve-devel] [PATCH novnc 1/2] update submodule to v1.1.0

2019-09-09 Thread Dominik Csapak 
Signed-off-by: Dominik Csapak 
---
the mirror has ofc to be updated
 novnc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/novnc b/novnc
index f9b6d76..9fe2fd0 16
--- a/novnc
+++ b/novnc
@@ -1 +1 @@
-Subproject commit f9b6d7665d01f31a6c0c675ec3f604e99f6b2341
+Subproject commit 9fe2fd04d4eeda0d5a360009453861803ba0ca84
-- 
2.20.1


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

[pve-devel] [PATCH novnc 2/2] rebase patches on v1.1.0

2019-09-09 Thread Dominik Csapak 
Signed-off-by: Dominik Csapak 
---
i tested around a bit, everything seemed to work

 .../0001-add-pve-specific-js-code.patch   |  78 +--
 ...002-add-custom-fbresize-event-on-rfb.patch |  19 ++-
 ...nge-scaling-when-toggling-fullscreen.patch |  15 +--
 debian/patches/0004-add-pve-style.patch   |  23 ++--
 debian/patches/0005-remove-vnc-logos.patch|  30 ++---
 ...ge-src-directory-for-images-js-files.patch | 124 +-
 .../patches/0007-add-pve-vnc-commands.patch   |  11 +-
 ...add-replaceable-snippets-in-vnc.html.patch |  23 ++--
 .../0009-decrease-animation-time.patch|  21 ++-
 debian/patches/0010-use-only-app.js.patch |  11 +-
 .../0011-add-localCursor-setting-to-rfb.patch |  55 
 .../0012-pass-custom-command-to-vnc.patch |  14 +-
 12 files changed, 195 insertions(+), 229 deletions(-)

diff --git a/debian/patches/0001-add-pve-specific-js-code.patch 
b/debian/patches/0001-add-pve-specific-js-code.patch
index c03901b..44e62a5 100644
--- a/debian/patches/0001-add-pve-specific-js-code.patch
+++ b/debian/patches/0001-add-pve-specific-js-code.patch
@@ -1,7 +1,7 @@
-From 9607c6496f643fde5435fa799702961dd22bf81a Mon Sep 17 00:00:00 2001
+From  Mon Sep 17 00:00:00 2001
 From: Dominik Csapak 
 Date: Tue, 13 Dec 2016 16:11:35 +0100
-Subject: [PATCH 01/10] add pve specific js code
+Subject: [PATCH 01/12] add pve specific js code
 
 this adds a es6 module 'PVEUI' which we use for defining the pve related
 methods (API2Request, etc.)
@@ -11,10 +11,10 @@ autoresizing, commandstoggle, etc.
 
 Signed-off-by: Dominik Csapak 
 ---
- app/pve.js | 418 +
- app/ui.js  |  71 +--
+ app/pve.js | 418 +
+ app/ui.js  |  66 +++--
  vnc.html   |  10 +-
- 3 files changed, 482 insertions(+), 17 deletions(-)
+ 3 files changed, 480 insertions(+), 14 deletions(-)
  create mode 100644 app/pve.js
 
 diff --git a/app/pve.js b/app/pve.js
@@ -442,10 +442,10 @@ index 000..e2c37fb
 +},
 +};
 diff --git a/app/ui.js b/app/ui.js
-index 4fe2a3f..59f7cca 100644
+index 17ec48d..4683c02 100644
 --- a/app/ui.js
 +++ b/app/ui.js
-@@ -17,6 +17,7 @@ import keysyms from "../core/input/keysymdef.js";
+@@ -16,6 +16,7 @@ import keysyms from "../core/input/keysymdef.js";
  import Keyboard from "../core/input/keyboard.js";
  import RFB from "../core/rfb.js";
  import * as WebUtil from "./webutil.js";
@@ -453,15 +453,16 @@ index 4fe2a3f..59f7cca 100644
  
  const UI = {
  
-@@ -58,6 +59,7 @@ const UI = {
+@@ -54,6 +55,8 @@ const UI = {
  // Render default UI and initialize settings menu
- start(callback) {
+ start() {
  
 +UI.PVE = new PVEUI(UI);
- // Setup global variables first
- UI.isSafari = (navigator.userAgent.indexOf('Safari') !== -1 &&
-navigator.userAgent.indexOf('Chrome') === -1);
-@@ -89,6 +91,9 @@ const UI = {
++
+ UI.initSettings();
+ 
+ // Translate the DOM
+@@ -81,6 +84,9 @@ const UI = {
  UI.addConnectionControlHandlers();
  UI.addClipboardHandlers();
  UI.addSettingsHandlers();
@@ -471,7 +472,7 @@ index 4fe2a3f..59f7cca 100644
  document.getElementById("noVNC_status")
  .addEventListener('click', UI.hideStatus);
  
-@@ -97,23 +102,19 @@ const UI = {
+@@ -89,19 +95,15 @@ const UI = {
  
  UI.openControlbar();
  
@@ -491,18 +492,11 @@ index 4fe2a3f..59f7cca 100644
 -// Show the connect panel on first load unless autoconnecting
 -UI.openConnectPanel();
 -}
- 
--if (typeof callback === "function") {
--callback(UI.rfb);
--}
-+if (typeof callback === "function") {
-+callback(UI.rfb);
-+}
 +});
- },
  
- initFullscreen() {
-@@ -156,9 +157,10 @@ const UI = {
+ return Promise.resolve(UI.rfb);
+ },
+@@ -145,9 +147,10 @@ const UI = {
  /* Populate the controls if defaults are provided in the URL */
  UI.initSetting('host', window.location.hostname);
  UI.initSetting('port', port);
@@ -513,16 +507,16 @@ index 4fe2a3f..59f7cca 100644
 +UI.initSetting('autoresize', true);
  UI.initSetting('shared', true);
  UI.initSetting('view_only', false);
- UI.initSetting('path', 'websockify');
-@@ -342,6 +344,7 @@ const UI = {
+ UI.initSetting('show_dot', false);
+@@ -334,6 +337,7 @@ const UI = {
  UI.addSettingChangeHandler('resize');
- UI.addSettingChangeHandler('resize', UI.enableDisableViewClip);
  UI.addSettingChangeHandler('resize', UI.applyResizeMode);
+ UI.addSettingChangeHandler('resize', UI.updateViewClip);
 +UI.addSettingChangeHandler('autoresize');
  UI.addSettingChangeHandler('view_clip');
  UI.addSettingChangeHandler('view_clip', UI.updateViewClip);
  UI.addSe

[pve-devel] [PATCH v2 qemu-server] add check to resize disk if current size could not be determined

2019-09-09 Thread Tim Marx 
This check ensures that disks aren't unintentionally shrunken, if the
size is zero due to an underlying problem.
---
* fix indentation

 PVE/API2/Qemu.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 245de80..e6f3cce 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -3511,6 +3511,8 @@ __PACKAGE__->register_method({
PVE::Storage::activate_volumes($storecfg, [$volid]);
my $size = PVE::Storage::volume_size_info($storecfg, $volid, 5);

+   die "volume $volid does not exists\n" if !$size;
+
die "internal error" if $sizestr !~ 
m/^(\+)?(\d+(\.\d+)?)([KMGT])?$/;
my ($ext, $newsize, $unit) = ($1, $2, $4);
if ($unit) {
--
2.20.1

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

[pve-devel] [PATCH v2 container 1/2] whitespace cleanup

2019-09-09 Thread Tim Marx 
---
 src/PVE/API2/LXC.pm | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
index 6ddff9c..faec445 100644
--- a/src/PVE/API2/LXC.pm
+++ b/src/PVE/API2/LXC.pm
@@ -35,7 +35,7 @@ BEGIN {
 
 __PACKAGE__->register_method ({
 subclass => "PVE::API2::LXC::Config",
-path => '{vmid}/config', 
+path => '{vmid}/config',
 });
 
 __PACKAGE__->register_method ({
@@ -212,7 +212,7 @@ __PACKAGE__->register_method({
if ($restore) {
# fixme: limit allowed parameters
}
-   
+
my $force = extract_param($param, 'force');
 
if (!($same_container_exists && $restore && $force)) {
@@ -257,9 +257,9 @@ __PACKAGE__->register_method({
 
my $archive;
if ($ostemplate eq '-') {
-   die "pipe requires cli environment\n" 
-   if $rpcenv->{type} ne 'cli'; 
-   die "pipe can only be used with restore tasks\n" 
+   die "pipe requires cli environment\n"
+   if $rpcenv->{type} ne 'cli';
+   die "pipe can only be used with restore tasks\n"
if !$restore;
$archive = '-';
die "restore from pipe requires rootfs parameter\n" if 
!defined($param->{rootfs});
@@ -675,7 +675,7 @@ __PACKAGE__->register_method({
};
 
my $realcmd = sub { PVE::LXC::Config->lock_config($vmid, $code); };
-   
+
return $rpcenv->fork_worker('vzdestroy', $vmid, $authuser, $realcmd);
 }});
 
-- 
2.20.1

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

[pve-devel] [PATCH v2 container 2/2] add check to resize disk if current size could not be determined

2019-09-09 Thread Tim Marx 
This check ensures that disks aren't unintentionally shrunken, if the
size is zero due to an underlying problem.
---
* fix indentation
 src/PVE/API2/LXC.pm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
index faec445..8006f4d 100644
--- a/src/PVE/API2/LXC.pm
+++ b/src/PVE/API2/LXC.pm
@@ -1639,6 +1639,9 @@ __PACKAGE__->register_method({
PVE::Storage::activate_volumes($storage_cfg, [$volid]);

my $size = PVE::Storage::volume_size_info($storage_cfg, $volid, 5);
+
+   die "volume $volid does not exists\n" if !$size;
+
$newsize += $size if $ext;
$newsize = int($newsize);

--
2.20.1

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

[pve-devel] proxmox5: can you bump kernel to ubuntu 4.15.0-59 ? (mellanox bug)

2019-09-09 Thread Alexandre DERUMIER 
Hi,

I have a bug on last pve-kernel 4.15 related to mellanox nic

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840854

seem to be fixed in 4.15.0-59.

could you bump it to last version ?

Thanks

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

[pve-devel] [PATCH storage 2/2] warn if filesize info couldn't be read due to error

2019-09-09 Thread Tim Marx 
This sh
Signed-off-by: Tim Marx 
---
 PVE/Storage/Plugin.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/PVE/Storage/Plugin.pm b/PVE/Storage/Plugin.pm
index ed71fe4..6b79e7a 100644
--- a/PVE/Storage/Plugin.pm
+++ b/PVE/Storage/Plugin.pm
@@ -742,6 +742,8 @@ sub file_size_info {
});
 };

+warn $@ if $@;
+
 return wantarray ? ($size, $format, $used, $parent) : $size;
 }

--
2.20.1

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

[pve-devel] [PATCH storage 1/2] whitespace cleanup

2019-09-09 Thread Tim Marx 
Signed-off-by: Tim Marx 
---
 PVE/Storage/Plugin.pm | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/PVE/Storage/Plugin.pm b/PVE/Storage/Plugin.pm
index 9a419f1..ed71fe4 100644
--- a/PVE/Storage/Plugin.pm
+++ b/PVE/Storage/Plugin.pm
@@ -651,7 +651,7 @@ sub alloc_image {
 if ($fmt eq 'subvol') {
# only allow this if size = 0, so that user knows what he is doing
die "storage does not support subvol quotas\n" if $size != 0;
-   
+
my $old_umask = umask(0022);
my $err;
mkdir($path) or $err = "unable to create subvol '$path' - $!\n";
@@ -661,7 +661,7 @@ sub alloc_image {
my $cmd = ['/usr/bin/qemu-img', 'create'];
 
push @$cmd, '-o', 'preallocation=metadata' if $fmt eq 'qcow2';
-   
+
push @$cmd, '-f', $fmt, $path, "${size}K";
 
eval { run_command($cmd, errmsg => "unable to create image"); };
@@ -671,7 +671,7 @@ sub alloc_image {
die "$@";
}
 }
-
+
 return "$vmid/$name";
 }
 
@@ -701,7 +701,7 @@ sub free_image {
 # all images from a guest got deleted
 my $dir = dirname($path);
 rmdir($dir);
-
+
 return undef;
 }
 
@@ -711,7 +711,7 @@ sub file_size_info {
 if (-d $filename) {
return wantarray ? (0, 'subvol', 0, undef) : 1;
 }
-
+
 my $cmd = ['/usr/bin/qemu-img', 'info', $filename];
 
 my $format;
@@ -785,9 +785,9 @@ sub volume_snapshot {
 }
 
 sub volume_rollback_is_possible {
-my ($class, $scfg, $storeid, $volname, $snap) = @_; 
+my ($class, $scfg, $storeid, $volname, $snap) = @_;
 
-return 1; 
+return 1;
 }
 
 sub volume_snapshot_rollback {
-- 
2.20.1

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

Re: [pve-devel] proxmox5: can you bump kernel to ubuntu 4.15.0-59 ? (mellanox bug)

2019-09-09 Thread Thomas Lamprecht 
Hi,

On 09.09.19 12:46, Alexandre DERUMIER wrote:
> Hi,
> 
> I have a bug on last pve-kernel 4.15 related to mellanox nic
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840854
> 
> seem to be fixed in 4.15.0-59.
> 
> could you bump it to last version ?

Yes, currently in the process of rolling it out, should come to pvetest today
or tomorrow, if no issue surfaces. It will be based on Ubuntu-4.15.0-63.72

cheers,
Thomas

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

Re: [pve-devel] [PATCH qemu-server 3/7] Add QEMU CPU flag querying helpers

2019-09-09 Thread Stefan Reiter 

Will implement all of this for v2, just a note inline.

On 9/6/19 1:42 PM, Fabian Grünbichler wrote:

On September 2, 2019 4:27 pm, Stefan Reiter wrote:

* query_understood_cpu_flags returns all flags that QEMU/KVM knows about
* query_supported_cpu_flags returns all flags that QEMU/KVM can use on
   this particular host.

To get supported flags, a temporary VM is started with QEMU, so we can
issue the "query-cpu-model-expansion" QMP command. This is how libvirt
queries supported flags for its "host-passthrough" CPU type.

query_supported_cpu_flags is thus rather slow and shouldn't be called
unnecessarily.

Signed-off-by: Stefan Reiter 
---

Changes from RFC:

* Clearer regexes
* Use existing QMP infrastructure
* Add locking for temporary VM start
* Add comments


  PVE/QemuServer.pm | 84 +++
  1 file changed, 84 insertions(+)

diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 8c519b5..97fa955 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -3500,6 +3500,90 @@ sub get_command_for_arch($) {
  return $cmd;
  }
  
+# The format of the flags returned here uses dashes '-' as seperators,


nit: s/seperator/separator/a


+# this is neither the default for 'query_supported_cpu_flags' below, nor for
+# /proc/cpuinfo.
+#
+# To compare (or array_intersect) flags, it's a good idea to convert them all
+# to a common format first (e.g. map s/\.|-/_/g).
+sub query_understood_cpu_flags {


not used anywhere in this series? also, confusingly, this returns less
values then the other helper (maybe because of some aliases?), and it's
not a strict subset :-/



Yes, this is for exposing via the API (for the GUI to create/edit custom 
models I have in mind). I just thought it fits with this patch well, 
since the comments refer to each other.


Also, query_understood_cpu_flags returns 188 flags for me, while 
query_supported_cpu_flags only returns 104...


The discrepancies generally arise because
a) query_understood_cpu_flags returns flags the host cannot use and
b) query_supported_cpu_flags (rather the QMP call) doesn't actually 
return CPU flags, but CPU settings - with most of them being flags. 
Those settings (and some flags, curiously) cannot be specified as a 
"-cpu" argument however.


The intersection of those provides only flags that can be passed to 
"-cpu" without issues in my testing. Since query_understood_cpu_flags is 
not host specific though, it doesn't need broadcasting.



I guess this is in preparation of exposing it via the API? some sort of
comment how _understood and _supported interact/are supposed to interact
would be nice. either as comment or part of the commit message


I'll try to make the comments/message more informative.


+my $flags = [];
+my $flag_section = 0;
+
+run_command(
+   [get_command_for_arch('x86_64'), '-cpu', 'help'],


why not get_host_arch()?


+   noerr => 1,
+   quiet => 1,
+   outfunc => sub {
+   my ($line) = @_;
+
+   if ($flag_section) {
+   return if $line =~ m/^\s*$/;
+   $line =~ s/^\s*|\s*$//g;
+   push @$flags, split(/\s+/, $line);
+   } elsif ($line =~ m/^\s*Recognized CPUID flags:\s*$/) {
+   $flag_section = 1;
+   }
+   }
+);
+
+return $flags;
+}
+
+# This function needs to start a temporary VM and is therefore rather 
expensive.
+# If you need the value returned from this, you can get it much cheaper from
+# pvestatd using PVE::Cluster::get_node_kv('cpuflags').


s/pvestatd/pmxcfs/

pvestatd is just the one putting it there ;)


+#
+# See also note to query_understood_cpu_flags above.
+sub query_supported_cpu_flags {
+my $flags = [];
+
+my $vmid = -1;
+my $pidfile = pidfile_name($vmid);
+
+PVE::QemuConfig->lock_config($vmid, sub {
+   # We start a temporary (frozen) VM with vmid -1 to allow us to send a 
QMP command
+   my $rc = run_command([
+   get_command_for_arch('x86_64'),


again, why not get_host_arch()?


+   '-cpu', 'kvm64',
+   '-display', 'none',
+   '-chardev', 
"socket,id=qmp,path=/var/run/qemu-server/$vmid.qmp,server,nowait",
+   '-mon', 'chardev=qmp,mode=control',
+   '-pidfile', $pidfile,
+   '-S', '-daemonize'
+   ], noerr => 1, quiet => 1);
+   return if $rc;
+
+   my $cmd_result = vm_mon_cmd_nocheck(
+   $vmid,
+   'query-cpu-model-expansion',
+   type => 'full',
+   model => { name => 'host' }
+   );
+
+   my $props = $cmd_result->{model}->{props};
+   if (%$props) {
+   foreach my $prop (keys %$props) {
+   push @$flags, $prop if "$props->{$prop}" eq '1';
+   }
+   }
+
+   # force stop with 10 sec timeout and 'nocheck'
+   vm_stop(undef, $vmid, 1, 1, 10, 0, 1);
+});
+
+# QEMU returns some flags multiple times, with '_', '.' or '-' as seperator
+# (e.g. lahf_lm and lahf-lm; sse4.2,

Re: [pve-devel] [PATCH qemu-server 4/7] Add CustomCPUConfig for storing/parsing custom CPU models

2019-09-09 Thread Stefan Reiter 
Thanks again for the thorough review, I'll try to address everything 
mentioned in v2. Some stuff inline for this patch in particular.


On 9/9/19 11:53 AM, Fabian Grünbichler wrote:

On September 2, 2019 4:27 pm, Stefan Reiter wrote:

Inherits from SectionConfig to provide base parsing infrastructure.

Use with helper functions:
* config_from_file gives bless'd config
* get_model_by_name returns a "formatted" hash for a single CPU model
* config_to_file writes changes back

File reads are cached in a local hash.


high-level:

use cfs_register/write/read_file please (it's our mechanism for handling
config files on pmxcfs after all ;))

is there a reason you need a class-like interface here? we usually use
that if we want to have multiple implementations of a certain interface
with a common shared code base, but that is not the case here..


As discussed off-list, I will change the code to use the cfs helpers and 
not use 'bless', the former primarily since I'd need to change the 
cluster code anyway (for locking).






Signed-off-by: Stefan Reiter 
---

This will definitely require some sort of versioning mechanism, otherwise CPU
definitions could be changed after starting a VM, thus breaking live-migration
by starting the migration-target with different parameters.

Hints, ideas, recommendations?


versioning is one possibility (cumbersome with SectionConfig though).

another would be to retrieve the CPU model from the running Qemu
instance, and convert that back to a '-cpu ...' string for starting the
target instance. if nothing hot-pluggable can change the generated -cpu
string, we could also record that somewhere (or take it from
/proc/$pid/cmdline) and override the target instance with that.



I like the idea of migrating the "-cpu" data together with the VM. I 
don't *think* hotplugging could change that, since topology is a 
seperate parameter (-smp), so I will probably use the /proc/$pid/cmdline 
version for now, though that is a detail that we can easily change later on.



  PVE/QemuServer/CustomCPUConfig.pm | 129 ++
  PVE/QemuServer/Makefile   |   1 +
  2 files changed, 130 insertions(+)
  create mode 100644 PVE/QemuServer/CustomCPUConfig.pm

diff --git a/PVE/QemuServer/CustomCPUConfig.pm 
b/PVE/QemuServer/CustomCPUConfig.pm
new file mode 100644
index 000..87ba9e6
--- /dev/null
+++ b/PVE/QemuServer/CustomCPUConfig.pm
@@ -0,0 +1,129 @@
+package PVE::QemuServer::CustomCPUConfig;
+
+use strict;
+use warnings;
+use PVE::Tools qw(file_get_contents file_set_contents);
+
+use base qw(PVE::SectionConfig);
+
+my $defaultData = {
+propertyList => {
+   basemodel => {
+   description => "Emulated CPU type to inherit defaults from.",
+   type => 'string',
+   format_description => 'string',
+   default => 'kvm64',


should have the same pattern/format as QemuServer's $cpu_fmt->{cputype}.
in other words, it probably makes sense to extract and re-use that ;)



The formats in this version of the patch are not *quite* the same, hence 
the seperation (e.g. $cpu_fmt doesn't support arbitrary flags but rather 
a whitelisted set). I'll see what I can do for v2, I agree that it would 
be nicer.



+   },
+   flags => {
+   description => "List of additional CPU flags separated by ';'."
+. " Use '+FLAG' to enable, '-FLAG' to disable a flag."
+. " Supports all flags supported by QEMU/KVM.",
+   format_description => '+FLAG[;-FLAG...]',
+   type => 'string',
+   pattern => qr/[+-][a-zA-Z0-9\-_\.]+(;[+-][a-zA-Z0-9\-_\.]+)*/,


same here (different description, please just use a single definition
for both instances)


+   optional => 1,
+   },
+   'phys-bits' => {
+   type => 'integer',
+   minimum => 1,
+   maximum => 64,
+   optional => 1,
+   description => "The physical memory bits that are reported to the guest 
OS. Must be smaller or equal to the host.",


this one might make sense to also allow in the regular, per-VM 'cpu'
option (and then we could again re-use the definition)



I can add that in, but I think this would be an API/CLI only thing, I 
don't think this is a common enough issue to confuse the 'average' GUI 
user with.



+   },
+   'host-phys-bits' => {
+   type => 'boolean',
+   default => 0,
+   description => "Whether to report the host's physical memory bits. 
Overrides 'phys-bits' when set.",
+   },


same


+   vendor => {
+   type => 'string',
+   enum => [qw(default AuthenticAMD GenuineIntel)],
+   default => 'default',
+   description => "The CPU vendor to report. 'default' uses the 
host's.",
+   },
+}


this probably only makes sense for the custom types. the default value
means that you never inherit the vendor from your basemodel - is that
intended?


I think that should be a different

Re: [pve-devel] [PATCH qemu-server 3/7] Add QEMU CPU flag querying helpers

2019-09-09 Thread Fabian Grünbichler 
On September 9, 2019 2:56 pm, Stefan Reiter wrote:
> On 9/6/19 1:42 PM, Fabian Grünbichler wrote:
>>> +# this is neither the default for 'query_supported_cpu_flags' below, nor 
>>> for
>>> +# /proc/cpuinfo.
>>> +#
>>> +# To compare (or array_intersect) flags, it's a good idea to convert them 
>>> all
>>> +# to a common format first (e.g. map s/\.|-/_/g).
>>> +sub query_understood_cpu_flags {
>> 
>> not used anywhere in this series? also, confusingly, this returns less
>> values then the other helper (maybe because of some aliases?), and it's
>> not a strict subset :-/
>>
> 
> Yes, this is for exposing via the API (for the GUI to create/edit custom 
> models I have in mind). I just thought it fits with this patch well, 
> since the comments refer to each other.
> 
> Also, query_understood_cpu_flags returns 188 flags for me, while 
> query_supported_cpu_flags only returns 104...

yes, a double check confirms this - seems I had the output files mixed 
up.. sorry for the noise

> 
> The discrepancies generally arise because
> a) query_understood_cpu_flags returns flags the host cannot use and
> b) query_supported_cpu_flags (rather the QMP call) doesn't actually 
> return CPU flags, but CPU settings - with most of them being flags. 
> Those settings (and some flags, curiously) cannot be specified as a 
> "-cpu" argument however.

that makes sense - and would make a good starting point for an 
informative comment ;)

> 
> The intersection of those provides only flags that can be passed to 
> "-cpu" without issues in my testing. Since query_understood_cpu_flags is 
> not host specific though, it doesn't need broadcasting.

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

[pve-devel] applied-series: [PATCH storage 2/2] warn if filesize info couldn't be read due to error

2019-09-09 Thread Thomas Lamprecht 
On 09.09.19 12:56, Tim Marx wrote:
> This sh

abrupt CI message ending?

> Signed-off-by: Tim Marx 
> ---
>  PVE/Storage/Plugin.pm | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/PVE/Storage/Plugin.pm b/PVE/Storage/Plugin.pm
> index ed71fe4..6b79e7a 100644
> --- a/PVE/Storage/Plugin.pm
> +++ b/PVE/Storage/Plugin.pm
> @@ -742,6 +742,8 @@ sub file_size_info {
>   });
>  };
> 
> +warn $@ if $@;
> +

applied both, even though `qemu-img info FN` still exits with 0 if FN does
not exists, so at least "common" possible problematic situations won't be
caught by this, I'd guess?

>  return wantarray ? ($size, $format, $used, $parent) : $size;
>  }
> 
> --
> 2.20.1
> 
> ___
> 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] [PATCH v2 qemu-server] add check to resize disk if current size could not be determined

2019-09-09 Thread Thomas Lamprecht 
On 09.09.19 12:39, Tim Marx wrote:
> This check ensures that disks aren't unintentionally shrunken, if the
> size is zero due to an underlying problem.
> ---
> * fix indentation
> 
>  PVE/API2/Qemu.pm | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> index 245de80..e6f3cce 100644
> --- a/PVE/API2/Qemu.pm
> +++ b/PVE/API2/Qemu.pm
> @@ -3511,6 +3511,8 @@ __PACKAGE__->register_method({
>   PVE::Storage::activate_volumes($storecfg, [$volid]);
>   my $size = PVE::Storage::volume_size_info($storecfg, $volid, 5);
> 
> + die "volume $volid does not exists\n" if !$size;

Hmm, but I _can_ create a 0 size disk image:

# qemu-img create -f qcow2 test.qcow2 0
Formatting 'test.qcow2', fmt=qcow2 size=0 cluster_size=65536 lazy_refcounts=off 
refcount_bits=16
# qemu-img info test.qcow2
image: test.qcow2
file format: qcow2
virtual size: 0 (0 bytes)
disk size: 192K
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false


while a bit strange, it's possible and the single real use case I'd then
have would be to resize it to some actual positive value.. Also ".. does
not exists" is then not true.

How about: parse stderr in qemu.img info too, with that you should be
able to check if a file really does not exists (`qemu-img info` does not
exits with <> 0 in that case but prints on stderr) and if not then set
$size and $used to undef? Then we can do a defined-ness check here...

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

Re: [pve-devel] proxmox5: can you bump kernel to ubuntu 4.15.0-59 ? (mellanox bug)

2019-09-09 Thread Thomas Lamprecht 
On 09.09.19 12:46, Alexandre DERUMIER wrote:
> Hi,
> 
> I have a bug on last pve-kernel 4.15 related to mellanox nic
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840854
> 
> seem to be fixed in 4.15.0-59.
> 
> could you bump it to last version ?

FYI:
pve-kernel-4.15.18-21-pve_4.15.18-47_amd64.deb
pve-kernel-4.15_5.4-9_all.deb
et al. got just uploaded on pvetest for 5.X, if you want to check if the 
Mellanox
issues are really fixed for you.

cheers,
Thomas

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

[pve-devel] applied-series: [PATCH novnc 1/2] update submodule to v1.1.0

2019-09-09 Thread Thomas Lamprecht 
On 09.09.19 12:17, Dominik Csapak wrote:
> Signed-off-by: Dominik Csapak 
> ---
> the mirror has ofc to be updated
>  novnc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/novnc b/novnc
> index f9b6d76..9fe2fd0 16
> --- a/novnc
> +++ b/novnc
> @@ -1 +1 @@
> -Subproject commit f9b6d7665d01f31a6c0c675ec3f604e99f6b2341
> +Subproject commit 9fe2fd04d4eeda0d5a360009453861803ba0ca84
> 

applied series, much thanks!

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

[pve-devel] applied-series: [PATCH pve-docs 0/4] vxlan: improve gateway doc

2019-09-09 Thread Thomas Lamprecht 
On 09.09.19 07:46, Alexandre Derumier wrote:
> cleanup config for gateway nodes
> add documentation for external bgp router
> add missing ipv6 conf
> 

applied series, thanks!

> Alexandre Derumier (4):
>   vxlan-evpn: remove prefix-route deny
>   vxlan: add ipv6 missing config
>   vxlan: add external bgp router documentation
>   vxlan: add rp_filter sysctl for multiple gateway nodes
> 
>  vxlan-and-evpn.adoc | 172 ++--
>  1 file changed, 152 insertions(+), 20 deletions(-)
> 


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

[pve-devel] applied: [PATCH v2 pve-network 0/4] vxlan-evpn: fix routing for local vms on gateway nodes

2019-09-09 Thread Thomas Lamprecht 
On 09.09.19 08:45, Alexandre Derumier wrote:
> It was not possible to route from external to a local vm on a gateway node.
> I have reworked the config hash with better ordering and sub keys
> 
> changelog v2:
> 
> - remove unneeded prefix-list
> - move gateway-nodes option to frr plugin, and add support for bgp external 
> router
> - also add missing ipv6 config
> 

applied, thanks!

> 
> Alexandre Derumier (4):
>   generate_frr_config: cleanup hash and ordering
>   vxlan: evpn: fix routing to local vms on gateway nodes
>   vxlan: frr : remove unneeded prefix-list
>   move gateway-nodes option to frr plugin and add gateway-external-peers
> 
>  PVE/Network/SDN.pm | 120 +++--
>  PVE/Network/SDN/FrrPlugin.pm   |  56 +--
>  PVE/Network/SDN/Plugin.pm  |   2 +-
>  PVE/Network/SDN/VxlanPlugin.pm |  35 +-
>  test/documentation.txt |   4 +-
>  5 files changed, 154 insertions(+), 63 deletions(-)
> 


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

[pve-devel] applied: [PATCH storage] fix vmid filter for backup listing

2019-09-09 Thread Thomas Lamprecht 
On 06.09.19 14:12, Dominik Csapak wrote:
> $1 and $2 get set to undef from the vmid filter regex, so we have to do
> the name/format regex after, else we get errors like:
> 
> 'use of unitiialized value $1[...]'
> 
> and the listing is empty
> 
> Signed-off-by: Dominik Csapak 
> ---
>  PVE/Storage/Plugin.pm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/PVE/Storage/Plugin.pm b/PVE/Storage/Plugin.pm
> index 9a419f1..2a4e88b 100644
> --- a/PVE/Storage/Plugin.pm
> +++ b/PVE/Storage/Plugin.pm
> @@ -925,8 +925,8 @@ my $get_subdir_files = sub {
>   $info = { volid => "$sid:vztmpl/$1", format => "t$2" };
>  
>   } elsif ($tt eq 'backup') {
> - next if $fn !~ 
> m!/([^/]+\.(tar|tar\.gz|tar\.lzo|tgz|vma|vma\.gz|vma\.lzo))$!;
>   next if defined($vmid) && $fn !~  m/\S+-$vmid-\S+/;
> + next if $fn !~ 
> m!/([^/]+\.(tar|tar\.gz|tar\.lzo|tgz|vma|vma\.gz|vma\.lzo))$!;
>  
>   $info = { volid => "$sid:backup/$1", format => $2 };
>  
> 

applied, thanks!

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

Re: [pve-devel] [PATCH pve-common] etc_network_interfaces : add uplink-id option

2019-09-09 Thread Thomas Lamprecht 
On 04.09.19 09:47, Alexandre Derumier wrote:
> Signed-off-by: Alexandre Derumier 
> ---
>  src/PVE/INotify.pm | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
> index 8b49f5a..fd54313 100644
> --- a/src/PVE/INotify.pm
> +++ b/src/PVE/INotify.pm
> @@ -955,6 +955,7 @@ sub __read_etc_network_interfaces {
>   'bridge-multicast-flood' => 1,
>   'bond_miimon' => 1,
>   'bond_xmit_hash_policy' => 1,
> + 'uplink-id' => 1,
>   'vlan-protocol' => 1,
>   'vxlan-id' => 1,
>   'vxlan-svcnodeip' => 1,
> @@ -1183,7 +1184,7 @@ sub __interface_to_string {
>comments => 1, autostart => 1, options => 1,
>address => 1, netmask => 1, gateway => 1, broadcast => 1,
>method6 => 1, families => 1, options6 => 1,
> -  address6 => 1, netmask6 => 1, gateway6 => 1, broadcast6 => 1 };
> +  address6 => 1, netmask6 => 1, gateway6 => 1, broadcast6 => 1, 
> 'uplink-id' => 1 };
>  
>  if (!$first_block) {
>   # not printing out options
> @@ -1487,6 +1488,21 @@ sub __write_etc_network_interfaces {
>   }
>  }
>  
> +# check uplink
> +my $uplinks = {};
> +foreach my $iface (keys %$ifaces) {
> + my $d = $ifaces->{$iface};
> + if (my $uplinkid = $d->{'uplink-id'}) {
> + die "iface '$iface' - uplink-id $uplinkid is only allowed on 
> physical and linux bond interfaces\n"
> + if $d->{type} ne 'eth' && $d->{type} ne 'bond'; 
> +
> + die "iface '$iface' - uplink-id $uplinkid is already assigned on 
> '$uplinks->{$uplinkid}'\n"
> + if $uplinks->{$uplinkid};
> +
> + $uplinks->{$uplinkid} = $iface;
> + }
> +}
> +
>  # check bridgeport option
>  my $bridgeports = {};
>  my $bridges = {};
> 


applied, with the commit message from your old mail added.

btw. a general note to all: Did also a tree-wide trailing white-space
cleanup with:
# find . -name '*.pm' -exec sed -i 's/\s\+$//'  {} \;

There were many in pve-common, sorry if I forced to rebase anybodies patch
series as a cause of this.

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

[pve-devel] [PATCH pve-network] frr: remove "no bgp default ipv6-unicast"

2019-09-09 Thread Alexandre Derumier 
Signed-off-by: Alexandre Derumier 
---
 PVE/Network/SDN/FrrPlugin.pm | 1 -
 1 file changed, 1 deletion(-)

diff --git a/PVE/Network/SDN/FrrPlugin.pm b/PVE/Network/SDN/FrrPlugin.pm
index 8a1f86c..79214a7 100644
--- a/PVE/Network/SDN/FrrPlugin.pm
+++ b/PVE/Network/SDN/FrrPlugin.pm
@@ -74,7 +74,6 @@ sub generate_frr_config {
 
 push @router_config, "bgp router-id $ifaceip";
 push @router_config, "no bgp default ipv4-unicast";
-push @router_config, "no bgp default ipv6-unicast";
 push @router_config, "coalesce-time 1000";
 
 foreach my $address (@peers) {
-- 
2.20.1

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

[pve-devel] [PATCH pve-docs] vxlan: remove "no bgp default ipv6-unicast"

2019-09-09 Thread Alexandre Derumier 
This syntax don't exist

Signed-off-by: Alexandre Derumier 
---
 vxlan-and-evpn.adoc | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/vxlan-and-evpn.adoc b/vxlan-and-evpn.adoc
index 0a05cfb..ec1bc07 100644
--- a/vxlan-and-evpn.adoc
+++ b/vxlan-and-evpn.adoc
@@ -367,7 +367,6 @@ iface vmbr3 inet manual
 
 router bgp 1234
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.2 remote-as 1234
  neighbor 192.168.0.3 remote-as 1234
@@ -437,7 +436,6 @@ iface vmbr3 inet manual
 
 router bgp 1234
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.1 remote-as 1234
  neighbor 192.168.0.3 remote-as 1234
@@ -508,7 +506,6 @@ iface vmbr3 inet manual
 
 router bgp 1234
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.1 remote-as 1234
  neighbor 192.168.0.2 remote-as 1234
@@ -612,7 +609,6 @@ frr.conf
 router bgp 1234
  bgp router-id 192.168.0.1
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.2 remote-as 1234
  neighbor 192.168.0.3 remote-as 1234
@@ -696,7 +692,6 @@ frr.conf
 router bgp 1234
  bgp router-id 192.168.0.2
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.1 remote-as 1234
  neighbor 192.168.0.3 remote-as 1234
@@ -778,7 +773,6 @@ frr.conf
 router bgp 1234
  bgp router-id 192.168.0.3
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.1 remote-as 1234
  neighbor 192.168.0.2 remote-as 1234
@@ -902,7 +896,6 @@ vrf vrf1
 router bgp 1234
  bgp router-id 192.168.0.1
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.2 remote-as 1234
  neighbor 192.168.0.3 remote-as 1234
@@ -1011,7 +1004,6 @@ vrf vrf1
 router bgp 1234
  bgp router-id 192.168.0.2
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.1 remote-as 1234
  neighbor 192.168.0.3 remote-as 1234
@@ -1120,7 +1112,6 @@ vrf vrf1
 router bgp 1234
  bgp router-id 192.168.0.3
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.1 remote-as 1234
  neighbor 192.168.0.2 remote-as 1234
@@ -1240,7 +1231,6 @@ vrf vrf1
 router bgp 1234
  bgp router-id 192.168.0.1
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.2 remote-as 1234
  neighbor 192.168.0.3 remote-as 1234
@@ -1372,7 +1362,6 @@ vrf vrf1
 router bgp 1234
  bgp router-id 192.168.0.2
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.1 remote-as 1234
  neighbor 192.168.0.3 remote-as 1234
@@ -1481,7 +1470,6 @@ vrf vrf1
 router bgp 1234
  bgp router-id 192.168.0.3
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.1 remote-as 1234
  neighbor 192.168.0.2 remote-as 1234
@@ -1610,7 +1598,6 @@ vrf vrf1
 router bgp 1234
  bgp router-id 192.168.0.1
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.2 remote-as 1234
  neighbor 192.168.0.3 remote-as 1234
@@ -1745,7 +1732,6 @@ vrf vrf1
 router bgp 1234
  bgp router-id 192.168.0.2
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.1 remote-as 1234
  neighbor 192.168.0.3 remote-as 1234
@@ -1878,7 +1864,6 @@ vrf vrf1
 router bgp 1234
  bgp router-id 192.168.0.3
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.1 remote-as 1234
  neighbor 192.168.0.2 remote-as 1234
@@ -1980,7 +1965,6 @@ vrf vrf1
 router bgp 1234
  bgp router-id 192.168.0.1
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.2 remote-as 1234
  neighbor 192.168.0.3 remote-as 1234
@@ -2066,7 +2050,6 @@ router bgp 1234
   bgp cluster-id 1.1.1.1  #cluster-id must be the same on each route reflector
   bgp log-neighbor-changes
   no bgp default ipv4-unicast
-  no bgp default ipv6-unicast
   neighbor fabric peer-group
   neighbor fabric remote-as 1234
   neighbor fabric capability extended-nexthop
@@ -2090,7 +2073,6 @@ router bgp 1234
   bgp cluster-id 1.1.1.1
   bgp log-neighbor-changes
   no bgp default ipv4-unicast
-  no bgp default ipv6-unicast
   neighbor fabric peer-group
   neighbor fabric remote-as 1234
   neighbor fabric capability extended-nexthop
@@ -2112,7 +2094,6 @@ proxmoxnode(s)
 router bgp 1234
  bgp router-id 192.168.0.x
  no bgp default ipv4-unicast
- no bgp default ipv6-unicast
  coalesce-time 1000
  neighbor 192.168.0.200 remote-as 1234
  neighbor 192.168.0.201 remote-as 1234
-- 
2.20.1

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

[pve-devel] applied: [PATCH pve-network] frr: remove "no bgp default ipv6-unicast"

2019-09-09 Thread Thomas Lamprecht 
On 09.09.19 17:56, Alexandre Derumier wrote:
> Signed-off-by: Alexandre Derumier 
> ---
>  PVE/Network/SDN/FrrPlugin.pm | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/PVE/Network/SDN/FrrPlugin.pm b/PVE/Network/SDN/FrrPlugin.pm
> index 8a1f86c..79214a7 100644
> --- a/PVE/Network/SDN/FrrPlugin.pm
> +++ b/PVE/Network/SDN/FrrPlugin.pm
> @@ -74,7 +74,6 @@ sub generate_frr_config {
>  
>  push @router_config, "bgp router-id $ifaceip";
>  push @router_config, "no bgp default ipv4-unicast";
> -push @router_config, "no bgp default ipv6-unicast";
>  push @router_config, "coalesce-time 1000";
>  
>  foreach my $address (@peers) {
> 

applied, sorry, did not checked the other patches to thoroughly about
the specifically added router configs.. :/

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

[pve-devel] applied: [PATCH pve-docs] vxlan: remove "no bgp default ipv6-unicast"

2019-09-09 Thread Thomas Lamprecht 
On 09.09.19 17:58, Alexandre Derumier wrote:
> This syntax don't exist
> 
> Signed-off-by: Alexandre Derumier 
> ---
>  vxlan-and-evpn.adoc | 19 ---
>  1 file changed, 19 deletions(-)
> 
applied

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