> '...' substitutions won't be in POSIX anymore.
That may be, but we would have to absolutely hate our customers to remove
support for this construct from our shells, so the positions of POSIX on
the matter seem a bit academic.
--
meem
___
zones-discu
> > I don't see how that addresses the primary point, which is that Solaris
> > brands seem to suffer from code duplication. Are you asserting that the
> > amount of code duplication between the sn1 and solaris10 brands is unique
> > to that situation and is not something that will occur agai
> > I was wondering about this too. Indeed, there seems be a sizeable amount
> > of duplicated code now. Why is this the right design?
>
> Because the sn1 brand is an internal brand for testing
> and is not delivered to customers. Once the solaris10
> brand is integrated, the sn1 brand w
> also, i would have though you'd commited to doing this work when you
> decided to fork the sn1 brand code instead of making it common.
I was wondering about this too. Indeed, there seems be a sizeable amount
of duplicated code now. Why is this the right design?
--
meem
> On a related topic, is there a reason you can't "snoop -d /dev/igb1" in
> the non-global zone, where igb1 is the NIC dedicated to the zone?
That should work fine (well, "snoop -d igb1" should).
--
meem
___
zones-discuss mailing list
zones-discuss@
> > Do a "man snoop" and search for the word "zone".
>
> My argument wasn't that there were zero bugs in the OS. That keyword
> seems to me to be pretty clearly a defect in snoop. (And apparently a
> recent one; less than a year old.)
... and indeed, there's a CR open to allow snoop to ac
> We've completed the development for the Phase I
> work on the solaris10 brand. I've posted a
> full webrev at:
>
> http://cr.opensolaris.org/~gjelinek/webrev.646/
>
> Let me know if there are any comments.
I see that ip-type=exclusive is regarded as "experimental" in
s10_support.c
> > As I've mentioned in the past to Dan, it's worth noting that Crossbow is
> > not the only project that has significant impact here -- e.g., Clearview
> > UV and Clearview IPMP (among other projects) also made significant changes
> > to both kernel and userland that are presumed to be in lo
> Part 2: solaris10 Brand
>
>
> The solaris10 brand is conceptually similar to the existing solaris8
> and solaris9 brands and builds directly on the BrandZ infrastructure
> that was created to support the lx brand. Familiarity with BrandZ
> and the solaris8 a
> I admit, I'm curious what needs to be emulated? I would think that
> Solaris 10 zones would work just fine under OpenSolaris as native
> branded zones.
>From the networking side at least, there's a fair bit of work here. In
particular, there are a number of features that have been removed
> > Thanks for looking at this. I'll take a look
> > at each of your recommendations. One factor
> > is that we plan on backporting this to S10, so
> > I want to keep things working on that release
> > with a minimum of changes.
>
> Erm... the warnings returned by $ ksh93 -n # apply to
> You mean if zone1 and zone2 were plumbed on e1000g1:1, and e1000g1:2,
> traffic will never be observable no matter what. I can live with
> this.
All IP packets can be observed as of Nevada build 103; see
http://blogs.sun.com/seb/ for some examples with zones.
--
meem
_
> "p2v.ksh" triggers lots of warnings when scanned via $ shlint p2v.ksh #
Has consensus been reached in the OpenSolaris community on the advice
offered by shlint? If not, it would seem that needs to be done first.
--
meem
___
zones-discuss mailing li
> Vanity naming is not a zone feature, the reason I mentioned it is that
> it wold be a nice feature when migrating zones between machines with
> different NIC:s.
Indeed, this was one of the uses we had in mind for the feature (and of
course, you can use it today with OpenSolaris :-)
--
> The original question here was about what sort of source selection
> behavior to expect, and what happens when the "wrong" routes are
> present when a TCP connection is attempted. As far as the user is
> concerned, the answers are (1) you must discard a TCP socket if it
> fails to connect
> You're assuming the packets sent on this UDP socket all have the same
> destination and that routing does not change between transmissions.
I'm not assuming that, just pointing out that in general there will
not be a different source address in each packet, and that for a given
destination we
> If you don't explicitly bind a preferred address to use (most
> applications do not), then the kernel will choose an address for you.
> With UDP, this happens on a packet-by-packet basis.
Really? I'd expect the first packet to a given destination to construct
an IRE cache entry, and then fo
> > > Contrary to what everyone else says, with a bit of customization dhcpd
> > > can run zones just fine. Solaris 10 update 3 and later (I forget
> > > which Nevada build) have all the required bits in place.
> > >
> > >
> > http://mail.opensolaris.org/pipermail/install-discuss/2007
> Contrary to what everyone else says, with a bit of customization dhcpd
> can run zones just fine. Solaris 10 update 3 and later (I forget
> which Nevada build) have all the required bits in place.
>
> http://mail.opensolaris.org/pipermail/install-discuss/2007-March/004266.html
Yep, it ca
> I just installed a local zone with a different IP subnet and different
> netmask than its global zone. There is no default route shown with
> netstat -r. In a local zone which is in the same subnet / netmask as
> its globsl zone, there is a default route.
>
> So, the question is, can this
> Actually, my bad, the reason is that the vlan-type is non-vlan as shown
> in the dladm output.
Actually, the reason is that VNIC support is not yet in OpenSolaris;
it's under development as part of Project Crossbow.
--
meem
___
zones-discuss mailin
> My statement "At the beginning..." meant "When the first part(s) of
> Crossbow are in Solaris 10." At this point, IP Instances will probably
> be that "first part" and that is what I was talking about.
OK. From an engineering perspective, I consider the projects
complementary but independe
> > It might be nice to have a full list of the (otherwise Sun supported)
> > NICs which don't work, if there isn't one already. I wasn't aware
> > of this particular limitation. Do you know of such a list?
>
> At the beginning, Crossbow will only support GLDv3 NICs. Is there a
> list of
> - Currently must be tied to a physical NIC -- in other words
> you must dedicate a real NIC (not a logical interface)
> to each IP instance you want to run.
Or you can dedicate a VLAN on that NIC.
--
meem
___
zones-dis
> >The IP Instances part of project crossbow deliver the feature to have a zone
> >have its own view of the stack. It is available as a BFU on top of NV, but
> >not yet integrated into NV.
>
> IP instances have integrated. (build 56 or something?
Build 57 (and it's mostly separate from Cro
> 6414178 RFE: prepare in advance for zone migration
I'm a bit confused here. It seems like the implemented functionality
serves the same purpose as "preparing in advance" for zone migration, but
does not actually "prepare in advance". Should the synopsis be updated?
Or am I missing something?
> > Should these functions be dealing with "link names" rather than
> > "interfaces" to avoid confusion with the interfaces that ifconfig(1M)
> > deals with?
>
> Good point.
> We've renamed them to have "datalink" in their names.
> Jerry also pointed out that we should be more careful abou
> You need to interpose the zone_create function, add the privilege to
> the privilege mask and call the original zone_create.
Egad. The zone_create() function is not part of any documented or
stable API; interpose on it at your peril.
--
meem
___
z
> > What happens when ce0 goes down ? Understood for running zone the i/p
> > will failover to ce2 BUT if zone needs rebooting, do I now have to
> > change physical to ce2 (ce0 is still down) ? If there any workaround ?
>
> I haven't tried this myself, but since the system knows that ce0 a
> In general, we have the 4 standard values (/usr, /platform,
> /lib & /sbin) for a sparse zone and no settings for a whole-root
> zone. The one gray area is probably /opt. We were just
> talking about this the other day and if we should impose
> some restrictions on inherit-pkg-dir to make
> This is an issue in S10 at two levels:
> 1. The /etc/hostname. and related files are ignored when a zone
> is booted.
FWIW, as NWAM is currently specified, they will soon be ignored for global
zone boots too (with appropriate transition mechanisms).
--
meem
> > > With regard to the third bullet, please see my concerns above about the
> > > introduction of "list -l". I think this should be part of a general
> > > zone status/health facility or perhaps something that dladm(1M) can
> > > print about the link names and how their assignment zone-
> With regard to the third bullet, please see my concerns above about the
> introduction of "list -l". I think this should be part of a general
> zone status/health facility or perhaps something that dladm(1M) can
> print about the link names and how their assignment zone-wise.
Displaying th
> I think that some minimal syslogging is warranted (I've tried to keep it
> simple here) because we do know that customers have a degree of comfort
> with syslog, and because it fits readily into various existing 3rd party
> monitoring packages.
But it falls apart in the long run since the o
> Such as?
No strong preference, but it should be something that can be versioned,
extensible, parsed unambiguously and easily, and unaffected by locale.
Maybe general purpose event channels?
--
meem
___
zones-discuss mailing list
zones-discuss@open
> So here are my questions:
>
> - Do you think this is useful?
>
> - Do you think the log level (Info) is right? daemon.info is
> *not* logged by default, whereas notice is. (So basically: do
> you want these messages in /var/adm/messages by default, or not?)
>
>
> > The fix for bug 6395576 adds the following failure mode:
> >
> > If two interfaces are in an IPMP group and there are no global zone
> > addresses attached to the interfaces (link-based failure detection),
> > then upon a link failure and failback, a zone IP address can migrate
> > back
> I will most likely be able to test it once it is there - it would be easier
> for me to test against S10 than it would be against Nevada. However,
> assuming these changes fall within usr/src/cmd-inet/usr.lib/in.mpathd and
> not somewhere under usr/src/uts, it would probably be pretty
> st
Mike,
Sorry for the delay. I think you have exposed at least 3 bugs in the
current implementation:
1. It's possible for in.mpathd to get confused and think that a
replacement ipif is a test address. In your case, the
replacement ipif was the 0.0.0.0 NOFAILOVER add
> I find that when I do cable pulls (pull bge0, replace bge0, pull bge1,
> replace bge1) that a zone IP address has been transitioned to a test
> address. Yuck!
A test address? It actually ends up with IFF_NOFAILOVER set?
--
meem
___
zones-discus
> Are you saying that if you have multiple interfaces on the same subnet,
> they must be in an IPMP group, or the config is broken?
Yes -- though the issue is really with having multiple interfaces on the
same link, rather than the same subnet.
> Or if you have multiple IP addresses (on the sa
> Yes, IPMP is IP Multipathing. Even if you have multiple addresses on
> the same subnet on different interfaces, as you do, it does not
> automatically enable IPMP.
Though the resulting configuration is unsupported and broken. That
is, if you have multiple IP interfaces on the same link, the
> I need your expertise to confirm the following issue:
>
> Issue Description: The customer appl A sends a lookup request which is
> destined to be handled by appl B. Both applications are using Cluster
> Logical IP addressed destined for different subnets as configured using
> multiple def
43 matches
Mail list logo
