applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> I think this would also be the first change to the Storage plugin API
> that would warrant bumping its version (in PVE/Storage.pm:37)..
Why exactly? I think this change is fully backward compatible?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
On Tue, Nov 29, 2016 at 09:26:50AM +0100, Dietmar Maurer wrote:
> > I think this would also be the first change to the Storage plugin API
> > that would warrant bumping its version (in PVE/Storage.pm:37)..
>
> Why exactly? I think this change is fully backward compatible?
my initial reaction was
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Hello,
today i've noticed that the firewall is nearly inactive on a node.
systemctl status says:
Nov 29 10:07:05 node2 pve-firewall[2534]: status update error:
ipset_restore_cmdlist: ipset v6.23: Error in line 3: The value of the
CIDR parameter of the IP address is invalid
Nov 29 10:07:14 node2 p
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
In this case an employee managed to create the following ipset:
# cat /var/lib/pve-firewall/ipsetcmdlist1
destroy PVEFW-120-letsencrypt-v4_swap
create PVEFW-120-letsencrypt-v4_swap hash:net family inet hashsize 64
maxelem 64
add PVEFW-120-letsencrypt-v4_swap 0.0.0.0/0
swap PVEFW-120-letsencrypt-v4
On Tue, Nov 29, 2016 at 10:10:53AM +0100, Stefan Priebe - Profihost AG wrote:
> Hello,
>
> today i've noticed that the firewall is nearly inactive on a node.
>
> systemctl status says:
> Nov 29 10:07:05 node2 pve-firewall[2534]: status update error:
> ipset_restore_cmdlist: ipset v6.23: Error in
> So it seems that the whole firewall breaks if there is somewhere
> something wrong.
>
> I think especially for the firewall it's important to jsut skip that
> line but process all other values.
That is how it should work. If there is a bug, we need to fix it. So
the first question is how to tri
On Tue, 29 Nov 2016 10:29:34 +0100 (CET)
Dietmar Maurer wrote:
>
> That is how it should work. If there is a bug, we need to fix it. So
> the first question is how to trigger that bug?
>
iptables does not like catch all like 0.0.0.0/0. It has to be 0/0.
--
Hilsen/Regards
Michael Rasmussen
Ge
Am 29.11.2016 um 10:24 schrieb Fabian Grünbichler:
> On Tue, Nov 29, 2016 at 10:10:53AM +0100, Stefan Priebe - Profihost AG wrote:
>> Hello,
>>
>> today i've noticed that the firewall is nearly inactive on a node.
>>
>> systemctl status says:
>> Nov 29 10:07:05 node2 pve-firewall[2534]: status upda
Am 29.11.2016 um 10:29 schrieb Dietmar Maurer:
>> So it seems that the whole firewall breaks if there is somewhere
>> something wrong.
>>
>> I think especially for the firewall it's important to jsut skip that
>> line but process all other values.
>
> That is how it should work. If there is a bug
Signed-off-by: Thomas Lamprecht
---
pvecm seemed like a reasonable place for this. migrations make only sense in
clustered setups, the settings are in the pve-cluster package
(datacenter.cfg), but I'm naturally open for suggestions about better places.
pvecm.adoc | 98 ++
On Thu, Sep 15, 2016 at 01:09:38PM +0200, Dietmar Maurer wrote:
>
>
> > On September 15, 2016 at 12:25 PM Wolfgang Link wrote:
> >
> >
> > We will check on every start of pveproxy if the logdir are available.
> > If not we make a new one and give www-data permission to this dir.
>
> And you w
---
src/PVE/API2/Firewall/IPSet.pm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/PVE/API2/Firewall/IPSet.pm b/src/PVE/API2/Firewall/IPSet.pm
index 6129c9d..ea6d1a2 100644
--- a/src/PVE/API2/Firewall/IPSet.pm
+++ b/src/PVE/API2/Firewall/IPSet.pm
@@ -187,6 +187,9 @@ sub register_create_
This way the error is visible with pve-firewall compile
without breaking the rest.
---
src/PVE/Firewall.pm | 4
1 file changed, 4 insertions(+)
diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm
index ef74ca2..c7d90f8 100644
--- a/src/PVE/Firewall.pm
+++ b/src/PVE/Firewall.pm
@@ -2773,6
On Tue, Nov 29, 2016 at 11:46:26AM +0100, Fabian Grünbichler wrote:
> On Thu, Sep 15, 2016 at 01:09:38PM +0200, Dietmar Maurer wrote:
> >
> >
> > > On September 15, 2016 at 12:25 PM Wolfgang Link
> > > wrote:
> > >
> > >
> > > We will check on every start of pveproxy if the logdir are availab
Signed-off-by: Dominik Csapak
---
www/manager6/ceph/OSD.js | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/www/manager6/ceph/OSD.js b/www/manager6/ceph/OSD.js
index 25c4f12..d53d46d 100644
--- a/www/manager6/ceph/OSD.js
+++ b/www/manager6/ceph/OSD.js
@@ -188,8 +
this patch improves the ceph gui in several ways:
* make the ceph status in the cluster status clickable
(it leads you to the ceph dashboard)
* adds a noout button
* groups the osd action button logically
* shows icons in osd view for the status
Dominik Csapak (5):
also return the ceph
to get faster from the datacenter dashboard to the ceph dashboard
also refactor the cursor style in the css
Signed-off-by: Dominik Csapak
---
www/css/ext6-pve.css | 3 +++
www/manager6/Workspace.js | 4 +---
www/manager6/dc/Health.js | 26 +-
3 files changed, 29 i
we want to set/get the flags in the ceph/osd tab, so we have to
return it there
Signed-off-by: Dominik Csapak
---
PVE/API2/Ceph.pm | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/PVE/API2/Ceph.pm b/PVE/API2/Ceph.pm
index 7b1bbd0..3dd1439 100644
--- a/PVE/API2/Ceph.pm
this patch adds a set/unset noout button (for easy maintenance of your
ceph cluster) and reorders the buttons so that global actions (reload,
add osd, set noout) are left, and osd specific actions are on the right
to reduce confusion, there is now a label left of the osd actions which
displays the
here we can set/unset a single ceph flag, like noout
Signed-off-by: Dominik Csapak
---
PVE/API2/Ceph.pm | 63
1 file changed, 63 insertions(+)
diff --git a/PVE/API2/Ceph.pm b/PVE/API2/Ceph.pm
index 3dd1439..eaca08d 100644
--- a/PVE/API2/C
in my initial patch series for the regression test, i failed to notice
the missing attributes for the sandisk ssds (which had not been parsed)
Signed-off-by: Dominik Csapak
---
test/disk_tests/ssd_smart/disklist_expected.json | 2 +-
test/disk_tests/ssd_smart/sdd_smart_expected.json | 248 +++
Signed-off-by: Dominik Csapak
---
PVE/Diskmanage.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/PVE/Diskmanage.pm b/PVE/Diskmanage.pm
index abd9ca9..48e6e0a 100644
--- a/PVE/Diskmanage.pm
+++ b/PVE/Diskmanage.pm
@@ -301,6 +301,7 @@ sub get_wear_leveling_info {
'samsung' => 177,
sandisk ssds have a default threshold of '---' on nearly all fields,
which prevents our parsing
Signed-off-by: Dominik Csapak
---
PVE/Diskmanage.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/PVE/Diskmanage.pm b/PVE/Diskmanage.pm
index 938d6a4..abd9ca9 100644
--- a/P
Hi,
+
>>+Here we want to use the 10.1.2.1/24 network as migration network.
>>+migration: secure,network=10.1.2.1/24
I think the network is:
10.1.2.0/24
?
- Mail original -
De: "Thomas Lamprecht"
À: "pve-devel"
Envoyé: Mardi 29 Novembre 2016 10:56:05
Objet: [pve-devel] [PATCH doc
Hi,
On 11/29/2016 04:34 PM, Alexandre DERUMIER wrote:
Hi,
+
+Here we want to use the 10.1.2.1/24 network as migration network.
+migration: secure,network=10.1.2.1/24
I think the network is:
10.1.2.0/24
Both works:
10.1.2.1/24 == 10.1.2.0/24 == 10.1.2.128/24
/24 tells us that the last 8 b
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
comments inline:
> diff --git a/src/PVE/API2/HA/Resources.pm b/src/PVE/API2/HA/Resources.pm
> index 621c9e6..f1fac54 100644
> --- a/src/PVE/API2/HA/Resources.pm
> +++ b/src/PVE/API2/HA/Resources.pm
> @@ -187,6 +187,14 @@ __PACKAGE__->register_method ({
> if !$group_cfg->{ids}->{$grou
> in this state the resource will not get touched by us, all commands
> (like start/stop/migrate) go directly to the VM/CT itself and not
> through the HA stack.
> The resource will not get recovered if its node fails.
>
> Achieve that by simply removing the respective service from the
> manager_s
Why do you call that state "setting ignored"? I would prefer a simple "ignored".
Else we have to document two different states with same semantics.
> diff --git a/src/PVE/API2/HA/Status.pm b/src/PVE/API2/HA/Status.pm
> index dbf23d5..0e081bc 100644
> --- a/src/PVE/API2/HA/Status.pm
> +++ b/src/PVE
36 matches
Mail list logo