On Nov 30, 2007 7:37 AM, Paul Van Der Zwan <[EMAIL PROTECTED]> wrote:
> Host 1:
> global zone   bge0
>                   vni0
> zone1          vni1
> zone2          vni2
> zone3          vni3

When you try this configuration, go into any zone listed above and try
this (when it is safe to reboot):

nslookup anything.com

The address must not be reachable.  The last time I tried
this in Nevada it causes a panic.  The last time I tried it on S10 it
causes one kernel thread to spin (mpstat will show one CPU at 100%

Through bugs.opensolaris.org I opened a bug (6422863) but now I cannot
see that bug through bugs.opensolaris.org.  Anyone from Sun care to

My simplified way to trigger this was:

ifconfig vni0 plumb
ifconfig vni0 up netmask broadcast +
ifconfig vni0 xmit

Zones were not needed to cause this problem.  However, my purpose for
doing this was to make it so that I had an "internal" communication
path between global and non-global zones.  That is, every global zone
would have vni0 at so that non-global zones could have a
reliable address to reach the global zone at.

I just tried to reproduce on S10U4 + all current patches on a T5120.
As soon as I ran nslookup, the following appeared on the console:


mpstat showed that one strand went to 100% sys and 14 other strands
went to between 9% and 59% sys for a total of 345% sys.  Prior to
running nslookup it was 100% idle.  Overall system utilization went
from 100% idle to 3% user and 6% sys (on a 64 processor system).

When I typed reboot, the console began getting spammed with the same
error message above.  The messages were interspersed, possibly
implying that multiple threads were writing the messages.  I had to
hard reset the system to get back.

Be careful with vni.

Mike Gerdts
zones-discuss mailing list

Reply via email to