Am 07.04.21 um 12:25 schrieb Fabian Ebner:
Only match against the file name to avoid false positives with directory names
containing "-$vmid-".
Signed-off-by: Fabian Ebner
---
Found while trying to debug/reproduce a forum thread[0], but the path there
should not be affected by this...
This
On 08.04.21 12:33, Fabian Ebner wrote:
> The code is in a very early state, I'm just sending this to discuss the idea.
> I didn't do a whole lot of testing yet, but it does seem to work.
>
> The idea is rather simple:
> 1. save the state to ramfs
> 2. stop the VM
> 3. start the VM loading the stat
ExtJS email validation regex has a length limit of 6 on the TLD.
This breaks some new gTLDs (e.g. .systems)
Override the validation function and verify against the EMAILRE from
PVE::Tools (used for 'e-mail' in JSONSchema)
Reported in our community forum:
https://forum.proxmox.com/threads/acme-acc
Good Catch.
Thanks Jack !
Le jeudi 08 avril 2021 à 10:32 +0200, Alexandre Bruyelles a écrit :
> On Linux, when no route is found in a vrf, it somehow fallback
> to the default routing table. In our case, that means a leak
> from the overlay to the underlay.
> Adding a low priority unreachable ca
Signed-off-by: Fabian Ebner
---
PVE/QemuServer.pm | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index fa2aad9..0287a80 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -22,7 +22,7 @@ use JSON;
use MIME::B
Signed-off-by: Fabian Ebner
---
PVE/QemuServer.pm | 50 +++
1 file changed, 50 insertions(+)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 983fb2f..fa2aad9 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -7729,4 +7729,54 @@ sub vms
Signed-off-by: Fabian Ebner
---
PVE/QemuConfig.pm | 10 ++
PVE/QemuServer.pm | 13 +
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/PVE/QemuConfig.pm b/PVE/QemuConfig.pm
index 7ee8876..01c51b0 100644
--- a/PVE/QemuConfig.pm
+++ b/PVE/QemuConfig.pm
@@ -208,14 +
and potentially save a big part of a second
Signed-off-by: Fabian Ebner
---
PVE/QemuServer.pm | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 0287a80..a8caa35 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -22,
Signed-off-by: Fabian Ebner
---
PVE/API2/Qemu.pm | 60
1 file changed, 60 insertions(+)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index c56b609..f20cd76 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -836,6 +836,7 @@ __PACKAGE__->r
The code is in a very early state, I'm just sending this to discuss the idea.
I didn't do a whole lot of testing yet, but it does seem to work.
The idea is rather simple:
1. save the state to ramfs
2. stop the VM
3. start the VM loading the state
This approach solves the problem that our stack is
Signed-off-by: Fabian Ebner
---
PVE/QemuServer.pm | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 5a89853..983fb2f 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -5621,6 +5621,27 @@
> Is there a reason why we assume that users without subscription do not want
> such notifications?
>
> As far as I see it, if we change it to
> > $dccfg->{notify_updates} // 1
> Then (until they change something)
> - users with active subscription should _continue_ to get notifications
> - enterp
On 08.04.21 11:21, Dominic Jäger wrote:
> On Wed, Apr 07, 2021 at 10:51:43AM +0200, Thomas Lamprecht wrote:
>> On 07.04.21 10:30, Dominic Jäger wrote:
>>> -# We assume that users with subscriptions want informations
>>> -# about new packages.
>>> -my $notify = ($info && $info->{status} eq 'Active')
On Wed, Apr 07, 2021 at 10:51:43AM +0200, Thomas Lamprecht wrote:
> On 07.04.21 10:30, Dominic Jäger wrote:
> > -# We assume that users with subscriptions want informations
> > -# about new packages.
> > -my $notify = ($info && $info->{status} eq 'Active') ? 1 : 0;
> > +my $notify = $dccfg->{notify
From: Alexandre Bruyelles
On Linux, when no route is found in a vrf, it somehow fallback
to the default routing table. In our case, that means a leak
from the overlay to the underlay.
Adding a low priority unreachable catch-all route is the way to go, as
per the doc: https://www.kernel.org/doc/Do
From: Alexandre Bruyelles
Alexandre Bruyelles (1):
zones: evpn: add a default unreachable, to prevent vrf leak
PVE/Network/SDN/Zones/EvpnPlugin.pm | 1 +
1 file changed, 1 insertion(+)
--
2.31.0
___
pve-devel mailing list
pve-devel@lists.proxmox
Alexandre Bruyelles (1):
zones: evpn: add a default unreachable, to prevent vrf leak
PVE/Network/SDN/Zones/EvpnPlugin.pm | 1 +
1 file changed, 1 insertion(+)
--
2.31.0
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.c
On Linux, when no route is found in a vrf, it somehow fallback
to the default routing table. In our case, that means a leak
from the overlay to the underlay.
Adding a low priority unreachable catch-all route is the way to go, as
per the doc: https://www.kernel.org/doc/Documentation/networking/vrf.t
On 4/8/21 10:32 AM, Alexandre Bruyelles wrote:
Alexandre Bruyelles (1):
zones: evpn: add a default unreachable, to prevent vrf leak
PVE/Network/SDN/Zones/EvpnPlugin.pm | 1 +
1 file changed, 1 insertion(+)
___
pve-devel mailing list
pve-devel
19 matches
Mail list logo
