On 3/25/19 12:53 PM, Dominik Csapak wrote:
> that is the name we use to connect from spiceproxy and can be either
> ipv4 or ipv6
>
> Signed-off-by: Dominik Csapak
> ---
> PVE/API2Tools.pm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/PVE/API2Tools.pm b/PVE/API2Tools.p
On 3/25/19 4:36 PM, Dominik Csapak wrote:
> to give the user better feedback about the various icons (play, pause,
> warning, error, etc) add a tooltip to the tree elements which
> contain that information
>
> Signed-off-by: Dominik Csapak
> ---
> this is a similar patch to that from my 'lock in
to give the user better feedback about the various icons (play, pause,
warning, error, etc) add a tooltip to the tree elements which
contain that information
Signed-off-by: Dominik Csapak
---
this is a similar patch to that from my 'lock in resources' series,
but without the lock part
this way w
the default sock options of LWP contains AI_ADDRCONFIG, which ignores
loopback addresses (which we need in order to connect to 127.0.0.1)
Signed-off-by: Dominik Csapak
---
src/PVE/CLI/termproxy.pm | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/PVE/CLI/termproxy.pm b/src/PVE/CLI/ter
that is the name we use to connect from spiceproxy and can be either
ipv4 or ipv6
Signed-off-by: Dominik Csapak
---
PVE/API2Tools.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/API2Tools.pm b/PVE/API2Tools.pm
index 2d1bdf25..9f782c92 100644
--- a/PVE/API2Tools.pm
+++
configdrive2 uses /etc/network/interfaces style config instead of the
official yaml one. this does not allow quoting of the ip addresses.
Tested with Windows Server 2016.
Signed-off-by: Mira Limbeck
---
This was an oversight on my part in 4efb58a. This should fix the problem
again. To reproduce
Signed-off-by: Christian Ebner
---
pve-firewall.adoc | 123 --
1 file changed, 110 insertions(+), 13 deletions(-)
diff --git a/pve-firewall.adoc b/pve-firewall.adoc
index 0781334..286c24b 100644
--- a/pve-firewall.adoc
+++ b/pve-firewall.adoc
@
>>I think this would be great.
ok thanks !
>>I suggest we start with simple setups, then test and extend the code and
>>models ...
yes, I'll first works on vlan, this is the simple part
then extend it to vxlan l2
and then on vxlan l3 (with routing and vrf), where it's more complex.
and last,