[pve-devel] [PATCH v2 firewall] Don't change external ebtables rules

2018-05-23 Thread Stoiko Ivanov 
  * Fixes #1764
  * Introduces ebtables_enable option to cluster config
  * All ebtables chains not created by PVE are left in place

Signed-off-by: Stoiko Ivanov 
---
Changes from V1:
* externally defined rules (those not in chains matching
  $pve_ebtables_chainname_regex) are ignored (taken and restored as is)
* setting ebtables_enable to 1 in the cluster config now cleans the ebtable
  rules generated by PVE.

I'm not too fond of the introduced code duplication
(get_ebtables_ruleset_status), but since we need the actual rule texts from
the ebtables output in this case as well it seemed like a fair compromise
(the alternative being a quite larger refactoring of the other parts which use
get_ruleset_status.



src/PVE/Firewall.pm | 100 ++--
 1 file changed, 73 insertions(+), 27 deletions(-)

diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm
index 96cf9bd..56b99c4 100644
--- a/src/PVE/Firewall.pm
+++ b/src/PVE/Firewall.pm
@@ -1827,11 +1827,12 @@ sub ipset_get_chains {
 return $res;
 }
 
+my $pve_ebtables_chainname_regex = 
qr/PVEFW-\S+|(?:tab|veth)\d+i\d+-(?:IN|OUT)/;
+
 sub ebtables_get_chains {
 
 my $res = {};
 my $chains = {};
-
 my $parser = sub {
my $line = shift;
return if $line =~ m/^#/;
@@ -1839,15 +1840,11 @@ sub ebtables_get_chains {
if ($line =~ m/^:(\S+)\s\S+$/) {
# Make sure we know chains exist even if they're empty.
$chains->{$1} //= [];
-   } elsif ($line =~ m/^(?:\S+)\s(PVEFW-\S+)\s(?:\S+).*/) {
+   } elsif ($line =~ 
m/^(?:\S+)\s($pve_ebtables_chainname_regex)\s(?:\S+).*/) {
my $chain = $1;
$line =~ s/\s+$//;
push @{$chains->{$chain}}, $line;
-   } elsif ($line =~ m/^(?:\S+)\s(tap\d+i\d+-(:?IN|OUT))\s(?:\S+).*/) {
-   my $chain = $1;
-   $line =~ s/\s+$//;
-   push @{$chains->{$chain}}, $line;
-   } elsif ($line =~ m/^(?:\S+)\s(veth\d+i\d+-(:?IN|OUT))\s(?:\S+).*/) {
+   } elsif ($line =~ m/^(?:\S+)\s(\S+)\s(?:\S+).*/) {
my $chain = $1;
$line =~ s/\s+$//;
push @{$chains->{$chain}}, $line;
@@ -1858,10 +1855,10 @@ sub ebtables_get_chains {
 };
 
 run_command("/sbin/ebtables-save", outfunc => $parser);
-
-# compute digest for each chain
+# compute digest for each chain and store rules as well
 foreach my $chain (keys %$chains) {
-   $res->{$chain} = iptables_chain_digest($chains->{$chain});
+   $res->{$chain}->{'rules'} = $chains->{$chain};
+   $res->{$chain}->{'digest'} = iptables_chain_digest($chains->{$chain});
 }
 return $res;
 }
@@ -2667,6 +2664,9 @@ sub parse_clusterfw_option {
if (($value > 1) && ((time() - $value) > 60)) {
$value = 0
}
+} elsif ($line =~ m/^(ebtables_enable):\s*(0|1)\s*$/i) {
+   $opt = lc($1);
+   $value = int($2);
 } elsif ($line =~ m/^(policy_(in|out)):\s*(ACCEPT|DROP|REJECT)\s*$/i) {
$opt = lc($1);
$value = uc($3);
@@ -3422,7 +3422,7 @@ sub compile {
$vmfw_configs = read_vm_firewall_configs($cluster_conf, $vmdata, undef, 
$verbose);
 }
 
-return ({},{},{}) if !$cluster_conf->{options}->{enable};
+return ({},{},{},{}) if !$cluster_conf->{options}->{enable};
 
 my $localnet;
 if ($cluster_conf->{aliases}->{local_network}) {
@@ -3431,7 +3431,7 @@ sub compile {
my $localnet_ver;
($localnet, $localnet_ver) = parse_ip_or_cidr(local_network() || 
'127.0.0.0/8');
 
-   $cluster_conf->{aliases}->{local_network} = { 
+   $cluster_conf->{aliases}->{local_network} = {
name => 'local_network', cidr => $localnet, ipversion => 
$localnet_ver };
 }
 
@@ -3657,13 +3657,14 @@ sub compile_ipsets {
 sub compile_ebtables_filter {
 my ($cluster_conf, $hostfw_conf, $vmfw_configs, $vmdata, $verbose) = @_;
 
-return ({}, {}) if !$cluster_conf->{options}->{enable};
+if (!($cluster_conf->{options}->{ebtables_enable} // 1)) {
+   return {};
+}
 
 my $ruleset = {};
 
 ruleset_create_chain($ruleset, "PVEFW-FORWARD");
 
-
 ruleset_create_chain($ruleset, "PVEFW-FWBR-OUT");
 #for ipv4 and ipv6, check macaddress in iptables, so we use conntrack 
'ESTABLISHED', to speedup rules
 ruleset_addrule($ruleset, 'PVEFW-FORWARD', '-p IPv4', '-j ACCEPT');
@@ -3848,6 +3849,50 @@ sub get_ruleset_cmdlist {
 
 return wantarray ? ($cmdlist, $changes) : $cmdlist;
 }
+sub get_ebtables_ruleset_status {
+my ($ruleset, $active_chains, $digest_fn, $verbose) = @_;
+
+my $statushash = {};
+
+foreach my $chain (sort keys %$ruleset) {
+   my $digest = &$digest_fn($ruleset->{$chain});
+
+   $statushash->{$chain}->{digest} = $digest;
+
+   my $olddigest = $active_chains->{$chain}->{digest};
+   if (defined($olddigest) && ($olddigest eq $digest) ) {
+   $statushash->{$chain}->{action} = 'exists';
+   } else {
+

[pve-devel] [Patch container 1/2] Also rename MP when CT is converted to template.

2018-05-23 Thread Wolfgang Link 
Mountpoints should use the same names as rootfs when they converted to a 
template.
So we also renamed MP.
---
 src/PVE/LXC.pm | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm
index 4f9674d..928234a 100644
--- a/src/PVE/LXC.pm
+++ b/src/PVE/LXC.pm
@@ -869,17 +869,32 @@ sub template_create {
 
 my $storecfg = PVE::Storage::config();
 
-my $rootinfo = PVE::LXC::Config->parse_ct_rootfs($conf->{rootfs});
-my $volid = $rootinfo->{volume};
+PVE::LXC::Config->foreach_mountpoint($conf, sub {
+   my ($ms, $mountpoint) = @_;
 
-die "Template feature is not available for '$volid'\n"
-   if !PVE::Storage::volume_has_feature($storecfg, 'template', $volid);
+   my $volume = $ms eq "rootfs" ?
+   PVE::LXC::Config->parse_ct_rootfs($conf->{$ms}) :
+   PVE::LXC::Config->parse_ct_mountpoint($conf->{$ms});
+   my $volid = $volume->{volume};
 
-PVE::Storage::activate_volumes($storecfg, [$volid]);
+   die "Template feature is not available for '$volid'\n"
+   if !PVE::Storage::volume_has_feature($storecfg, 'template', $volid);
+});
 
-my $template_volid = PVE::Storage::vdisk_create_base($storecfg, $volid);
-$rootinfo->{volume} = $template_volid;
-$conf->{rootfs} = PVE::LXC::Config->print_ct_mountpoint($rootinfo, 1);
+PVE::LXC::Config->foreach_mountpoint($conf, sub {
+   my ($ms, $mountpoint) = @_;
+
+   my $volume = $ms eq "rootfs" ?
+   PVE::LXC::Config->parse_ct_rootfs($conf->{$ms}) :
+   PVE::LXC::Config->parse_ct_mountpoint($conf->{$ms});
+   my $volid = $volume->{volume};
+
+   PVE::Storage::activate_volumes($storecfg, [$volid]);
+
+   my $template_volid = PVE::Storage::vdisk_create_base($storecfg, $volid);
+   $volume->{volume} = $template_volid;
+   $conf->{$ms} = PVE::LXC::Config->print_ct_mountpoint($volume, $ms eq 
"rootfs");
+});
 
 PVE::LXC::Config->write_config($vmid, $conf);
 }
-- 
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 container 2/2] Mark CT as a template after rename volumes.

2018-05-23 Thread Wolfgang Link 
If a rename fails, the CT should not mark as a template.
---
 src/PVE/API2/LXC.pm | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
index bce5fa3..c016b44 100644
--- a/src/PVE/API2/LXC.pm
+++ b/src/PVE/API2/LXC.pm
@@ -1168,13 +1168,13 @@ __PACKAGE__->register_method({
 
my $realcmd = sub {
PVE::LXC::template_create($vmid, $conf);
-   };
 
-   $conf->{template} = 1;
+   $conf->{template} = 1;
 
-   PVE::LXC::Config->write_config($vmid, $conf);
-   # and remove lxc config
-   PVE::LXC::update_lxc_config($vmid, $conf);
+   PVE::LXC::Config->write_config($vmid, $conf);
+   # and remove lxc config
+   PVE::LXC::update_lxc_config($vmid, $conf);
+   };
 
return $rpcenv->fork_worker('vztemplate', $vmid, $authuser, 
$realcmd);
};
-- 
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] [PATCH manager 3/3] fix #427: add notes panel to node

2018-05-23 Thread Thomas Lamprecht 
On 5/22/18 5:02 PM, Dominik Csapak wrote:
> Signed-off-by: Dominik Csapak 
> ---
>  www/manager6/node/Config.js | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/www/manager6/node/Config.js b/www/manager6/node/Config.js
> index 9e9f49c5..077d543d 100644
> --- a/www/manager6/node/Config.js
> +++ b/www/manager6/node/Config.js
> @@ -125,6 +125,19 @@ Ext.define('PVE.node.Config', {
>   iconCls: 'fa fa-book',
>   itemId: 'summary',
>   xtype: 'pveNodeSummary'
> + },
> + {
> + title: gettext('Notes'),
> + iconCls: 'fa fa-sticky-note-o',
> + itemId: 'notes',
> + xtype: 'panel',
> + items: [
> + {
> + xtype: 'pveNotesView',
> + pveSelNode: me.pveSelNode,
> + border: false
> + }
> + ]
>   }
>   );
>   }
> 

Hmm, do we really want this as full new panel?
Or should it be in integrated in the summary panel?
I honestly expected that you put it there once  I saw this series,
would then be consistent with VMs and CTs...

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

Re: [pve-devel] [PATCH V2 ifupdown2 0/2] ifupdown2 package

2018-05-23 Thread Alexandre DERUMIER 


Alexandre Derumier 
Ingénieur système et stockage 

Manager Infrastructure 


Fixe : +33 3 59 82 20 10 



125 Avenue de la république 
59110 La Madeleine 
[ https://twitter.com/OdisoHosting ] [ https://twitter.com/mindbaz ] [ 
https://www.linkedin.com/company/odiso ] [ 
https://www.viadeo.com/fr/company/odiso ] [ 
https://www.facebook.com/monsiteestlent ] 

[ https://www.monsiteestlent.com/ | MonSiteEstLent.com ] - Blog dédié à la 
webperformance et la gestion de pics de trafic

- Mail original -
De: "Alexandre Derumier" 
À: "pve-devel" 
Cc: "Alexandre Derumier" 
Envoyé: Jeudi 17 Mai 2018 12:25:08
Objet: [PATCH V2 ifupdown2 0/2] ifupdown2 package

Changelog v2: 
- use submodule for ifupdown2 src 
- split proxmox/extra patches 
- add description in 0004-add-dummy-mtu-bridgevlanport-modules.patch 
- add a note in this cover letter about systemd-networkd and ipv6 madness 

Hi, 

Theses last months, I'm working on vxlan implementation. (I'll send info in 
coming weeks) 

I have worked on classic ifupdown, but it's not super clean to implement, 
when we have complex configuration. 

ifupdown2 is currently well maintained by cumulus since 2014, and support all 
features from last kernels. 
(vxlan (unicast, multicast, frr, arp suppression, vrf, vlanaware bridge, 
vlan attributes on interfaces, ...) 
and compatible with classic ifupdown syntax. 


This package is based on cumulus branch 
https://github.com/CumulusNetworks/ifupdown2/tree/cl3u18 
as the master/debian branch is old and don't have all features 
(cumulus is planning to rebase it in coming months) 

For now, it could be great to simply propose ifupdown2 as alternative to 
proxmox users. 
and maybe in 1 or 2 years, if it's working great, make it default for proxmox6 
? 

Some advantages vs classic ifupdown: 

-we can reload configuration ! (ifreload -a, or systemctl reload networking). 
ifupdown2 maintain graphs dependencies between interfaces. 

(Note that as we don't define tap,veth interfaces in /etc/network/interfaces, 
they are not bridged anymore if you do ifdown/ifup vmbr0, 
but it don't remove them on ifreload vmbr0) 

-we can define ipv4/ipv6 in same interface 
(no need anymore iface inet6 static, iface inet static, or iface inet manual, 
but old iface inet syntax is still supported) 

auto eth0 
iface eth0 
address 192.168.0.1 
address 2001:db8::1:1/64 
address 2001:db8::2:2/64 

or multiple ip on loopback 

auto lo 
iface lo inet loopback 
address 10.3.3.3/32 
address 10:3:3::3/128 
-classic pre-up scripts still works (if users have custom config) 

- for ovs I just have needed to make a small workaround in ovs ifupdown script 
(see my ovs patch), 
and a small config change (replace allow-ovs by auto). 
Currently, I don't do in ifupdown2 post-install script 

-templating support: example: creating vxlan interfaces from vxlan30->vxlan100 

auto all 
%for v in range(30,100): 

auto vxlan${v} 
iface vxlan${v} 
vxlan-id ${v} 
vxlan-local-tunnelip 10.59.100.231 
bridge-learning off 
bridge-arp-nd-suppress on 
bridge-unicast-flood off 
bridge-multicast-flood off 
bridge-access ${v} 
%endfor 

some documentation here: 
https://support.cumulusnetworks.com/hc/en-us/articles/202933638-Comparing-ifupdown2-Commands-with-ifupdown-Commands
 


About systemd-networkd: 
- Currently it can't reload configuration 
https://github.com/systemd/systemd/issues/6654 
- unicast vxlan it not supported 
https://github.com/systemd/systemd/issues/5145 
- I think we don't have to maintain a systemd package if we need to extend it 
- new features seem to take years to come 
- IPV6: systemd-networkd reimplement kernel features (ipv6 RA,...) with tons of 
bugs (some not yet fixed) 
http://ipv6-net.blogspot.fr/2016/11/ipv6-systemd-another-look.html 
http://ipv6-net.blogspot.fr/2016/04/systemd-oh-you-wanted-to-run-ipv6.html 
https://github.com/systemd/systemd/issues/8906 


Alexandre Derumier (2): 
add debian dir 
add ifupdown2 submodule 

.gitmodules | 3 + 
debian/changelog | 174 + 
debian/compat | 1 + 
debian/control | 31  
debian/copyright | 28  
...0001-start-networking-add-usr-bin-in-PATH.patch | 28  
...ns-scripts-fix-ENV-for-interfaces-options.patch | 29  
...3-netlink-IFLA_BRPORT_ARP_SUPPRESS-use-32.patch | 31  
.../extra/0004-add-vxlan-physdev-support.patch | 159 +++ 
debian/patches/pve/0001-config-tuning.patch | 52 ++ 
.../pve/0002-manual-interfaces-set-link-up.patch | 58 +++ 
...e-tap-veth-fwpr-interfaces-from-bridge-on.patch | 27  
...0004-add-dummy-mtu-bridgevlanport-modules.patch | 74 + 
debian/patches/series | 8 + 
debian/rules | 21 +++ 
ifupdown2 | 1 + 
16 files changed, 725 insertions(+) 
create mode 100644 .gitmodules 
create mode 100644 debian/changelog 
create mode 100644 debian/compat 
create mode 100644 debian/control 
create mode 100644 debian/copyright 
create mode 100644

Re: [pve-devel] [PATCH V2 ifupdown2 0/2] ifupdown2 package

2018-05-23 Thread Alexandre DERUMIER 
any comment ?


- Mail original - 
De: "Alexandre Derumier"  
À: "pve-devel"  
Cc: "Alexandre Derumier"  
Envoyé: Jeudi 17 Mai 2018 12:25:08 
Objet: [PATCH V2 ifupdown2 0/2] ifupdown2 package 

Changelog v2: 
- use submodule for ifupdown2 src 
- split proxmox/extra patches 
- add description in 0004-add-dummy-mtu-bridgevlanport-modules.patch 
- add a note in this cover letter about systemd-networkd and ipv6 madness 

Hi, 

Theses last months, I'm working on vxlan implementation. (I'll send info in 
coming weeks) 

I have worked on classic ifupdown, but it's not super clean to implement, 
when we have complex configuration. 

ifupdown2 is currently well maintained by cumulus since 2014, and support all 
features from last kernels. 
(vxlan (unicast, multicast, frr, arp suppression, vrf, vlanaware bridge, 
vlan attributes on interfaces, ...) 
and compatible with classic ifupdown syntax. 


This package is based on cumulus branch 
https://github.com/CumulusNetworks/ifupdown2/tree/cl3u18 
as the master/debian branch is old and don't have all features 
(cumulus is planning to rebase it in coming months) 

For now, it could be great to simply propose ifupdown2 as alternative to 
proxmox users. 
and maybe in 1 or 2 years, if it's working great, make it default for proxmox6 
? 

Some advantages vs classic ifupdown: 

-we can reload configuration ! (ifreload -a, or systemctl reload networking). 
ifupdown2 maintain graphs dependencies between interfaces. 

(Note that as we don't define tap,veth interfaces in /etc/network/interfaces, 
they are not bridged anymore if you do ifdown/ifup vmbr0, 
but it don't remove them on ifreload vmbr0) 

-we can define ipv4/ipv6 in same interface 
(no need anymore iface inet6 static, iface inet static, or iface inet manual, 
but old iface inet syntax is still supported) 

auto eth0 
iface eth0 
address 192.168.0.1 
address 2001:db8::1:1/64 
address 2001:db8::2:2/64 

or multiple ip on loopback 

auto lo 
iface lo inet loopback 
address 10.3.3.3/32 
address 10:3:3::3/128 
-classic pre-up scripts still works (if users have custom config) 

- for ovs I just have needed to make a small workaround in ovs ifupdown script 
(see my ovs patch), 
and a small config change (replace allow-ovs by auto). 
Currently, I don't do in ifupdown2 post-install script 

-templating support: example: creating vxlan interfaces from vxlan30->vxlan100 

auto all 
%for v in range(30,100): 

auto vxlan${v} 
iface vxlan${v} 
vxlan-id ${v} 
vxlan-local-tunnelip 10.59.100.231 
bridge-learning off 
bridge-arp-nd-suppress on 
bridge-unicast-flood off 
bridge-multicast-flood off 
bridge-access ${v} 
%endfor 

some documentation here: 
https://support.cumulusnetworks.com/hc/en-us/articles/202933638-Comparing-ifupdown2-Commands-with-ifupdown-Commands
 


About systemd-networkd: 
- Currently it can't reload configuration 
https://github.com/systemd/systemd/issues/6654 
- unicast vxlan it not supported 
https://github.com/systemd/systemd/issues/5145 
- I think we don't have to maintain a systemd package if we need to extend it 
- new features seem to take years to come 
- IPV6: systemd-networkd reimplement kernel features (ipv6 RA,...) with tons of 
bugs (some not yet fixed) 
http://ipv6-net.blogspot.fr/2016/11/ipv6-systemd-another-look.html 
http://ipv6-net.blogspot.fr/2016/04/systemd-oh-you-wanted-to-run-ipv6.html 
https://github.com/systemd/systemd/issues/8906 


Alexandre Derumier (2): 
add debian dir 
add ifupdown2 submodule 

.gitmodules | 3 + 
debian/changelog | 174 + 
debian/compat | 1 + 
debian/control | 31  
debian/copyright | 28  
...0001-start-networking-add-usr-bin-in-PATH.patch | 28  
...ns-scripts-fix-ENV-for-interfaces-options.patch | 29  
...3-netlink-IFLA_BRPORT_ARP_SUPPRESS-use-32.patch | 31  
.../extra/0004-add-vxlan-physdev-support.patch | 159 +++ 
debian/patches/pve/0001-config-tuning.patch | 52 ++ 
.../pve/0002-manual-interfaces-set-link-up.patch | 58 +++ 
...e-tap-veth-fwpr-interfaces-from-bridge-on.patch | 27  
...0004-add-dummy-mtu-bridgevlanport-modules.patch | 74 + 
debian/patches/series | 8 + 
debian/rules | 21 +++ 
ifupdown2 | 1 + 
16 files changed, 725 insertions(+) 
create mode 100644 .gitmodules 
create mode 100644 debian/changelog 
create mode 100644 debian/compat 
create mode 100644 debian/control 
create mode 100644 debian/copyright 
create mode 100644 
debian/patches/extra/0001-start-networking-add-usr-bin-in-PATH.patch 
create mode 100644 
debian/patches/extra/0002-addons-scripts-fix-ENV-for-interfaces-options.patch 
create mode 100644 
debian/patches/extra/0003-netlink-IFLA_BRPORT_ARP_SUPPRESS-use-32.patch 
create mode 100644 debian/patches/extra/0004-add-vxlan-physdev-support.patch 
create mode 100644 debian/patches/pve/0001-config-tuning.patch 
create mode 100644 debian/patches/pve/0002-manual-interfaces-set-link-up.patch 
create

[pve-devel] applied: [PATCH cluster] use constants for IPC request types

2018-05-23 Thread Wolfgang Bumiller 
applied, with a fixup to the Makefile.am to have IPCConst.pm depend on
cfs-ipc-ops.h in addition to its generator awk script.

On Fri, May 18, 2018 at 12:37:25PM +0200, Thomas Lamprecht wrote:
> Add a simple header with the constants as defines.
> Use a simple awk script to translate this to an perl module with the
> constants exported. awk is far easier to understand and maintain than
> h2ph or h2xs, also their result is quite a mess for such a trivial
> thing, IMO.
> 
> Signed-off-by: Thomas Lamprecht 
> ---
>  data/PVE/Cluster.pm  | 19 +-
>  data/PVE/Cluster/IPCConst.pm.awk | 21 
>  data/PVE/Makefile.am |  8 
>  data/src/cfs-ipc-ops.h   | 42 
> 
>  data/src/server.c| 19 +-
>  5 files changed, 91 insertions(+), 18 deletions(-)
>  create mode 100644 data/PVE/Cluster/IPCConst.pm.awk
>  create mode 100644 data/src/cfs-ipc-ops.h
> 
> diff --git a/data/PVE/Cluster.pm b/data/PVE/Cluster.pm
> index 4e3bf7a..7569abc 100644
> --- a/data/PVE/Cluster.pm
> +++ b/data/PVE/Cluster.pm
> @@ -17,6 +17,7 @@ use PVE::IPCC;
>  use PVE::SafeSyslog;
>  use PVE::JSONSchema;
>  use PVE::Network;
> +use PVE::Cluster::IPCConst;
>  use JSON;
>  use RRDs;
>  use Encode;
> @@ -408,7 +409,7 @@ my $ipcc_get_config = sub {
>  my ($path) = @_;
>  
>  my $bindata = pack "Z*", $path;
> -my $res = PVE::IPCC::ipcc_send_rec(6, $bindata);
> +my $res = PVE::IPCC::ipcc_send_rec(CFS_IPC_GET_CONFIG, $bindata);
>  if (!defined($res)) {
>   if ($! != 0) {
>   return undef if $! == ENOENT;
> @@ -424,7 +425,7 @@ my $ipcc_get_status = sub {
>  my ($name, $nodename) = @_;
>  
>  my $bindata = pack "Z[256]Z[256]", $name, ($nodename || "");
> -return PVE::IPCC::ipcc_send_rec(5, $bindata);
> +return PVE::IPCC::ipcc_send_rec(CFS_IPC_GET_STATUS, $bindata);
>  };
>  
>  my $ipcc_update_status = sub {
> @@ -434,7 +435,7 @@ my $ipcc_update_status = sub {
>  # update status
>  my $bindata = pack "Z[256]Z*", $name, $raw;
>  
> -return &$ipcc_send_rec(4, $bindata);
> +return &$ipcc_send_rec(CFS_IPC_SET_STATUS, $bindata);
>  };
>  
>  my $ipcc_log = sub {
> @@ -443,7 +444,7 @@ my $ipcc_log = sub {
>  my $bindata = pack "CCCZ*Z*Z*", $priority, bytes::length($ident) + 1,
>  bytes::length($tag) + 1, $ident, $tag, $msg;
>  
> -return &$ipcc_send_rec(7, $bindata);
> +return &$ipcc_send_rec(CFS_IPC_LOG_CLUSTER_MSG, $bindata);
>  };
>  
>  my $ipcc_get_cluster_log = sub {
> @@ -452,7 +453,7 @@ my $ipcc_get_cluster_log = sub {
>  $max = 0 if !defined($max);
>  
>  my $bindata = pack "Z*", $max, 0, 0, 0, ($user || "");
> -return &$ipcc_send_rec(8, $bindata);
> +return &$ipcc_send_rec(CFS_IPC_GET_CLUSTER_LOG, $bindata);
>  };
>  
>  my $ccache = {};
> @@ -460,7 +461,7 @@ my $ccache = {};
>  sub cfs_update {
>  my ($fail) = @_;
>  eval {
> - my $res = &$ipcc_send_rec_json(1);
> + my $res = &$ipcc_send_rec_json(CFS_IPC_GET_FS_VERSION);
>   #warn "GOT1: " . Dumper($res);
>   die "no starttime\n" if !$res->{starttime};
>  
> @@ -487,7 +488,7 @@ sub cfs_update {
>  eval {
>   if (!$clinfo->{version} || $clinfo->{version} != $versions->{clinfo}) {
>   #warn "detected new clinfo\n";
> - $clinfo = &$ipcc_send_rec_json(2);
> + $clinfo = &$ipcc_send_rec_json(CFS_IPC_GET_CLUSTER_INFO);
>   }
>  };
>  $err = $@;
> @@ -500,7 +501,7 @@ sub cfs_update {
>  eval {
>   if (!$vmlist->{version} || $vmlist->{version} != $versions->{vmlist}) {
>   #warn "detected new vmlist1\n";
> - $vmlist = &$ipcc_send_rec_json(3);
> + $vmlist = &$ipcc_send_rec_json(CFS_IPC_GET_GUEST_LIST);
>   }
>  };
>  $err = $@;
> @@ -617,7 +618,7 @@ sub rrd_dump {
>  
>  my $raw;
>  eval {
> - $raw = &$ipcc_send_rec(10);
> + $raw = &$ipcc_send_rec(CFS_IPC_GET_RRD_DUMP);
>  };
>  my $err = $@;
>  
> diff --git a/data/PVE/Cluster/IPCConst.pm.awk 
> b/data/PVE/Cluster/IPCConst.pm.awk
> new file mode 100644
> index 000..3c622ec
> --- /dev/null
> +++ b/data/PVE/Cluster/IPCConst.pm.awk
> @@ -0,0 +1,21 @@
> +BEGIN {
> +print "package PVE::Cluster::IPCConst;"
> +print "use strict; use warnings;"
> +print
> +print "use base 'Exporter';"
> +print
> +print "my %IPC_OPS;"
> +print "BEGIN {"
> +print "  %IPC_OPS = ("
> +}
> +
> +/^#define CFS_IPC/ {
> +print "" $2, "=>", $3 ","
> +}
> +
> +END {
> +print "  );"
> +print "}"
> +print "use constant \\%IPC_OPS;"
> +print "our @EXPORT = keys(%IPC_OPS);"
> +}
> diff --git a/data/PVE/Makefile.am b/data/PVE/Makefile.am
> index 1f576b0..393f0c8 100644
> --- a/data/PVE/Makefile.am
> +++ b/data/PVE/Makefile.am
> @@ -4,6 +4,10 @@ IPCC.c: IPCC.xs
>   xsubpp IPCC.xs > IPCC.xsc
>   mv IPCC.xsc IPCC.c
>  
> +Cluster/IPCConst.pm:

[pve-devel] [PATCH qemu-server] fix #1779: vzdump: ensure guest-fsfreeze-thaw is called on error

2018-05-23 Thread Wolfgang Bumiller 
as QMPClient's queue_execute can throw an error

Signed-off-by: Wolfgang Bumiller 
---
 PVE/VZDump/QemuServer.pm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/PVE/VZDump/QemuServer.pm b/PVE/VZDump/QemuServer.pm
index 42680f8..70abe99 100644
--- a/PVE/VZDump/QemuServer.pm
+++ b/PVE/VZDump/QemuServer.pm
@@ -416,16 +416,18 @@ sub archive {
$self->logerr($err);
}
}
 
-   $qmpclient->queue_execute();
+   eval { $qmpclient->queue_execute() };
+   my $qmperr = $@;
 
if ($agent_running){
eval { PVE::QemuServer::vm_mon_cmd($vmid, "guest-fsfreeze-thaw"); };
if (my $err = $@) {
$self->logerr($err);
}
}
+   die $qmperr if $qmperr;
die $qmpclient->{errors}->{$vmid} if $qmpclient->{errors}->{$vmid};
 
if ($cpid) {
POSIX::close($outfileno) == 0 ||
-- 
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] [PATCH manager 1/3] check for VM.Montior privileges on qemu AgentIPView

2018-05-23 Thread Thomas Lamprecht 
On 5/22/18 2:02 PM, Dominik Csapak wrote:
> so that the user does not get the useless 'no information' or
> 'not running' message, but the real cause
> 
> Signed-off-by: Dominik Csapak 
> ---
>  www/manager6/qemu/AgentIPView.js | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/www/manager6/qemu/AgentIPView.js 
> b/www/manager6/qemu/AgentIPView.js
> index ecc091f1..13fe3e9a 100644
> --- a/www/manager6/qemu/AgentIPView.js
> +++ b/www/manager6/qemu/AgentIPView.js
> @@ -128,15 +128,22 @@ Ext.define('PVE.qemu.AgentIPView', {
>   me.running = (store.getById('status').data.value === 'running');
>   /*jslint confusion: false*/
>  
> + var caps = Ext.state.Manager.get('GuiCap');
> +
> + if (!caps.vms['VM.Monitor']) {
> + me.updateStatus(false, gettext('Need VM.Monitor privileges'));

How about: Ext.String.format(gt('Requires {0} privileges'), 'VM.Monitor')

Seems more future proof then to have a translation for every privilege
which is required somewhere and we want the user to inform about it?

btw. could we do something like a: global var printf = Ext.String.format?
It's annoying to write this always out and makes readability worse, IMO.


> + return;
> + }
> +
>   if (me.agent && me.running && me.ipStore.isStopped) {
>   me.ipStore.startUpdate();
>   }
>   me.updateStatus();
>  },
>  
> -updateStatus: function(unsuccessful) {
> +updateStatus: function(unsuccessful, defaulttext) {
>   var me = this;
> - var text = gettext('No network information');
> + var text = defaulttext || gettext('No network information');
>   var more = false;
>   if (unsuccessful) {
>   text = gettext('Guest Agent not running');
> 


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

[pve-devel] applied: [PATCH qemu-server] fix #1780: change datacenter.conf to datacenter.cfg

2018-05-23 Thread Thomas Lamprecht 
On 5/22/18 4:44 PM, Dominik Csapak wrote:
> Signed-off-by: Dominik Csapak 
> ---
>  PVE/QemuServer.pm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index 648a5f8..9c4ac94 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -272,7 +272,7 @@ my $confdesc = {
>  keyboard => {
>   optional => 1,
>   type => 'string',
> - description => "Keybord layout for vnc server. Default is read from the 
> '/etc/pve/datacenter.conf' configuration file.".
> + description => "Keybord layout for vnc server. Default is read from the 
> '/etc/pve/datacenter.cfg' configuration file.".
>  "It should not be necessary to set it.",
>   enum => PVE::Tools::kvmkeymaplist(),
>   default => undef,
> 

applied

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