On 3/11/19 10:50 PM, Stoiko Ivanov wrote:
> As discussed on the list [0] setting a multicast mac-address breaks starting
> containers. This is most evident if you set a mac_prefix for your cluster,
> with
> leading to multicast macs (odd second hexdigit of the first byte).
>
> The proposed idea o
>>does it work with another odd number in the second hex-digit? ("X1:",
>>"X3:","X5:",..."XC:" (for X =~ /A-F0-9/))?
Indeed, odd number in second nibble don't work (1,3,5,7,...,F)
- Mail original -
De: "Stoiko Ivanov"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Lundi 11 Mars 2019 20:45:30
O
MAC-addresses having the LSB of the first octet set, are considered
multicast-addresses (see [0,1]). LXC (the kernel) does not allow
such a mac-address to be set for a device, thus preventing containers from
starting if a multicast prefix is set (reported in [2] by Alexandre)
This patch adapts the
having a container with a multicast mac (see [1]), prevents it from starting
(see [0,3]).
This patch adapts the regex for matching the mac_prefix to only allow even
second hexdigits in the first octet.
[0]
https://lists.linuxcontainers.org/pipermail/lxc-users/2010-August/000783.html
[1] https://
provide direct visual feedback for the related commit in pve-cluster.
Signed-off-by: Stoiko Ivanov
---
Toolkit.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Toolkit.js b/Toolkit.js
index 4f1b623..e31ebad 100644
--- a/Toolkit.js
+++ b/Toolkit.js
@@ -54,7 +54,7 @@ Ext.appl
As discussed on the list [0] setting a multicast mac-address breaks starting
containers. This is most evident if you set a mac_prefix for your cluster, with
leading to multicast macs (odd second hexdigit of the first byte).
The proposed idea of 'die'ing in 'PVE::Tools::random_ether_addr' did not s
creating a VM with a NIC with multicast mac (see [1]) is possible, but setting
the interface's link up inside the guest fails (tested on Debian stable).
The issue was noted with LXC first (see [0,2]) and then tested with Qemu.
This patch adapts the regex for matching the mac_prefix to only allow e
On Mon, 11 Mar 2019 20:17:27 +0100 (CET)
Alexandre DERUMIER wrote:
> >>hm - could be related to multicast mac-addresses? - see [0]
> >>the first octet of the prefix AF has the least-significant bit set
> >>and if I read [1] correctly this implies multicast mac-addresses.
>
>
> It seem that
MAC-addresses having the LSB of the first octet set, are considered
multicast-addresses (see [0,1]). LXC (the kernel) does not allow
such a mac-address to be set for a device, thus preventing containers from
starting if a multicast prefix is set (reported in [2] by Alexandre - thanks!)
This patch
>>hm - could be related to multicast mac-addresses? - see [0]
>>the first octet of the prefix AF has the least-significant bit set and
>>if I read [1] correctly this implies multicast mac-addresses.
It seem that it don't work, with I have a "F" in second character
don't work with "1F:...", "C
Hi,
hm - could be related to multicast mac-addresses? - see [0]
the first octet of the prefix AF has the least-significant bit set and
if I read [1] correctly this implies multicast mac-addresses.
But definitely an issue that is hard to find/unexpected (I had luck
in choosing the correct logline
Ok found the problem,
I had setup a mac address prefix in datacenter:
AF:BB
and it seem to not work with lxc (qemu is fine)
- Mail original -
De: "aderumier"
À: "pve-devel"
Envoyé: Lundi 11 Mars 2019 17:36:03
Objet: [pve-devel] proxmox training week : error starting lxc with networ
Hi,
We are doing some tests in this training week,
and I have a bug never seen before with lxc container, when a network interface
is present in ct
root@kvmformation1:~# pveversion -v
proxmox-ve: 5.3-1 (running kernel: 4.15.18-11-pve)
pve-manager: 5.3-11 (running version: 5.3-11/d4907f84)
pve-
On 3/11/19 3:45 PM, Dominik Csapak wrote:
> if a vm has the 'suspend' lock, we resume with the saved state
> and remove the lock, the saved vmstate and the saved runningmachine
> after the vm started
>
> Signed-off-by: Dominik Csapak
> ---
> PVE/QemuServer.pm | 26 +-
> 1
On 3/11/19 3:45 PM, Dominik Csapak wrote:
> the idea is to have the same logic as with snapshots, but without
> the snapshotting of the disks, and after saving the vm state (incl memory),
> we hard shut off the guest.
>
> this way the disks will not be touched anymore by the guest
>
> to prevent
this enables the use of the suspend to disk code
Signed-off-by: Dominik Csapak
---
PVE/API2/Qemu.pm | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 49aaa48..6466a23 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -23
we will reuse this later
Signed-off-by: Dominik Csapak
---
PVE/QemuConfig.pm | 30 +-
PVE/QemuServer.pm | 34 ++
2 files changed, 35 insertions(+), 29 deletions(-)
diff --git a/PVE/QemuConfig.pm b/PVE/QemuConfig.pm
index 6ba0cc3..6d701
and remove comment that makes no sense
Signed-off-by: Dominik Csapak
---
PVE/QemuServer.pm | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 1d1b687..02bb798 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -7123,8 +7123,7
the idea is to have the same logic as with snapshots, but without
the snapshotting of the disks, and after saving the vm state (incl memory),
we hard shut off the guest.
this way the disks will not be touched anymore by the guest
to prevent any alteration of the vm (incl migration, hw changes, et
if a vm has the 'suspend' lock, we resume with the saved state
and remove the lock, the saved vmstate and the saved runningmachine
after the vm started
Signed-off-by: Dominik Csapak
---
PVE/QemuServer.pm | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git
implement suspend to disk for vms
the idea is the following:
add a 'suspend' lock
halt execution of the vm
save the vmstate to a file/disk/etc.
hard poweroff the vm (qmp quit)
on the next start check for 'suspend' lock
resume from saved state
the lock prevents any changes to the vm that would p
On 3/11/19 3:06 PM, Mira Limbeck wrote:
> Signed-off-by: Mira Limbeck
> ---
> pvecm.adoc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/pvecm.adoc b/pvecm.adoc
> index 1f95bdc..4b4747f 100644
> --- a/pvecm.adoc
> +++ b/pvecm.adoc
> @@ -180,7 +180,7 @@ Votequorum inf
Signed-off-by: Mira Limbeck
---
pvecm.adoc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pvecm.adoc b/pvecm.adoc
index 1f95bdc..4b4747f 100644
--- a/pvecm.adoc
+++ b/pvecm.adoc
@@ -180,7 +180,7 @@ Votequorum information
Expected votes: 4
Highest expected: 4
Total vo
On 3/11/19 11:20 AM, he...@initfour.nl wrote:
> From: Herman van Rink
>
> ---
> configs/vzdump.conf | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configs/vzdump.conf b/configs/vzdump.conf
> index c533030f..f69b69c4 100644
> --- a/configs/vzdump.conf
> +++ b/configs/vz
From: Herman van Rink
Removes a ':'
Herman van Rink (1):
Remove typo from vzdump.conf
configs/vzdump.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.17.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.co
From: Herman van Rink
---
configs/vzdump.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/vzdump.conf b/configs/vzdump.conf
index c533030f..f69b69c4 100644
--- a/configs/vzdump.conf
+++ b/configs/vzdump.conf
@@ -14,4 +14,4 @@
#maxfiles: N
#script: FILENAME
#exc
Am 3/11/19 um 10:07 AM schrieb Alwin Antreich:
> On Mon, Mar 11, 2019 at 09:44:17AM +0100, Thomas Lamprecht wrote:
>> Am 3/8/19 um 3:41 PM schrieb Alwin Antreich:
>>> @@ -1630,6 +1630,8 @@ __PACKAGE__->register_method({
>>> PVE::Tools::run_command(['resize2fs', $path]);
>>>
On Mon, Mar 11, 2019 at 09:44:17AM +0100, Thomas Lamprecht wrote:
> Am 3/8/19 um 3:41 PM schrieb Alwin Antreich:
> > On resizing a container's disk image the filesystem is extended and in
> > the case of RBD the returned path of the volume was not a path to a
> > mapped device.
> >
> > This patch
Am 3/8/19 um 3:41 PM schrieb Alwin Antreich:
> On resizing a container's disk image the filesystem is extended and in
> the case of RBD the returned path of the volume was not a path to a
> mapped device.
>
> This patch uses map_volume (respectively unmap_volume) to get a device
> mapped and its p
29 matches
Mail list logo
