Hi Garrett,
I just tested 'ndd' within the global zone, a native non-global zone,
and an S10C on x86 and x64 systems and noticed that zones can read ndd
properties but can't write to them (even as root). I take it that ndd
doesn't require a special privilege that a zone root user might not have?
Also, S10C root users can read device properties via 'ndd' but can't
write to them (as is true of zones generally). It doesn't look like ndd
produces different output for devices such as /dev/tcp and /dev/udp as
compared to the global zone, so I don't think this is a problem.
Thanks,
Jordan
On 06/25/09 07:09 PM, Garrett D'Amore wrote:
I'm pretty sure that nearly all of the interfaces used by normal
applications will continue to operate.
One thing that might cause problems is ndd support. Customers used to
using ndd to tweak device or stack settings will probably find many
things have changed or just don't work. (For example, you can't ndd
/dev/hme anymore, you have to use ndd /dev/hme0 or whatever.)
This is more an impact to the administrator than to applications,
though. It may be acceptable to assume that the administrator will only
change things in the global zone using Nevada/OpenSolaris methods rather
than from within a Zone. (I suspect you'd want to disallow such changes
from inside the zone anyway.)
- Garrett
Jordan Vaughan wrote:
Hello networking experts,
I'm one of two engineers working on Solaris 10 Containers (S10Cs), a
project aimed at producing a zone brand that will emulate Solaris 10
user environments in OpenSolaris. (See
http://opensolaris.org/os/project/s10brand for more information.) I'm
going to start evaluating networking within S10Cs in order to discover
which S10 networking behaviors will break in S10Cs.
I suspect that the sweeping changes made to networking in Nevada will
be incredibly difficult to detect and remedy in S10Cs, especially
within exclusive-stack S10Cs. I'm familiar with neither the internals
of Solaris networking nor the networking APIs presented to userland
nor the changes that have caused S10 and Nevada networking to
diverge. I figured that it would be better to consult you first
regarding potential breaks before blindly plunging into a massive
evaluation of networking APIs.
The following questions concern me most:
1. Which applications, networking device interfaces, and system calls
are or will most likely be broken in S10Cs?
2. Given the answer to (1), what are the best means of fixing the
breakage?
3. Which networking test suites can be run within zones and which
will most likely expose breakage in networking APIs within S10Cs?
We (the engineers working on S10Cs) have a few ways of
solving/circumventing breakages in S10Cs:
1. If a break occurs in a system call (i.e., a fix was integrated
into Neavada (but not S10) that introduced a flag day), then we can
[usually] emulate the old S10 system call by interposing on it within
S10Cs.
2. If a break occurs in a device's ioctl interface (ioctl parameters
changed between S10 and Nevada, behaviors changed, etc.), then we have
a few options:
A. Create and push a new streams module on top of the problematic
device from within S10Cs that emulates S10 behaviors.
B. Modify the Nevada version of the device to be more
accommodating of legacy behavior.
C. Enhance emulation of the ioctl system call to detect ioctls
issued to the problematic device and emulate the device's legacy
behavior. (This is the least desirable solution of the three listed
here.)
3. If a broken interface is Sun-private or not widely used, then we
might be able to replace binaries that consume the interface with
native Nevada binaries when the branded zone is booted.
4. If all else fails, we can backport the missing/problematic feature
to S10. (This is obviously the least desirable solution.)
Bear in mind that we have to produce S10 networking behaviors not only
for Sun applications but for ISV applications as well. If a broken
networking interface/API is used by ISVs as well as Sun, then simply
replacing Sun S10 binaries with native equivalents will not be
satisfactory.
Any feedback you can provide would be greatly appreciated. Any help
you can provide in evaluating networking within S10Cs would also be
greatly appreciated.
Thanks for your time.
Regards,
Jordan
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
