Re: [zones-discuss] query re zones and trusted solaris
Enda o'Connor - Sun Microsystems Ireland - Software Engineer writes: What is the impact on the use of non-global zones and trusted Solaris? i.e. if I install trusted Solaris, are there any restrictions on the use of non-global zones, expecially with respect to networking? In effect, you can't use any independent zones on a Solaris system with TX (Trusted Extensions) installed. Each zone on a TX system represents a security label. The system as a whole (the global zone and _all_ of the non-global zones) appears as a unified system with multiple labels to the user. This means that zones on a TX system are essentially an implementation detail, and can't be used to create independent Solaris environments. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Non-global zone sending TCP SYN-ACK packet over
Tobias Oberstein writes: One more Q: does stateful IPF work if I'd connect e1000g0-3 to a LACP-capable Switch and combine the ifcs using Solaris 10 1/06 link aggregation to a logical, aggregated interface? Yes, assuming that driver is supported for aggregation. In that case, you'll have the 'ipf' module plumbed atop the 'aggr0' driver, so you'll have a single stream. If you were to use the older Sun Trunking solution, it would work only if there were a single IP stream plumbed for the trunk. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] query re zones and trusted solaris
Enda o'Connor - Sun Microsystems Ireland - Software Engineer writes: I was looking at a box this am that was setup with this scenario, and the non-global zones were apparently not able to see outside the box, they could ping the global etc, but nothing else. Guess that explains that then, need to familarise myself with TX. The situation is a bit complicated, and you should talk with the Rampart team to get some help with it. The non-global zones can have a mix of shared network connectivity and local IP addresses. The latter are typically used for multi-level services contained within a zone, but could be used for other things. For the shared IP address(es), packets are distinguished by the IP security label option. Each zone has a label, and the label on the packet maps it to a particular zone. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] SecurityFocus Article
Ed White writes: I would like to know if this attack could be effective to bypass barriers among OpenSolaris Zones. [...] http://www.securityfocus.com/columnists/402 I don't see how. His attack relies on having free access to PIO registers and video memory. You don't have that in a non-global zone. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone stuck in 'mounted' state
Dick Davies writes: How do I get a zone out of 'mounted' state? Can't find it on any of the state transition diagrams. You shouldn't have one stuck like that. It's an internal state used by packaging tools. If you can see it at all, it's a bug. # zoneadm -z vera1 $ANYTHING zoneadm: zone 'vera1': $ANYTHING operation is invalid for zones in state 'mounted' zoneadm: zone 'vera1': call to zoneadmd failed Try unmount. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] The ability to lock non-global zones
James Dickens writes: The interface would be #zoneadm ?z zonename lock With the zone locked no changes in the global zone effects the non-global zones. I'd suggest using a less general term (pkg-lock, maybe?) and consider using zonecfg instead. So what happens with the default sparse-root zones? If I have a zone locked and I try to remove a package from the global zone, what happens? The bits are going to disappear from the non-global zone (because it's just using lofs mounts), but the packaging data won't be removed. It'll be a phantom. Similarly, adding packages becomes a bit strange. Is this feature available only with whole-root zones? What happens when the lock is disabled? If I add another package to the global zone that depends on things that were added while the lock was enabled, does that work? Do I get a flood of things hauled into the now-unlocked non-global zone by dependency, or does the pkgadd just fail? The system is in a funny state at this point. What happens when a package has system-wide effects? For example, if I remove a package containing a device driver from the global zone, there's no way that package can still exist in any non-global zone, is there? It doesn't matter whether that lock flag is set -- because kernel modules exist only in the global zone, if that package is removed, the non-global zone (even a whole-root zone) will have to lose the device. Otherwise, it looks like a fairly reasonable RFE to me, though I'd be a bit worried about the long-term administrative effects. What distinguishes a pkgadd done for the purpose of adding new application software from a pkgadd done for the purpose of maintaining the system itself seems like a bit of a grey area. (You mention patches, but patches likely aren't the only issue here.) Are you looking for someone to file the RFE, or are you planning to visit bugs.opensolaris.org? -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] traffic/data between zones
Brian Kolaci writes: IHAC that needs proof that traffic between local zones on the same system will not in fact hit the NIC card. There's two scenarios. I guess the first question is what sort of proof would be satisfactory. If we can cite parts of the code, would that help? Or does this person need something with a more solid, mathematic basis? (I have to admit that the word proof is tripping me up here.) First, if one does FTP or scp to transfer files between the zones, how can I prove it doesn't hit the NIC or wire? What function in the IP driver would I look for with DTrace that would hit the NIC or wire? I would check for calls to put(9F) and putnext(9F) from within the IP module (which includes TCP). Second, the same proof (not sure why he thinks this but...) for a filesystem lofs mounted in both zones (from the global zone) and can just copy files back and forth between the zones without hitting the NIC/wire. huh? Perhaps the right question in response is: what problem are you seeing, and what are you trying to do? It's quite unclear to me what would prompt a question about lofs that looks like the above. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
Glenn Faden writes: It can easily tell this though. It's not obvious to me how the non-global zone can determine the hostname of its global zone unless the global zone puts that information somewhere (like in a new file). It should not be based on something flimsy (and user-administrable) like the host name. Instead, I think we need a way to ask the system (perhaps a new ioctl?) whether a given known IP address represents a local address or a remote one. Or just fix the deadlock. ;-} Seems like the kernel has to help out here. I agree. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] FYI: # of logical interfaces in a zone
Steffen Weiberle writes: PS. I was impressed with the linearity of ifconfig going through 8K interfaces. This is due to the work of the SolarMAX project, which converted the kernel ipif database from a linear list to AVL trees. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] /usr read only
Krzys writes: Hello Jeff, thank you for your answer.. well the sinple answer why I need it is because my iPlanet installation does fail when trying to install it in a zone that is not global, aparently it does try to install something in /usr directory which is read only and installation does fail on that... In that case, whole root zones are probably the way to go, along with making sure there isn't already a CR filed against the package in question. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Solaris 10 1/06 to 6/06 upgrade problems
[trimming internal lists] Dave Bevans writes: More information on the OS upgrade issue... This is from the customer... When I'm running in the multi-user state, all of the SAN devices show up as c7 devices (mpxio) and the internals show up as c1. When I boot off of DVD, the SAN devices are still there, but they're translated back to c0 and c1 devices and the internals are c3, (i.e...mpxio isn't in control). The gentleman that I'm working for here, opened a case way back when, #65058360. Can you find out whether mpxio is in the miniroot? ...and if it is, it doesn't appear to be working. It sounds to me like you need to talk to the group that supports mpxio, rather than install or zones. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Live Upgrade and Zones
Jesus Cea writes: Is there any plan to support live upgrade on machines with Solaris zones? Yes. The project code name is Zulu. If affirmative, any timetable?. I don't think we can share that at this time, but it's soon. The plan is to have it in one of the S10 updates. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Creating a zone with the -b option
Marlanne DeLaSource writes: What are the advantages/disadvantages of creating a zone with the -b option (like in the excellent page here http://users.tpg.com.au/bdgcvb/zones.html by Brendan Gregg). It duplicates a lot of space but what can be done that can't be with a normal zone (called a small zone in the page quoted above). It allows users inside the zone to write to the directories (/lib, /platform, /sbin, and /usr) that would otherwise be inherited from the global zone. When a directory is inherited, it's read-only inside the zone, even to all-powerful root. (Though root may, of course, mount other things underneath.) This can be helpful with non-Sun software that (nontheless and despite filesystem(5)) installs to /usr. For what it's worth, the two models are normally called sparse root and whole root. Is it supported ? Everything documented in man pages (such as the -b option) is supported, unless somehow explicitly disclaimed. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Zone in a mounted state ?
Dick Davies writes: On 06/09/06, Jeff Victor [EMAIL PROTECTED] wrote: According to the inline doc, execution can only get there if the zone's root is mounted on $ZONEPATH/lu. I've never used liveupgrade (is that what 'lu' refers to?) Yes, originally. but I saw this when a package install crapped out. Possibly $ZONEPATH/lu is involved then. As Enda said, I got around it by running a 'zoneadm -z myzone unmount'. It is indeed internal. If you see it, then that's a bug. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Re: Convert sparse root to full root zone without reinstall?
Andreas Koppenhoefer writes: See filesystem(5) -- non-OS software shouldn't be delivering to /usr/bin. Good pointer! I've googled several times looking for some definition about correct use of /usr, /opt, etc., but did not find much regarding solaris. Most documents are about Linux' Filesystem Standard. With this manpage originated by Sun we may get software vendor to fix their software for beeing usable in local zones. In the meantime, using whole-root zones where such software is required is probably the least troublesome workaround. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones network documentation redux
Jay Calaus writes: So I guess my question si: Is it possible to configure zones to use the loopback interface? If yes, how? A pointer to a documentation would be great. There's nothing to configure. They do that by default. It's just not possible to communicate _between_ zones using loopback. You need a network interface to do that. Fortunately, it doesn't need to be a real interface. Doing something like this should work: # ifconfig ip.tun0 plumb 192.168.0.1 192.168.0.2 up # ifconfig ip.tun0:1 plumb 192.168.0.2 192.168.0.1 zone test up -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] /etc/zones/index content
Jan Hendrik Mangold writes: I am programatically creating zones and just realized that they all have the same fingerprint in /etc/zones/index. The zones are created from the same template in /etc/zones Is that correct or should I be worried? If the 'fingerprint' you're referring to is the UUID, then this is a known problem. It's CR 6379341, which is fixed in Solaris 10 Update 06/06, and patches 122662-02 (SPARC) and 122663-05 (x86). It's nothing to be worried about; the updates correct the problem, and the software knows how to deal with it. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Company offering Zones hosting
Stephen Hahn writes: * James Carlson [EMAIL PROTECTED] [2006-10-05 13:47]: Dan Price writes: On Thu 05 Oct 2006 at 07:16PM, Alan Burlison wrote: Someone using Solaris 10 Zones for hosting provision, cool to see ^^ [...] Probably something to discuss in opensolaris-mktg (or even cab-discuss, if you conclude it's too controversial). I see Al's made a supporting comment, so maybe best to move to Marketing and see if it's not just a zones thing--would plain hosting with any OpenSolaris distribution be worth a mention? I'm not too opposed to seeing happily used by links on opensolaris.org, though there's probably a fuzzy line there between promoting Open Solaris and just plain old advertising. It might be better still if this were somehow an automatically- generated assemblage of www.$distribution.com/happy-users links, so that each distribution would get a chance to post and maintain the contacts they know about. The original message posted here, though, was about S10. Perhaps it's a too-pedantic distinction to be made, but it seems to me that citing this on opensolaris.org as evidence of the utility of Open Solaris might be a bit risky. It's not actually Open Solaris, though it is Zones. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Re: RFE?: Prevent installation of packages
Jens Elkner writes:
In general, if you want new features quickly, you'll
want to use
Solaris Express.
Yes, actually I really wanna use Express (since Sol 10 software is pretty
much out of date - especially GNOME). But unfortunately it is not supported
by SUN so no chance to use it ... :
Solaris Express is supported. You can buy support contracts on it.
See http://www.sun.com/software/solaris/solaris-express/
It's just not supported in exactly the same way as S10.
BTW: Found a workaround (at least for my case):
pkginfo | awk '{ print $2 }' | grep SUNWstaroffice
/var/sadm/install/gz-only-packages
This reduced the zone size from ~ 950 to ~ 520 MB and the zone install time
from ~ 20 to 14 min.
Any objections against this workaround ?
None, except that it depends on an implementation detail and thus
might stop working at any time and _may_ interfere with upgrade.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Zones and VLAN tagging.
Mike Gerdts writes: On 10/23/06, Roshan Perera [EMAIL PROTECTED] wrote: zonecfg:sz44bsdvapdqc02:net set address=10.165.20.35/23 That should be: set address=10.165.20.35 You will then need an entry in the global zone's /etc/netmasks to ensure that the netmask is set properly as the zone is booted. There's nothing wrong with CIDR notation here. In fact, I'd recommend that users prefer CIDR and shy away from the ancient and feeble /etc/netmasks interface. See the zonecfg(1M) man page for details. That's not the problem the user is seeing. The problem the user is experienced appears to be CR 6367840 -- fixed in Nevada, but not S10. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] What is the proceess to change the physical net to an already working zone?
Ian Matchett writes: How do I move a zone to usebr br bge1:1 /10.12.13.14br Two methods: change the entry in zonecfg and restart the zone, or unplumb the alias and plumb up a new one from the global zone. The first case: # zonecfg -z test zonecfg:test select net physical=bge0 zonecfg:test:net set physical=bge1 zonecfg:test:net end zonecfg:test verify zonecfg:test commit zonecfg:test exit # zoneadm -z test reboot The second case: # ifconfig bge0:1 unplumb # ifconfig bge1:1 10.12.13.14 netmask + broadcast + zone test up -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone creation
Abraham Panicker writes: When creating a zone with zone creation scripts, I am using the option 'create -b' Will it create a sparse root zone or a whole root zone. Whole root. If I wanted to create a sparse root zone, what options would I add to the cmd file script. None -- just remove the -b. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
Erik Nordmark writes: James Carlson wrote: I don't think that argument works on two counts. First, exclusive-IP behavior does not offer complete IP isolation, because you can't (for instance) install your own copy of Firewall-1 or Cisco VPN into a non-global exclusive-IP zone. Agreed you can't do that. But how does that make IP packets leak between different exclusive-IP zones? It doesn't make the packets leak. It makes the administrative activities leak. Perhaps we have a different definition of what IP isolation means? To me the critical property is that there is no IP packet leakage. I don't think it's the only property. Some things do still require global zone administration. Second, ps shows processes that the user in the global zone cannot 'administer' by way of kill(2), so they are at least as isolated as IP instances, but they're still of interest to global zone administrators who want a global view of the system. I tried the kill and AFAICT root in the global zone can kill a process in a non-global zone: OK. I must be misremembering this. I thought the restriction was more complex than that. All that said, I think making ifconfig list the interfaces present in exclusive-IP zones, given the design of ifconfig, would be prohibitively difficult. It'd have no access to the DLPI nodes, which is where it gets some of its information, and the ioctls it uses for tunnels and the like won't work well if the zones have independent control of the interfaces. (It'd work for now, but I think it'd end up representing more confusion with Clearview, as there'd be no easy way to coordinate interface names across multiple zones, so ifta_lifr_name would be ambiguous.) I agree it would be a pain to implement. zone_enter() would be one way. But the key thing to me is the consistency between where things can be observed and where they can be modified. We already have RFEs filed against other utilities because they don't show non-global zone activity (see, for example, CR 6369726). I think the lines here are pretty blurry. In some usage models, the global zone administrator owns everything. Even if he can't directly control things from the global zone (and must log into the non-global zone to turn services on and off), he wants to see a view of the system that includes everything. In other usage models, the global zone administrator just provides infrastructure and has no business looking at non-global zones. And we've had requests to lock down the global zone so it can't look where it shouldn't. Given that there are some networking things that must be administered in the global zone alone even when exclusive stack instances are in use, it doesn't seem unreasonable to me to say that the administrator of the global zone should be able to list related information without entering the non-global zone. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
Erik Nordmark writes: James Carlson wrote: Erik Nordmark writes: But the key thing to me is the consistency between where things can be observed and where they can be modified. We already have RFEs filed against other utilities because they don't show non-global zone activity (see, for example, CR 6369726). I think the lines here are pretty blurry. In some usage models, the global zone administrator owns everything. Even if he can't directly control things from the global zone (and must log into the non-global zone to turn services on and off), he wants to see a view of the system that includes everything. Do you have an example of that? I'm not sure I understand the question. Is CR 6369726 a suitable example? If not, then what are you asking? Given that there are some networking things that must be administered in the global zone alone even when exclusive stack instances are in use, it doesn't seem unreasonable to me to say that the administrator of the global zone should be able to list related information without entering the non-global zone. ifconfig displays network interface names used by IP and IP addresses and related information. zoneadm list -l displays the datalink names assigned to an exclusive-IP zone. Are you saying that the datalink names are insufficient for the administration the global zone would need to do for the exlusive-IP zone? Yes, if the administrator of the global zone needs to know what networks are involved in order to make a change. For example, if the administrator of the global zone has Firewall-1 installed, he's going to need to configure IP details in the global zone. I don't see how he can do that if he doesn't have access to them. There are things external to the system (such a firewalls) that might need to be configured with IP addresses, and I can see the same thing being true for the global zone (e.g. the global zone might run a firewall in front of the non-global zone down the road). Right. But I don't see that particular type of configuration as an argument for being able to do ifconfig -a in the global zone and see the non-global information, any more than there being a requirement for a router outside the system being able to do ifconfig -a and see the IP configuration of other systems on the network. It depends on the administrator's mental model for the system. Seeing IP addresses for other systems on the same network would not be a rational thing to expect out of ifconfig. Seeing IP addresses configured inside the very same box on the very same running kernel, though, may well be a rational expectation. Thus I am trying to understand what the architectural or design principle is that makes you conclude that showing IP address configuration for exclusive-IP zones in ifconfig in the global zone. The design principle is that we have different tools for different tasks, and those tools are expected to give you a coherent view of the system. I do expect to use the resource control commands to control resources that I'm going to delegate to zones. I do expect to be able to view mount points and devices in use on the local system using tools designed for those purposes, regardless of what zone is involved. I don't expect to use one tool to list datalinks and IP interfaces when they're in my local zone (dladm, ifconfig) and a completely different tool when they're in the same system but in some other zone. That's not the model we had been using, which is why ifconfig currently does show interfaces in non-global zones, even though you can't use those interfaces in the global zone. The exception is where zonecfg sets up boundary conditions for a given zone, and thus must take on tasks from other subsystems, but even in those cases, I expect the 'native' (non-zones) tools to work as well with those resources as with ones in the global zone. In fact, I don't see what it has to do with zoneadm. The question is whether there's a single global view of the resources on the system. If the answer is no, then I suspect we'll end up needing to find a way to provide that view, because that hasn't been a broadly accepted answer in the past. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
[EMAIL PROTECTED] writes: I tried the kill and AFAICT root in the global zone can kill a process in a non-global zone: OK. I must be misremembering this. I thought the restriction was more complex than that. Within the global zone, the ability to kill a process in a non-global zone is controlled by the proc_zone privilege. Normally, only a user with all privileges will have this ability unless modified via RBAC. Thanks. ;-} I _knew_ it wasn't as simple as killing a process in the global zone. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Zones and Solaris upgrade
Peter Baer Galvin writes: Hi, any update on the status of the Zulu project!? thanks. It integrated into build 53. Work is continuing now on cleaning up some related bugs and backporting for S10. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
RE: [zones-discuss] Re: Zones and Solaris upgrade
Peter Baer Galvin writes: Ah, I should be playing with it in a week or so then. Is there a summary of its functionality posted anywhere? Thanks much... There's a heads-up message that went out about it, but there's not much to it. There's one new package -- SUNWlucfg -- that must be removed and replaced with each upgrade. This was done because SUNWlur was hollow, and we need some of the files inside the non-global zones. The lucreate '-m' option gains the ability to specify unshared file systems embedded within zones -- e.g., -m /opt:/dev/dsk/c0t0d0s5:ufs:myzone -- and lufslist gets the ability to print them out. Other than that, it should be just as it was before, except that you can now live-upgrade a system with non-global zones. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone delete/rename problems
Dave Bevans writes: I have a customer who has a couple of zones issues. His first problem is that he's trying to delete a zone and he gets an error (/see zonecfg errors below/). [...] -bash-3.00# zonecfg -z NS2.i2c.com delete -F Zone NS2.i2c.com not in configured state; delete not allowed. The error explains the problem -- the zone isn't in configured state. You can't delete it if there's still an installed zone there; you must remove the installed zone first. His second problem is when he tries to rename a zone he gets a usage error. I'm having him try using another shell (/bin/sh), but I didn't know if there was anything I was missing. [...] zonecfg:monitoring-inc set zonename=monitoring usage: set property-name=property-value You need to have bits that have the zone renaming feature in order to make this work. The release you're using doesn't have that feature. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone installation problem.
Chris Greenman writes: add inherit-pkg-dir set dir=/usr/sfw end Why would /usr/sfw be a separate mount point? ERROR: Read-only file system: cannot create mount point /zones/mysql1/root/opt/csw/var At a guess, this occurs because /zones/mysql1 itself is mounted read-only. Can you check how that file system is mounted? -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] How to get new ZFS Solaris 10 U3 features going from Solaris 10 U2
Chris Greenman writes: From my understanding, the only way is to perform a system upgrade (regular or live upgrade). Also you WILL NOT be able to upgrade any zones. You best bet for that is to save all your application data and zone configs and rebuild the zones after upgrading the global zone. That's not correct. If you're using netinstall or DVD media (rather than CDs), then you should have the standard upgrade option available even if you have non-global zones installed, and the option does in fact upgrade the zones as well. It does not work with Live Upgrade or from CDs, though; if you use LU or CDs, you can upgrade that way only if you have no non-global zones installed. The zones upgrade feature was shipped as part of the very first Solaris 10 Update release. The Zulu project that just integrated into Nevada (and is headed for a future S10 Update) will extend this support to Live Upgrade, so that all the upgrade mechanisms are supported. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: zone to zone networking slow!!
Jeff Victor writes: 1. Global zone to global zone using 127.0.0.1: 125 Mbytes/s 2. Global zone to global zone using 192.x.y.z: 124 Mbytes/s 3. Global zone to non-global zone: 124 Mbytes/s 4. Non-global zone to itself: 118 Mbytes/s 5. Non-global zone to another non-global zone: 122 Mbytes/s Did you just rely on ftp's reports? If so, and if you didn't have name services set up to be snappy on reverse (address-to-name) translation, you might have lost some time there. (Just a wild guess; I don't know what else could account for that.) There really ought to be no difference among those numbers, as it's the same stack being driven in the same code paths. Zones are not an emulation layer. It's puzzling that you're seeing a difference at all. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: zone to zone networking slow!!
Jeff Victor writes: Yes, I did. As I said in that msg, don't read too much into those numbers. You went and read too much into them, didn't you? :-) Yeah, ok, I'm like that. ;-} -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Patching the system
Shawn LEE C. H. writes: Thanks for the reply... Would you be able to explain how the patching is done on halted zone specifically how the /var which is not mounted in the halted zone is being updated. Thanks! Zones that are being updated are put into the internal (undocumented) mounted state, in which all file systems are mounted, but no processes are running in the zone. I can probably make the design document that describes scratch zones public if you need it. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] How to update zone configuration
Bernard Biessy writes: I have a V890 server connected to 2 Sun StorEdge 3510 storages. My users ask me to increase the /sauvebase file-system and I have no space left on 1 of my 2 3510, so I mirror d1002 soft partition on a new biggest d1502 soft partiton on the other storage. After that, I umount/remount the FS and it work fine except that I discover that zone configuration has not be updated. So the question is : What is the good method to update the name of the /sauvebase soft partition name in the zone configuration. Assuming I understood the scenario, it's something like this: # zonecfg -z zy91 zonecfg:zy91 select fs dir=/sauvebase zonecfg:zy91:fs set special=/dev/md/dsk/d1502 zonecfg:zy91:fs set raw=/dev/md/rdsk/d1502 zonecfg:zy91:fs end zonecfg:zy91 verify zonecfg:zy91 commit zonecfg:zy91 exit -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Re: Ashanti and Zulu Details Needed
Ben Rockwood writes: When I say migration I'm refering to moving zones either: A) From one system to another B) Exporting a zone prior to upgrade, and then importing it after the upgrade. I don't see how (B) can be supported with the current software. In either case we've got two problems: 1) Damage or invalidation of the package database (frankly I don't care much) If you ever upgrade, install any new packages, or use patches, then I'd think it likely that having an intact packaging database would be important. 2) Non-current /etc files. (I do care about this) Yes, and many of these are updated as a part of upgrade process via class action and packaging scripts. If the zone is detached during the upgrade, then there's no way those files will be updated, and reattaching (if forced) will leave you in an inconsistent state. In the latter case, effectively what I need is a generic version of ACR. Even though migrations may not be kosher, I'm doing them today quite a bit. What I think would be needed is (possibly) some way for the 'attach' process to run the necessary upgrade against the zone before allowing it to be imported, so that the packaging and patching databases are updated along with running the appropriate migration scripts. It might be possible to hack up a version of ACR to do some of that instead, but that solution sounds far enough off the path that we really want to go with Zones that I don't think it's something worth doing. But, if you do, then propose an ACR for detached zones project and have at it. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones and Resource Pools
Jeff Victor writes: Information about zone-pool assignment 'feels' like it belongs in zoneadm list output (analogous to zonepath), It certainly doesn't feel that way to me. I expect zoneadm list to produce the information that's *crucial* for the operation of the zone. It's the stuff that defines the identity and location of the zone. Just as I don't expect zoneadm to list what processes are running in a given zone, or what IP addresses are configured, I don't expect it to list out pool assignments or other ancillary run-time information. I expect to use pool-resource-related tools (perhaps with Zones extensions) to do that, or zonecfg if I'm interested in the start-time configuration of the zone. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] putting local zone filesystem in global zone vfstab
Tillman, Gregory writes: What bad things would happen if I add an entry to my global zone's vfstab to mount a filesystem into a local zone's root (for ex, /zones/myzone/root/logs)? Would the zone still boot up and shut down cleanly? thanks It won't boot at all if there's something mounted inside the zone. Use 'zonecfg' instead. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Zones on NFS
Ben Rockwood writes: Still looking for a quasi-official answer on this. Again, the questions that need specific answers to are: A) Why, specifically, can't Non-global roots be placed on NFS? Cross-zone NFS is currently not allowed; see PSARC 2004/357. You'd end up with a process in one zone making system calls that are resolved via an NFS client established in another zone. In more detail, you'd want the file system interface to work as though it's inside the non-global zone, but for the NFS network I/O to take place as though the client were actually in the global zone. Doing this requires a minor redesign of the NFS client side. What we need here is to have a split between the upper part that implements the file system itself, and the lower part that does network I/O, and some way of joining the two such that the system knows which zoneid and which credentials (cred_t) to use in which cases. Then we'd also need some way to map credentials between the zones. There's no guarantee that the UIDs and GIDs are the same between them. This likely causes some interesting problems with Kerberized NFS, at least. B) Is anyone tasked with solving this? Is there an ARC case that I'm unaware of? LOFI might provide a workaround but I need a rock solid solution thats integrated and I'm not going to bother implementation testing LOFI until I know that there is absolutely no alternative on the horizon. I think you should also take this up with the NFS community. I believe that they have talked about the problem, though I don't (immediately) see a related project on opensolaris.org. It definitely needs their input. See also CR 4963321. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
RE: [zones-discuss] Re: Zones on NFS
Ellis, Mike writes: I believe all Ben is looking for is the ability to put a local zone's root-fs on NFS. That boils down to the same problem. Processes inside that no-lgobal zone will issue system calls (such as open(2)) that reference these files. Somewhere in the middle of the stack, we need to realize that the mount itself (distinct from the process invoking the system call) is in a different zone, and switch to that zone for the underlying network operations. And we'll need to handle all the credential issues I mentioned before. That middle-of-the-stack magic doesn't currently exist, so what he's asking won't work. Especially with U3's zone-import/export feature, this becomes very powerful (without having to goof around with lofs and friends) If there isn't an official (Solaris 10) RFE on this already (I thought there was) please let me know and I'll have one opened. (others can then attach to it in order to hopefully influence its priority) I cited the RFE in my previous message -- it's CR 4963321. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Zones on NFS
Jeremy Teo writes: I cited the RFE in my previous message -- it's CR 4963321. James, would you mind sharing the rest of the info in CR 4963321? b.o.o. says see comments :) Wretched, I know. I'll see what I can do with it. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] LU non-global zone timeline
Paul Kraus writes: Does anyone know what the timeline for LivuUpgrade support of Non-Global Zones is ? It's already in Solaris Nevada (Express). It's headed for the next Update release now -- though, of course, that's in the future, and predicting the future is unwise in the best of circumstances. ;-} -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] hostnames and zones
[EMAIL PROTECTED] writes: All, I have a customer asking this question: This might seem like a very basic question but now that I have the global zone with two local zones created how do I associate hostnames to the zone virtual IP addresses? I would think that the answer would be to populate dns for hosts trying to contact this host. but what about the local system? Should you add the virtual IP hostnames to the global zone /etc/hosts file or the /etc/hosts file in the zone itself? Name resolution is a purely user-space matter. It's controlled by /etc/nsswitch.conf (yes, inside the zone as well), and if you use 'files' as one of your name resolution methods, and if you care to manage your name-to-address mapping directly in local files, then, sure, adding entries there is a fine thing to do. There are other possible choices. The global zone's /etc/nsswitch.conf and associated configuration files are inaccessible from within a non-global zone, and thus have no effect there. I think things may be different in TX zones, though. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] NFS server in zones
[EMAIL PROTECTED] writes: 2) Lack of requirements - we don't know what people want. In addition to the requirements already stated by others, another crucial one is a resolution of the infamous NFS/VM deadlock. There have been numerous bugs filed over the years concerning it but I believe the current one is 5065254 NFS/UFS deadlock when system is both NFS server and client If non-global zones are going to be NFS servers, then fixing this is a requirement. I think we already have this as a potentially serious problem for non-global zones that are NFS clients of the global zone, don't we? Making it work right would involve either resolving the underlying deadlock or somehow identifying those self-mounts and doing a lofs mount from the global zone instead. I think the latter is what's done for TX, but it's in a very narrow usage case. The general case hasn't been solved. I don't think it's a special problem that's particular to allowing non-global zones to be NFS servers. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone in mounted state
Sivakumar Shanmugasundaram writes: This worked. 'unmount' is undocumented, is it? Not documented, because it's not supported for customer use. It's not a secret, though. You can find out what it does in PSARC 2005/474. Enda, yes. I was doing a pkgadd when I interrupted it. (to run pkgadd -G again). The tools are supposed to unmount the zone even when stopped by interruption. If that's not happening, then either there's a bug (and we'd like to know about it -- file one) or you used extreme force to interrupt the process (such as SIGKILL). If it's the latter, I wouldn't trust the system too much after having interrupted a packaging change. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Zone start order
Rainer J. H. Brandt writes: And there you can see the answer: The clean thing to do is not to add another abstraction (e.g. /etc/zones/boot_order), but to use FMRIs referring to other zones or even remote hosts or zones on remote hosts. And our SMF engineering friends obviously already thought about that, as you can see when looking at this FMRI: I also don't think that having another abstraction is right, however I don't think the FMRI approach is right either. If these zones were independent nodes on a network, we would never be having this conversation. Instead, you'd be told to do the normal networking thing: be robust. If your peer isn't ready when you are, then try again later. If your peer disappears on you, then log the problem, and try to reconnect. Once you get this boot ordering issue down, you'll ask about what to do when services inside one zone fail or are restarted and those outside the zone can't 'see' the change. So, why isn't this just an exercise in proper application design, and why are zones necessarily special here? At best, I think we're talking about a minor boot-time optimization rather than a fundamental way zones should interact. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: SOA (was: Zone start order)
Rainer J. H. Brandt writes: outside the zone can't 'see' the change. So, why isn't this just an exercise in proper application design, and why are zones necessarily special here? They aren't. I think I should have changed the subject line. (I've done that now.) And probably switched to another mail list. (SMF? I hesitated because I hate cross-posting.) Yes, this does look like a topic that's more appropriate for the SMF list. Though it's of interest to Zones users, it seems applicable to arbitrary networking environments. I wasn't just talking about boot order. That probably wasn't clear. That's just one of the many problems that could be solved by what I suggested. And that was SMF across machines, which is what a cluster or a Service Oriented Architecture is about, and which is what we almost have with SMF. A real thing instead of all this marketing buzz around SOA. I mean this: dependency name='my-great-database' type='service' grouping='require_all' restart_on='none' service_fmri value='svc://dbhost/application/postgresql' / /dependency Wouldn't that be nice? I'm not so sure. Do you see that attribute restart_on? No, I won't ask the question that you mentioned up where I added the [***] comment. I already know how to to that with SMF. In general, I would not want my networking applications restarted merely because a peer went haywire. For a really simple example, consider a web server. The server likely depends on name services for normal operation. Should it go down if name services are temporarily unavailable? Should it restart? Is networking unavailability or partitioning equivalent to service failure? Yes, it's possible to construct cases (such as a web server that's wholly non-functional if a co-located database is missing) where such behavior makes some sense. I'm dubious, though, that this is the right way to design networking applications. It doesn't correspond to the multiple decades of design practice in this area, so, before I'd endorse it, I think I'd have to see some really compelling results, as well as, in the IETF tradition, examples of problems that _can't_ be solved in the usual way. Things get stranger still if you have a heterogeneous environment, which I think is a fairly common situation. SMF exists only on Solaris. So, how do you complete dependencies across platforms? So, should we move this to the SMF list? Or forget it? (As I said, there are most likely people who have thought about this.) The SMF list seems much more appropriate to me. The mechanisms involved would have to be in the SMF infrastructure itself -- making the restarter and dependency tree aware of distributed applications -- and the usage of the new feature would be independent of (though perhaps useful for) Zones. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: SOA (was: Zone start order)
Detlef Ulherr - Sun Availability Engineering Germany - Frankfurt writes: There are many famous apaplication servers in the field which have to be restarted whne the underlying database is restarted. The Oracle Application server is one of them. I agree with you this is a crappy design, but we are not in the ideal world. So, should we design the system around crappy designs or good ones? In the clustering space, we are very well aware of this issue. BTW this problem can be soloved very easy in single node cluster on standalone system. with the features of Solaris Cluster this is a nobrainer. We can even have dependencies between smf services across zones. I agree there's likely a real need for this. I'm just wary that it'll leak into places where it's _not_ the right answer. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [Fwd: [install-discuss] virtual interfaces in non-global zone ?]
Jeff Victor writes: The simple way to configure a zone with multiple IP addresses (on one or more NICs) is with zonecfg: # zonecfg -z myzone add net set address=10.1.1.2 set physical=qfe0 end add net set address=10.2.1.2 set physical=qfe1 end That's not quite what the original requestor wanted. He wanted multiple addresses on the same interface. Fortunately, I think that works just by using the same 'physical' for multiple 'add net' sections. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [install-discuss] DHCP Server in zone, WAS: Install software from SXCE DVD?
Dan Price writes: - 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. This limitation is expected to be lifted when the Virtual NIC part of Crossbow is integrated. A physical DLPI Style 1 NIC -- Style 2 (such as hme and ce) won't work with it yet. (Clearview should fix this.) Also, you can't have your own private kernel modules inside the non-global zones (so, if you were expecting to run a separate instance of Firewall-1 there, that won't work), and the NFS server hasn't been virtualized (meaning that you can't yet have an NFS server in a non-global zone). -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Re: Re: zone hung in shutting_down status
Dave Pigliavento writes: Yes, but in both cases preap hangs indefinitely.. That likely implies that the process is stuck unkillably in the kernel, which in turn means that you've got a driver problem of some sort. Mdb (and ::threadlist -v) is probably the next step in troubleshooting this. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
[EMAIL PROTECTED] writes: I've done some work on pidentd prior to the new IP instances code using the ability to intercept calls for all zones in the global zone with the SO_ALLZONES socket option (which may not work anymore after the IP instances putback) Nifty! Not sure about the socket option (should still work ... ?), but IP Instances did nuke the symbols that pidentd was reading out of the kernel, so that utility is now broken. In that scenario, there's one pidentd which runs in the global zone and it gets all identd calls for all zones which do not have exclusive IP instances; it is then able to resolve all identd queries but using nameservices relative to the global zone. I'd sort of like to know how it does that reliably ... does it fork and enter the zone? In any event, I think that getting something other than /dev/kmem for these sorts of applications (pidentd isn't the only one; there's also lsof and probably ntop as well) would be a _very_ nice thing to have. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
[EMAIL PROTECTED] writes: I'd sort of like to know how it does that reliably ... does it fork and enter the zone? It does not resolve names local to the local zones; but it can easily find all the appropriate uids and processes. No different from traditional Solaris with multiple interfaces. Oh. I though that pidentd was supposed to resolve UIDs locally. That's one of the features of the protocol; it provides here's who *I* think the user is information back to the requester. In any event, I think that getting something other than /dev/kmem for these sorts of applications (pidentd isn't the only one; there's also lsof and probably ntop as well) would be a _very_ nice thing to have. Yep. But defining an interface is hairy, specially considering locking and performance. *sigh* -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones network documentation
Mike Gerdts writes: With Nevada I have seen reproducible panics by sending an UDP packet to a destination that does not exist on the local machine and there was no route to send it elsewhere. See http://bugs.opensolaris.org/view_bug.do?bug_id=6422863. The bug report shows a rather complicated mechanism for causing it. A simple nslookup something badIP works as well. If it's that easy to encounter, then this needs to be looked at much more urgently. I've bumped up the priority of this bug to P2. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [install-discuss] updating a zone when attaching
Jerry Jelinek writes: to upgrade to. Pkg operations on pkgs with the SUNW_ALLZONES attribute set must be run from the global zone, the operation will be performed on all native zones, and this behavior is built-in to the pkg commands. This document describes in detail how the packaging bits will be taken care of. But how are patches re-run to update the zone on attach? We don't have copies of the patch metadata (the scripts) around in usable form, do we? Do we just 'assume' that those patches never do anything useful to any non-global zone? commands. Those commands were formerly part of the ON consolidation but moved to the Install consolidation as part of [5]. That case documents man pages for pkgremove and pkginstall but no such man pages exist. No stability level is documented for these two commands so we're assuming these are consolidation private and a contract is needed to directly use these commands. The command line options being used are: Indeed; they're private implementation details of the Install consolidation. One alternative would be to modify pkgadd/pkgrm (or deliver new bits from Install) to expose the features you need. I assume that the reason you're not doing this is that delivery of Install updates on which this new feature depends would be more difficult. Is that right? -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [install-discuss] updating a zone when attaching
Jerry Jelinek writes: This document describes in detail how the packaging bits will be taken care of. But how are patches re-run to update the zone on attach? We don't have copies of the patch metadata (the scripts) around in usable form, do we? Do we just 'assume' that those patches never do anything useful to any non-global zone? The patch bits are handled in the same way that they are currently handled for a freshly installed zone. That is, those changes are already merged into the bits as well as the spooled pkg data that we have in the global zone. Yep; I know. I was asking more about the patch-related scripting. When we install a new zone the bits from the global zone are copied into the zone and the spooled pkg is used to update the editable and volatile files as well as the metadata for the pkg that is stored in the zone. This is actually a different case. With the usual patch install scenario, one may need to worry about the zones on the system today and the zones that are yet to be installed in the future. This project introduces a new case: new un-upgraded zones may now show up in the future, long after the patch scripts have run. I think the assumption needs to be that we'll just never have a patch script that needs to muck about in existing zones. Right? One alternative would be to modify pkgadd/pkgrm (or deliver new bits from Install) to expose the features you need. I assume that the reason you're not doing this is that delivery of Install updates on which this new feature depends would be more difficult. Is that right? Yes, thats right. Plus, I am hoping this is a relatively short-term solution and that as the longer term caiman project evolves this kind of feature will move back into the core install capability. I didn't see it on that roadmap, but ok ... -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [install-discuss] updating a zone when attaching
Jerry Jelinek writes: OK, sorry for misunderstanding your point. Actually, I think the assumption is different. I think the assumption is that patching leaves the bits and spooled pkgs on the system in a state that is suitable for installing the pkg into a zone. And, what is a new use case now, is that this has to apply not only to fresh zones, but to zones that have been previously installed. Yes; that's exactly what I'm asking about. However, I am not sure this is really anything new. When we are upgrading a system from one Solaris update to the next, I believe the pkgs we are installing are in this state. That is, a Solaris upgrade from one update to the next does not install the patches as a separate step, it expects the pkgs to be pre-patched. Yes. Is that your understanding as well? So maybe there could be an issue if we had a patch that was not suitable for use in a Solaris update but that was issued asynchronously? ... or that was just handled differently in the update. I know we've done some special things in patches outside of the updates, especially with zones and outside of ON. I'd suggest asking Enda O'Connor about these, so that (if it is a problem) you can at least detect it and fail out. I will add some material explaining this assumption to the proposal. OK. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zoneadm install
F.V.(Phil)Porcella writes: ERROR: Read-only file system: cannot create zone product registry text database file /zones/CIS2/root/var/sadm/install/contents [...] add inherit-pkg-dir set dir=/var end I don't think that /var can be an inherit-pkg-dir, as this is where the private per-zone packaging database will live, among other important zone-private things. Did you add this to the zone configuration on your own (if so, why?), or did some script do it for you (if so, what script?)? -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [install-discuss] Re: [zones-discuss] updating a zone when attaching
Mike Gerdts writes: On 6/4/07, roush [EMAIL PROTECTED] wrote: Hi Jerry, This proposal mentions native zones. Please ensure that the cluster brand is treated as a native brand, as noted in PSARC 2007/304. Any details on what this is? The case doesn't seem to be available on opensolaris.org and the mercurial change log is not terribly revealing. It's an open case, so everything ought to be there. I'll drop a line to the ARC discuss list. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ipfilter in local zones
Jason Bradfield writes: I think we have decided to leave this for nowIt will be our clients that will be using the non-global zones.. Is their a way to manage this from within the global zone.. without exclusive IP stacks.. ie in the global zone can I specify ipf rules for the non-global zones.. Sure. Ipf rules specified for the global zone apply to all 'regular' (non-exclusive) non-global zones as well. The rules themselves don't have a way to filter based on Zone ID or name, but you can still filter based on address. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ipfilter in local zones
Jason Bradfield writes: set intercept_loopback true; I tried this... This doesn't allow non global zones to maintain their own ipf.conf and run ipfilter. I think that'd be fairly complex and a pretty serious security problem if we allowed it. For shared-stack zones, there's only one TCP/IP stack. If we allowed ipfilter to be configured inside the zone, then the user of the non-global zone could do all sorts of nefarious things -- such as redirecting packets out other interfaces, dropping packets intended for other zones, and creating rewriting or NAT rules to impersonate someone else. What you have inside the zone is really an address, not a physical interface. It's not a separate machine -- it's a machine with shared resources that relies on an independently managed infrastructure. If you want a separate machine, with its own kernel and own resources, I think the right answer is to go with some VM-like solution, such as Xen, LDOMS, Domains, or VMware. All this allows is filtering between zones the global zones ipf rules.. Yes; that's what the loopback intercept is for. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Can I migrate zones without reboot?.
larry lancaster writes: when i use zones, can I migrate then without havign to reboot my machine? Is ohter words is the zone migration static or live? The zone itself must be shut down in order to migrate, but the machine itself doesn't need to be rebooted. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zonecfg and dhcp for shared interface?
Martin Man writes: VNIC? I think we were discussing the use of DHCP with regular shared-stack zones and ordinary logical interfaces. I'm lost in Sun's always-have-at-least-three-names-for-the-same-thing madness, fortunately it didn't confuse you :-)) ;-} I understand physical interface bge0 and I know logical interface bge0:1. forget the rest please..., somehow I was thinking about VNIC being the Virtual NIC, e.g., logical interface... OK; then it sounds like we're talking about the same thing. (VNICs are a Crossbow concept. They're layer 2 devices, rather than being layer 3 entities like the much older IP logical interfaces. If you like, you can think of IP logical interfaces as being address aliases found on other operating systems. They're just represented as distinct IP objects with their own flags on Solaris.) I think the proposal would be to make the DHCP-learned information available within the non-global zone, not to go modify the zone's files from the global zone. One way to do this would be to make the /etc/dhcp/$IF.dhc file visible in the zone, and write the raw DHCPACK there. There are probably better ways of doing this, such as making dhcpagent's internal control socket (used by dhcpinfo) available in the zone. as long as it will work with BrandZ I basically don't care... Got it; that's an important consideration. Getting the DHCP data into a form where Linux can use it inside the zone might be a challenge, but it's worth some thought. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones and 3D applications
Amir Javanshir writes: First of all, we agree that Solaris zones (by extension the containers) are really useful on the server side, for consolidation means. However does it really make sense to use zones on a graphical workstation ? What benefit would there be there ? (The only one I can see is to have two different versions of a software on the same workstation) It also provides the opportunity to run servers in those other zones -- isolated from the local workstation usage -- and perhaps allow for certain kinds of software testing. * In case of the sparse root zone many libraries are shared between all the zones. What about the X11 libraries, colormap, pixmap ans so on ? Yes. Everything under /lib, /platform, /usr, and /sbin. * And in Whole Root Zones, do we get a different X server for each zone ? You may. The hard part, though, will be with the devices and permissions required inside the non-global zone. * Finally, lets say each zone has it's own X server, how can dirrerent zones deal with the 3D graphic card on the workstation (the XVR 2500 card for example) ? I think you'll need to ask the folks who support those cards what provisions they've made for non-global zone operation. My guess would be that it's impossible to run any of those cards in a non-global zone, because it requires permissions that exceed what non-global zones may have. Just a guess, though, and it depends on the individual products, not on the Zones feature itself. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Running zonename command in an alternate root
Ritu Agrawal writes:
Opening to [EMAIL PROTECTED]
Thanks. Also removing accidental cc of confidential list.
Use /sbin/zonename and you should be fine
This is a Live upgrade case when we are on the alternate root.
Yep; understood.
The
alternate root has the O/S installed and we try to upgrade some of our
packages. Please note that this is all happening in the alternate root.
I understand that. I don't understand why you'd be attempting to
execute any binaries you find on the alternate root. They can't work.
We attempt to do a pkgadd -d dir -R altroot pkgname. The
package/postinstall inturn does a zonename first. Since we are in the
alternate root, the command thats run is altroot/usr/bin/zonename
which is when it fails.
Right. So why are you doing that?
Here's a code snippet :
ZONECMD=${PKG_INSTALL_ROOT}/usr/bin/zonename
That's the broken part. That should be just:
ZONECMD=/usr/bin/zonename
Otherwise, I don't understand the intent. The executable things that
come with the system are located under /usr/bin, /sbin, and
/usr/sbin. Those should always work and always be consistent with the
system libraries and kernel.
Binaries that you find elsewhere may not necessarily work.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Running zonename command in an alternate root
Dan Price writes:
On Thu 26 Jul 2007 at 05:04PM, James Carlson wrote:
Here's a code snippet :
ZONECMD=${PKG_INSTALL_ROOT}/usr/bin/zonename
That's the broken part. That should be just:
ZONECMD=/usr/bin/zonename
I'm lacking context here, slightly, but...
Isn't it also broken to be calling /usr/bin/zonename? /sbin/zonename
is shipped in SUNWcsr, and /usr/bin/zonename is only in SUNWzoneu.
This is a bug, and one we should fix, but it's the behavior we've got.
Yes, that's also broken; thanks for catching it. You're right that
/sbin/zonename is the right answer (and pkgcond might be a better
one).
I was focusing too much on the invocation of binaries located outside
of the system root -- I figured there had to be a reason to be
attempting something that complicated, and I was trying to get to the
bottom of that first.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Zones and Routing
Robert Smicinski writes: The route for network A - network C is different than the route for network B - network C. [...] What's up with that? Is there only one routing table? Yes. Can I force a zone to use a specific route and interface? Only if you use an exclusive stack instance. See the ip-type property in zonecfg(1M). (Are you running an OpenSolaris-based distribution? If so, then if you have a recent enough build, you should already have this feature.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Creating a Virtualization Community Group
Ellard Roush writes: There is so much discussion in these areas that it would be most undesirable to combine these 3 different areas. An excess of discussion sounds like stuff that belongs on a narrower project or subgroup mailing list, not a reason to avoid a community group focusing on virtualization. It's the difference between choosing 'opensolaris-discuss' versus 'myproject-dev' when figuring out where to send a message. Recommend that they be kept distinct. However, I do agree that there are topics that would appeal to all 3 areas. In such cases recommend that people send their comments to the 3 discussion aliases in a single email. Note that communities get to steer their technologies independently. Is it good for Solaris if these three groups end up with conflicting choices for common components, such as software install and management? If that's not good, then I'd suggest that a single virtualization group would be a good way to start. In fact, other than a possibly excessive list of community group leaders and core contributors, I find it a little hard to understand why separate CGs would be helpful here. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Non-global zone and nfs mounts from global zone
Lu, Baolu writes: Q: Can a non-global zone NFS-mount a file system that has been shared from its own global zone? A: No. This may be addressed in the future. However, the filesystem can be LOFS-mounted into the local zone, and, The LOSF-mounted filesystem is read only in the local zone, this means it is only a one direct sharing. How, if the local zone want to share some files to the other zones? Non-global zones can't do this on their own via local methods. However, the global zone administrator can set up arbitrary sharing between selected sets of non-global zones. Just create a directory and export it into the desired non-global zones via lofs. The alternative is to choose some other means for sharing files -- such as (for example) a web, ftp, ssh, or rsync server running in the non-global zone. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones on zfs
Dick Davies writes: On 16/08/07, Boyd Adamson [EMAIL PROTECTED] wrote: Neal Miskin [EMAIL PROTECTED] writes: From http://www.opensolaris.org/os/community/zones/faq/#cfg_zfsboot Does anyone know if this is still the case or if it is fixed or will be fixed in a patch? It was fixed in Nevada a while ago. I don't think that's right. Zones are now live-upgradable, but not if they're on ZFS. I'd *love* to be wrong, incidentally. You're right. No upgrade mechanism yet supports zones (global or non-global) on a ZFS root. That's coming, but not yet. The fixed in Nevada a while ago was the ability to do real upgrades (both 'standard' and live) of Solaris systems with non-global zones present. A real upgrade consists essentially of computing the differing sets of packages between the releases, and then doing pkgrm/pkgadd in order to adjust the system upwards. Extending that mechanism to Zones is what the project code-named Zulu delivered. Previously (in S10u1 through S10u3) the upgrade mechanism consisted of some tricky patch-based work, from a project code-named Ashanti. The problem with that mechanism is that it required the distribution medium (DVD-only) to carry the same bits twice -- once as packages (for regular upgrades of global-zone-only systems) and then again as a set of patches (for Ashanti upgrades of systems with non-global zones). It wasn't sustainable. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones on zfs
Mike Gerdts writes: On 8/16/07, James Carlson [EMAIL PROTECTED] wrote: Previously (in S10u1 through S10u3) the upgrade mechanism consisted of some tricky patch-based work, from a project code-named Ashanti. The problem with that mechanism is that it required the distribution medium (DVD-only) to carry the same bits twice -- once as packages (for regular upgrades of global-zone-only systems) and then again as a set of patches (for Ashanti upgrades of systems with non-global zones). It wasn't sustainable. Is this the purpose of the UpgradePatches directory on S10 media? Yes. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] webshere in Solaris 10 containers
Redmar van Leeuwaarden writes: A quick and dirty fix; linking /opt/WebSphere/AppServer/deploytool/itp/configuration/ (global) - /opt/WebSphere/itp (local); proved that this is indeed is the problem when deploying EJBs. One obvious thing to do would be to contact the WebSphere folks and ask them why they're writing back in the installation directory, rather than creating something like /var/WebSphere/AppServer to hold variable data. Does any one have a more acceptable solution for this problem, or does any one now a way to configure the temporary workspace for the itp tool (not the osgi.instance.area.default variable, I really mean the temp files placed in the itp/configuration directory). I must imagine that more users have faced this issue. Two things come to mind: - As you suggested, create a symlink in the global zone that points to local storage in each non-global zone. - Add read-write lofs mounts for each non-global zone that mount separate (per-zone) directories onto the .../itp/configuration directory, something like this: zonecfg:blue add fs zonecfg:blue:fs set dir=/opt/WebSphere/AppServer/deploytool/itp/configuration zonecfg:blue:fs set special=/export/blue-itp-configuration zonecfg:blue:fs set type=lofs zonecfg:blue:fs end -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [brandz-discuss] Creating a Virtualization Community Group
Brandorr writes: It seems there is a majority of people in favor of this. What do we need to do to make it happen? I think the main barrier is getting the LDoms team to agree. They seem to feel that they need a separate community from the rest of the virtualization mechanisms on Solaris, and that a common community would serve no useful purpose. I don't quite agree, but in our last OGB meeting, we did approve the LDoms community proposal. Going ahead with a virtualization community that _doesn't_ involve LDoms seems much more feasible to me. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [xen-discuss] [brandz-discuss] Creating a Virtualization Community Group
Liam Merwick writes: The LDoms community would be happy to be part of an umbrella Virtualization community involving the BrandZ, LDoms, Xen and Zones communities (or as projects - depending on what OS.o process is ultimately decided on). This isn't the rationale that was provided to the OGB. The rationale provided looks more like this: http://mail.opensolaris.org/pipermail/ogb-discuss/2007-August/002239.html and this: http://mail.opensolaris.org/pipermail/ogb-discuss/2007-August/002250.html That is, LDoms are special. We were told rather directly that there was no point in having a Virtualization community because there was _NOTHING_ that could be shared between these projects -- no high level management or coordination, no tools support, and no joint projects. If that's not true, then it certainly comes as news to me. the communities. The LDoms community would be more that satisfied to be part of an overall cohesive virtualization community Then I don't understand why the repeated requests by OGB members and others to go this direction -- to create a Virtualization community to cover LDoms, Xen, Zones, and others -- were rejected by the LDoms proponents. The only ones in favor of the broader community were the other groups, such as Xen: http://mail.opensolaris.org/pipermail/ogb-discuss/2007-August/002234.html -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [xen-discuss] [brandz-discuss] Creating a Virtualization Community Group
Nils Nieuwejaar writes: It's certainly not true. I didn't really think it was, but that's the basis for the OGB approval of the new LDoms community. Representatives of all of these teams recently spent several days in a woefully overcrowded room hashing out exactly where these areas of overlap are. If anything, the zones project was the odd man out, since they virtualize at a different level of the stack than Xen and LDoms. Even with Zones, I'd expect software packaging, install, and maintenance issues to be shared (at least in part) with the other groups. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] unable to rsh into zone2
[EMAIL PROTECTED] writes: Does anyone know how to get rsh working on zone2? I can zlogin to both zone1 and zone2 ok. xc12p11-b1# zoneadm list -cv ID NAME STATUS PATH BRANDIP 0 global running/ native shared 6 xc12p11-b1-ce0-zone1 running/export/xc12p11-b1-ce0-zone1 native shared 12 xc12p11-b1-ce0-zone2 running/export/xc12p11-b1-ce0-zone2 native shared xc12p11-b1# rsh -l root xc12p11-b1-ce0-zone2 'date'- Not working xc12p11-b1-ce0-zone2: Connection refused What's the status of svc:/network/shell:default in that zone? Did you perhaps configure zone2 and forget to go through sysid? -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] unable to rsh into zone2
Russ Petruzzelli writes: I also notice in your command you are attempting rsh by root.br It is a big security risk, but you must comment out the CONSOLE line in /etc/default/login to allow root logins via rsh.br True. It's worse than that -- rsh and rlogin are completely insecure. It's 2007. In general, you ought not be using them anymore. Try ssh instead. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] unable to rsh into zone2
[EMAIL PROTECTED] writes: It is enabled but uninitialized. Aha. That almost certainly means that you need to log into the console of that zone and answer the questions that sysidtool is asking. You can look at svcs -x to find out more about the state of the zone services. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] unable to rsh into zone2
[EMAIL PROTECTED] writes: Anyone know how to start the restarter? You don't need to, and doing it wouldn't help. Instead, you need to use zlogin -C zone2 to connect to the zone's console and answer the questions that sysidtool is asking. Those questions (such as the root password and default time zone) are what's blocking it from booting up. Once you've done that, it'll boot up correctly. Alternatively, you can make sure that you use a sysidcfg file when you install the zone. There are references to this in the documentation ... -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zlogin invoked by cron hangs after a few minutes
Damien Carbery writes: If someone inside Sun would like to poke around the machine (it's in Dublin), I can provide the login details. This is a zlogin bug (actually, several bugs). I'm writing up the CR now. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IP instances
Bernd Schemmer writes: can I use IP instances with every kind of network adapter? No. Only GLDv3-based drivers will work. For hme and qfe I get the following error messages while booting the zone: bash-3.00# zoneadm -z s8-zone-ose005 boot zoneadm: zone 's8-zone-ose005': WARNING: unable to hold network interface 'qfe2'.: Invalid argument zoneadm: zone 's8-zone-ose005': WARNING: unable to hold network interface 'hme0'.: Invalid argument That's expected. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] carry forward mount points from global to non-global zones
Sengor . writes: Something like this in zonecfg should do the trick: add fs set dir=/mnt set special=/mnt set type=lofs add options rw No, I wouldn't expect that to work. That'll export just the /mnt directory itself (read-write to the non-global zone!). Any sub-mounts that appear there will not be mirrored into the zone, because lofs doesn't cross mount points. There currently isn't a mechanism that will do exactly what the original poster asked. The individual mounts would need to be replicated in each zone. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] netmask notation with zonemgr
Kamlakar Patil writes: While creating zones using zonemgr, I specified netmask as 255.255.255.240 but zonemgr scripts converts it to CIDR 29 instead of 28. What version are you using? It looks like this works right in version 1.8.1: http://opensolaris.org/os/project/zonemgr/files/zonemgr-1.8.1.txt -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] carry forward mount points from global to non-global zones
[EMAIL PROTECTED] writes: Are you sure? lofs generally missors the entire tree below the mountpoint and not just the toplevel mount. Doh; I tried with nfs mounts. You're right. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] b75 ip-instances bug?
John-Paul Drawneek writes: Network can ping the zones and global zone zones and global zone can't ping each other Unless there's some external router that forwards traffic between the zones, you won't be able to communicate between exclusive stack instance zones. That's sort of the point. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] netmask warning, misconfiguration
Jordan Brown (Sun) writes: OTOH, I don't immediately understand how the example can work. It says that 128.32.*.* (except for the exclusions) gets a 24-bit netmask, but I don't see how that can be unambiguously determined. The example *seems* to want to explicitly specify a 28-bit netmask for several ranges and a 24-bit netmask for the rest, but how can it distinguish between requesting that 128.32.*.* is all 24-bit and requesting that 128.32.0.* is all 24-bit? (For that matter, why isn't it specifying that 128.001?.*.* is 24-bit?) It doesn't always work very well, which is why I generally recommend against /etc/netmasks. It may have been an ok interface 20 years ago, but with CIDR, it's mostly a defect looking for a place to happen. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Shared-ip routing and VNI interface
Paul Van Der Zwan writes: I'm having a problem figuring out why my ping replies never get sent. There's no way for any of your configured zones to transmit, so they don't. Vni is really not much different from lo0. You cannot transmit packets on vni -- it's just a place to hang a local IP address. That's why they say NOXMIT when you configure them. The global zone has 192.168.200.14 configured on bge0 You need to give your zones access to bge0 if you want them to transmit there. You give access by assigning an address on that interface. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Shared-ip routing and VNI interface
Paul van der Zwan writes: service address=10.1.1.1 default gateway=192.168.1.254 zone1 on host1 has 192.168.1.1 on bge0 and 10.1.1.1 on vni0 zone1 on host2 has 192.168.1.2 on bge0 and 10.1.1.1 on vni0 That looks like a variant on the original design target for vni, so I'd expect it to work. The loadbalancer routes 10.1.1.1 traffic for session1 to 192.168.1.1 Would traffic from zone1 be able to go out to the internet using the default gateway 192.168.1.254 with a source of 10.1.1.1 or would the source become 192.168.1.1 ( even if the application binds to 10.1.1.1 ) ? Yes, it should be able to reach that router because the configuration of bge0 in the zone gives it access to that subnet. No, the system never alters a chosen source address. The only time we ever pick a source address is when the application itself has not chosen one -- either it hasn't called bind() at all, or it has called bind() and supplied an all-zeros address. Is there some documentation on the routing in Solaris 10 esp. in combination with zones ? Besides the man pages and docs.sun.com, there's some useful information in the FAQ: http://www.opensolaris.org/os/community/zones/faq/#cfg_io -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Whole root or sparse one ?
elkhaoul elkhaoul writes: What's model is generally used to set up zone ? Whole root or sparse model ? Thanks a lot for your answer. You may need to provide more details to get a more coherent answer, but the _default_ for zonecfg is to create a sparse-root model zone. You have to delete the inherit-pkg-dir entries to create a whole root zone. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] exclusive-ip
Robert Smicinski writes: We have the same problem, none of our interfaces show up on ce's, bge's, qfe's or ge's on sparc. It does work on one of our x86 machines though. Maybe it's related to sparc? It's not SPARC that's the problem. The problem is that the IP Instances feature (exclusive-ip) currently supports only GLDv3 interfaces. Any interface implemented using GLDv3 will work, regardless of platform. ce, qfe, and ge are (or at least _were_) monolithic DLPI designs, not GLD-based. It's also pretty important to know that version matters here, so describe the system you're using. Quite a few changes have gone into OpenSolaris-based distributions that haven't gotten back (and may never get back) to S10. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] exclusive-ip
Robert Smicinski writes: I don't see that reference in the Sun What's New Solaris 10 8/07 Release: http://docs.sun.com/app/docs/doc/817-0547/6mgbdbsoa?l=ena=viewq=ip+instances I don't see a reference to the issue there, either. I think that's probably a documentation bug. The issue is with the design of the driver. If it uses GLDv3, then zoneadmd can issue a special new ioctl to move the link into the zone. If it doesn't use GLDv3, then that doesn't work. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dhcp/zone
Robert Milkowski writes: Hello Zoram, Tuesday, December 11, 2007, 9:41:13 AM, you wrote: ZT IIRC, you need to have ip-type=exclusive to have DHCP work in a ZT non-global zone. Currently ce doesn't support exclusive IP stack, but I ZT remember seeing an RFE somewhere that'd allow exclusive/ce combo. ZT Perhaps this has already been fixed in Open Solaris, I'm not sure. IIRC someone from Sun wrote some time ago it won't rather happen (GLDv3 version of ce) - unfortunately. I think you're confusing two things. One is the conversion of 'ce' to GLDv3. That might or might not happen -- I know of at least one person who is quite interested in it, but I don't know whether the work will get done. Given the number of ... special ... features in that driver, it'd be an interesting job to say the least. The other is the support of the ioctls necessary for assignment of links to a zone, which is needed to support the exclusive IP stack feature, and the tweaks to zoneadmd to make it work. This *HAS* been done and is on a path for release. In S10 currently, the only framework that supports the feature is GLDv3, which is why the exclusive IP stack is tied to GLDv3 support. But non-GLDv3 drivers can also be modified (with some difficulty) to support the feature, and that's what's being done for 'ce.' -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dhcp/zone
Ihsan Zaghmouth writes: James Carlson wrote: There is an interesting support issue for Trunking and/or Aggregation that needs to be addressed to support of ce and ge by GLDV3. Indeed. Solaris Trunking 1.3 does support ce and ge, unlike Solaris 10 Aggregation (dladm). Since dladm is the focus for future network administration among all the other features builtin for supporting IP-instances, where Aggregation is a sub function of, isn't it prudent to be strategic reason to push for the support of ce and ge by GLDV3 ? That'd be one good way to do it. The other way is via Clearview's UV shim layer, which will eventually make legacy DLPI devices appear to be GLDv3 drivers. I'd rather see these old drivers ported over to the new framework, but that's a cost/benefit analysis that others (partly the maintainers of the driver) need to make. (And, unfortunately, many of these old drivers are closed-source, so it's harder to find people to help out.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] different MAC addresses
Caroline Carol writes: Is it possible to configure local zones with a differnt MAC address ? No. With the same MAC as in global, and in the same VLAN, spanning tree encounter problems in the Network I'm not sure I follow. In all cases, with respect to the Spanning Tree protocol, we're simply an end node. We don't (currently) bridge any packets, nor do we emit any BPDUs. Shared-stack (ordinary) zones use only alternate IP addresses. They're exactly equivalent to assigning multiple IP addresses per interface, as before you could zones with ifconfig's addif command. It's purely an IP concept, and link-layer issues aren't involved. Exclusive-stack zones allow zones to take possession of a VLAN, but even in that case, there's nothing that's different from a system without zones. In other words, you can create VLANs on a system with no zones configured at all (only the default global zone), and the network will be unable to tell the difference in the packets we send versus a system with non-global zones configured. As far as Spanning Tree is concerned, end nodes like us don't exist (because we cannot form L2 forwarding loops) and IP has nothing to do with the way in which bridging works, so how do zones cause problems? Or what problems do you specifically see? -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] How to configure Global/Local zone in seperate subnet and use seperate router
Mike Gerdts writes: On Tue, Mar 4, 2008 at 3:31 AM, Enda O'Connor [EMAIL PROTECTED] wrote: Hi For the ce driver you will need 137042-01 SPACR 137043-01 X86 which fix CR 6616075 ( ON Part ) as well as 118777-12 SPARC 118778-12 x86 which fix CR 6606507 the ce driver side. Keep in mind that to use exclusive IP's each zone will need its own physical network. That is if you have a network used only by the global zone and a different network shared by two or more non-global zones, you will need to have a physical network interface per non-global zone. Almost. You need a separate VLAN to assign for each zone. The exclusive IP feature allows you to put a VLAN into a zone, not the whole physical interface. The distinction is a bit confusing because the default VLAN for an interface is effectively ID zero -- no VLAN header at all, as long as no CoS bits are set -- and that can be placed into a non-global zone. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Lost network connectivity and NIC recognition
Anne Moore writes: I am definitely using OpenSolaris as that's what I downloaded and installed, (excuse me if it's not called 10). I was trying to find out which one you actually have. Solaris 10 and OpenSolaris are different entities. it sounds like you need some local support I feel sorry for you James. It appears you must put people down to feel better about yourself. Why not go to a shrink for help?! I wasn't trying to put you down at all. I'm sorry if it sounded that way in email. I was suggesting that if you have Solaris 10 (which it sounded to me like you did -- many Solaris 10 users errantly think they're using OpenSolaris, and I've never heard of an OpenSolaris user refer to his or her system as 10), then you ought to contact a local Sun support person. That's what support is for. Next time, ask a real engineer before you respond. Ah, well, time to turn in that worthless sheepskin, I guess. :-/ As for the unexpected results on sys-unconfig, did it ask you any questions at all on boot-up? If this really is OpenSolaris, which one is it exactly? There are multiple distributions, each with many different builds. Narrowing down the field seems like the first obvious step. Is it perhaps Indiana? If so, then you should be contacting that project team directly. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] The quick dirty guide to zones on iSCSI LUNs
roush writes: No, I have not encountered this problem. The targets mount just in time for my zones. But it sounds to me like a dependency on svc:/network/routing/route:default for cluster could help this along? CT Hi Christine, We have dependencies upon routing. However, this dependency only let's us know when initialization of routing started and does not tell us when things are ready. That's correct, though it's actually worse than that. Fundamentally, it's not possible to build such a dependency. There is no way to know whether you will ever receive any routing information from the other systems out on the network, or whether that information will ever be complete or even sufficient to perform the task you want to do. Ready makes no sense. As a simple (but by no means exclusive) example case that illustrates the problem, let's assume the following: - You're on the 192.168.0.0/24 network. This network using RIP-2 for routing. - There's a router located at 192.168.0.1. This router advertises the default route, because it connects to most of the rest of the networks in the area, and knows how to reach the (off-link) NAT to get to the wider Internet. - There's another router located at 192.168.0.2. This router advertises only a route to 10.0.0.0/24, because that's the only other interface it has. For simplicity, 192.168.0.2 is the only path to 10.0.0.0/24. - The router at 192.168.0.1 reaches 10.0.0.0/24 via 192.168.0.2. In other words, your local 192.168.0.0/24 network is also used for some internal transit traffic; it's not just a simple stub. Now suppose the server you want to reach is at 10.0.0.1. If 192.168.0.2 is down, you won't be able to get there because the only path is cut. A strictly dependency-based check, though would suggest that you *can* get there. After all, not only does routing come up on your local system, but you also hear a default route from 192.168.0.1. As far as dependency checking can go, you've got everything you need. Your packets, though, would end up errantly matching the default route, being sent via 192.168.0.1, and then either dropped silently, replied-to with ICMP Destination Unreachable, or perhaps even with a redirect to the unusable 192.168.0.2 router (because redirects stink as a routing protocol ;-}). In any event, you can't get there from here. In other words, by talking about such a dependency, I believe you're really asking the wrong question. The only dependency a networking application ought to have should be: is the networking stack initialized? And even that one (in a perfect world) ought to be a simple yes at all times. The right questions are: How do I set up a retry algorithm? Are there any ways to get hints for retries? If you're using TCP or SCTP, then the transport layer itself does the retries. You don't need to mess about with it; just let it do its job. At most, you need an application-layer retry, but that ought to be a fairly long timer: there's not much reason to pester a broken network with useless packets. For the second question, you can listen to a routing socket if you want. You'll get notified of routing changes, and these (particularly RTM_ADD) may well signal a good time to schedule another connection attempt. Any time the dependency lines on the graph extend outside the confines of the box, we need to be very careful. Networking is _not_ the same as system design, and SMF addresses only the latter. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dhcp/zones
Caroline Carol writes: Can you please let me know if DHCP works on local zones NOW ??? It's worked for quite some time now. You need to set up your non-global zones using set ip-type=exclusive. Is there any patch that fix this problem ??? OpenSolaris doesn't have patches. What are you running? If you're using Solaris 10, you should be contacting Sun's support group instead. (I believe IP Instances went into Solaris 10 Update 4, but, unlike OpenSolaris, some Ethernet drivers are not supported, and you may need patches for others.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] RE : Re: dhcp/zones
elkhaoul elkhaoul writes: Thanks for your answer. I am using Solaris 10 U4 8/07 That's not OpenSolaris. You should be contacting your local Sun support folks so that they're in the loop on what you're doing and can provide advice. And my interface is : ### dladm show-link ce0 type: legacymtu: 1500 device: ce0 ce1 type: legacymtu: 1500 device: ce1 Is this interface support exclusive IP ? With the right patches, yes. You need the patches for CRs 6616075 and 6606507, which I think are 137042-01 and 118777-12 for SPARC. But since you're not using OpenSolaris, you should be working with your local support folks on that rather than an OpenSolaris-related mailing list. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] The quick dirty guide to zones on iSCSI LUNs
Ellard Roush writes: Thanks for explaining about how the routing situation changes dynamically. However, we have been aware of that for a long time. Sun Cluster (SC) is a High Availability product. We have customers that want recovery to occur in less than 2 seconds. While we have not achieved that goal, we are working in that direction. This means that some operations MUST complete very quickly. A late completion of an operation is a failure. Understood. As a general principle, though, you cannot demand that other systems do anything you want at any other time. When networking is involved, other independent systems are involved. In other words, I think the focus is on the wrong level here. The whole deployment -- the routers, bridges, and other infrastructure included -- must be designed to meet your goal, not _just_ this one bit of Solaris software. (And once that's done, the state of routing in Solaris may or may not be at issue.) More specifically, when a quorum device is unreachable for substantial periods of time, the unreachable quorum device is in a failed state as far as we are concerned. This is true even when the device might be reachable 60 seconds from now. The administrator must configure a quorum device that can be reached reliably in a short time period. The solution is easy at this level: send a packet. If you get a sensible response, then that system is in fact reachable. If you don't get a sensible response within the time constraint that you've set for yourself, then it's not. That's really the only information available. The current SMF information does not even tell us when the Solaris routing software can even accept attempts to communicate. That's correct. As I've already outlined *it doesn't know* and (more importantly) *it cannot in principle know*. Or, if you prefer: it always accepts attempts to communicate. It just won't always be successful in those attempts. We already know that the attempts can fail. Before the routing software in Solaris is ready, all attempts to communicate will fail. We just want to know when it is safe to try. We are not asking for a dependency upon when a specific route is present. We know that is not possible. We have encountered problems when an attempt is made before the routing software is ready. We want to access the quorum device as soon as we can for quicker recovery, but no sooner than can be achieved reliably. There's just no general solution to the problem. If the only thing you care about is whether routing has established a route to somewhere, then (as I mentioned before) you can listen to a routing socket to observe the resulting RTM_ADD. I don't think that'll actually help you in your quest, but it's certainly doable and answers the immediate (and I think improperly formed) question of when routing software in Solaris is 'ready'. For some value of ready, at least. There is simply *NO WAY* that the system can tell you a priori whether an attempt to transmit a packet will actually result in that packet being sent from the system (ARP can still fail and Spanning Tree can disable ports silently) or whether delivery is possible. Only sending data can do that, and only then in retrospect. If you get an answer, then it must have worked. I strongly disagree that we should be offering any sort of routing is ready checkpoint or SMF dependency. It'd be misleading at best, and would result in a new class of unsolvable failure modes. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] The quick dirty guide to zones on iSCSI LUNs
Ellard Roush writes: James Carlson wrote: That point in time is as soon as your application can start. It need not have any dependencies at all. Here is the other point that needs to be clarified. This is not an application. Applications do not start until much later. We have to get the cluster formed and cluster services established before applications run. We probably have different definitions of that term. For networking, an application is something that uses the services provided by a transport or (for raw sockets) network layer protocol. I'm not talking about user applications; just things that use networking services in some way. Your program (whatever it is) should not need dependencies on networking in order to be successful. As I suggested before, it's sometimes helpful to listen to routing sockets (you can get hints there about when it might be a good time to shorten a retry timer, and thus make your program respond more quickly), but it's not really a dependency issue. The internal interfaces that we had to use are not well documented. Your explanation helps understand what is probably going on. It's hinted at in the documentation, but not as well-documented as it should be. man -s 3socket connect says: underlying transport provider. Generally, stream sockets can successfully connect() only once. Datagram sockets can use [..] ECONNREFUSED The attempt to connect was forcefully rejected. The calling program should close(2) the socket descriptor, and issue another socket(3SOCKET) call to obtain a new descriptor before attempting another connect() call. That generally is also true for most unsuccessful connect() calls and the advice under ECONNREFUSED is actually true for pretty much all failures. The exceptions are the non-failure failures -- EALREADY, EINPROGRESS, and EWOULDBLOCK. I think that issue is what the text is trying to dance around. You're partly connected (at least bound) after the real failures, and getting back to a clean state is easiest just by close() and trying again. The usual references (Stevens and others) have more detailed discussions. The underlying problem is that for much of the BSD world, the code *is* the documentation, so whatever sockets did, well, that's what they do. (For what it's worth, this isn't even one of the darker corners. Raw socket behavior, for example, varies in mysterious ways across OS platforms and even across releases of a given OS.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
