We need to be very careful changing such things. For example we use the return
value
in PVE::Cluster:: gen_pve_ssl_cert()
It is also use in PVE::API::OpenVZ
We need to fix that too if we allow more than one domain.
diff --git a/data/PVE/INotify.pm b/data/PVE/INotify.pm index
I just re-read 'man resolv.conf', and I think we should not merge
'domain' and 'search', and return both values instead?
diff --git a/data/PVE/INotify.pm b/data/PVE/INotify.pm index
850668a..0d871d9 100644
--- a/data/PVE/INotify.pm
+++ b/data/PVE/INotify.pm
@@ -536,7 +536,7 @@ sub
So maybe disabling it is the better choice.
I have talked again with my network engineer, he say it's really shouldn't be
break anything.
Our production servers don't have anymore multicast errors since the change.
OK, just uploaded a new kernel to pvetest (disabled
Thanks !
I'll test it today
- Mail original -
De: Dietmar Maurer diet...@proxmox.com
À: Alexandre DERUMIER aderum...@odiso.com
Cc: pve-devel@pve.proxmox.com
Envoyé: Vendredi 8 Mars 2013 11:46:18
Objet: RE: [pve-devel] corosync, multicast problem because of vmbr
multicast_snooping
That's what I think too. We are using search as if it was domain. In
fact, domain defines the domain the computer is actually on, search
field defines the domain where to resolve relatives names.
I think we must not use search field when creating ssl certificates !
So we need to modify
That's what I think too. We are using search as if it was domain. In fact,
domain
defines the domain the computer is actually on, search field defines the
domain
where to resolve relatives names.
I think we must not use search field when creating ssl certificates !
yes, only use
That seems a good idea.
We should also change the field name in web interface to keep it clear.
yes.
The only problem is how we translate the current configuration? Form what I see,
current installations have a single domain like:
# cat /etc/resolv.conf
search test.com
nameserver 1.2.3.4
I
Maybe it would be better to duplicate and keep the first entry? If a
configuration uses it already, we should avoid destroying that
configuration:
#cat /etc/resolv.conf
search domain1.com domain2.com
nameserver 1.2.3.4
would give:
search domain1.com domain2.com
domain domain1.com
nameserver
I am not sure this is useful because in most cases search value will be equal
to
domain value but we would be sure we don't break anything
fom man resolv.conf:
search Search list for host-name lookup.
The search list is normally determined from the local domain
I removed the kernel from the pvetest repository, because it breaks multicast
totally.
So please compile yourself, code is in git.
I'll test it today
- Mail original -
De: Dietmar Maurer diet...@proxmox.com
À: Alexandre DERUMIER aderum...@odiso.com
Cc:
Signed-off-by: Damien PIQUET piqu...@gmail.com
---
data/PVE/INotify.pm | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/data/PVE/INotify.pm b/data/PVE/INotify.pm
index 850668a..35c71b9 100644
--- a/data/PVE/INotify.pm
+++ b/data/PVE/INotify.pm
@@
This version uses the first entry of search if no domain is found.
When edited, it creates or replaces domain entry. It does not update
search entries at all.
I still have to change the field name in the interface and limit input
to only one domain, but I'll send another patch for this.
2013/3/8
multicast also does not work between updated nodes.
Just an idea, can you try to reboot your physicals switchs ?
Maybe old igmp snooping from bridge was propagated to your switchs...
(I think that igmp queries are send from linux bridge to all interfaces
connected to it)
But Indeed, that's
Hi Michael,
You are certain that it is not your switch which is causing problems?
Do you talk to me or Dietmar ?
I have never seen multicast problems in my log files and my switch will
block multicast traffic unless multicast snooping is enabled on the
ports involved or the entire vlan.
This
But Indeed, that's not an easy update,i'm not sure it's possible to push it
by
default to next kernel.
You are certain that it is not your switch which is causing problems?
@alexandre: what switch model do you use?
___
pve-devel mailing list
On Fri, 8 Mar 2013 19:21:52 +0100
Michael Rasmussen m...@datanom.net wrote:
The Phd thesis describing the igmp snooping implementation in linux
bridges can be downloaded here: http://eprints.fri.uni-lj.si/1086/
Ups, just found out it is not translated in English:-)
--
Hilsen/Regards
@alexandre: what switch model do you use?
production: cisco 6500 WS-X6548 modules
test : cisco 2960g
Both have igmp snooping manually disabled.
Note that my main problem was that, when shutting down a node of the cluster,
after 2 min, all nodes linux bridges blocked the multicast
The really strange thing is that omping seems to work. So maybe multicast
works,
but corosync is broken. So it is maybe related to recent corosync updates?
It's possible that omping don't use the same multicast address that your
cluster ?
(igmp snooping filter by multicast address group)
18 matches
Mail list logo
