Re: [zones-discuss] Confirming Zone running Container
On Thu, Oct 2, 2008 at 3:53 PM, Menno Lageman [EMAIL PROTECTED] wrote: On 10/02/08 22:42, Nicolas Dorfsman wrote: Phillip, Le 2 oct. 08 à 22:38, Bruce, Phillip a écrit : Mike, Using zonecfg command can ONLY be used at the global zone level not at the container level. [EMAIL PROTECTED]:/var/adm# zonecfg zonecfg can only be run from the global zone. What are you trying to do exactly ? The Mike's tip need to be used on the global-zone AND a non-global zone reboot is mandatory. Actually, the reboot is not mandatory: [EMAIL PROTECTED] # touch /zones/aap/root/etc/globalname [EMAIL PROTECTED] # mount -F lofs -o ro /etc/nodename \ /zones/aap/root/etc/globalname [EMAIL PROTECTED] # zlogin aap cat /etc/globalname blondie Menno -- I almost replied with that... If you can take the outage, it is usually a good idea to test your change as soon as you make it. If the zone is up for another 6 months, you will not learn about your fat fingers until a time far removed from the change made. A more holistic approach is to get this into your standard zone build process. Many places have a script that they have written to build zones the way they like, others have customized zone templates. Whichever your style is (hopefully not manual steps every time) insert it into your repeatable process so it is a reliable indicator across all of your systems. FWIW, the way that I really implemented this was via copying a file like nodename into $zonepath/root/etc/globalzonename. I'll be changing that shortly to use lofs mounts so that it automatically handles things right with zoneadm detach + attach. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] rcapd
On Mon, Sep 1, 2008 at 6:55 AM, syed [EMAIL PROTECTED] wrote: Hi , I am facing an issue with rcapd, currently I have setup 8 sparse-root containers on a server with 32G physical memory, I have capped each of these containers varyingly and there is no issue with capping and it works fine. The issue arises when one of the containers eats up more memory (rapidly) than it has been allocated .It causes other non global zones to be less (noticable ) responsive while rcapd is trying to curb this unruly behaviour by one of the containers.I am wondering if this is due to heavy paging ? What does vmstat -p say? I bet it says yes! Has anyone else seen such behaviour, or is this an acceptable behaviour ? Any comments or experiences would be really helpful. I haven't, but then again that is because I expected to see such behavior if I used rcapd. There are very few circumstances in my world that make sense to encourage heavy paging - as rcapd will do. Solid state disk may change this a bit because paging would likely be a lot faster. For now, my approach is to cap the use of swap. Note that in this definition, swap is different than most people expect - it refers to how much memory a zone can reserve. If the sum of all of your zones' swap cap is 32 GB, you should see pretty much no paging to swap devices. You will still see file system (e.g. executable) paging. The most noticable side effect is that if the things running in a zone (including use of /tmp) try to use more than their respective caps, memory allocations will fail. I see this as a good thing because it means that the misbehaving application fails rather than taking down all the rest. rcapd works a bit like boot camp (military - not the mac thing). If one soldier (zone) misbehaves they all get punished. There may be circumstances where this outcome is desirable but server virtualization using zones is likely not one of them. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
On Wed, Aug 27, 2008 at 4:31 PM, Ethan Quach [EMAIL PROTECTED] wrote: Jerry, If its not for general purpose, then yes, I agree zonepath/ROOT is more clear. ?(And I also agree about the rpool name) Regarding a general purpose dataset, IMO we need to always automatically give this branded zone one of those since we're giving it the ability to manipulate its own BEs. ?With BEs, zone admins will inevitably want a place to store data shared by all of their BEs instead of having everything cloned. I'm with you here. It seems as though there should be a convention for a non-root dataset that is delegated to the zone. For instance zfs create -o mountpoint=none rpool/zones/z1/share zonecfg -z z1 add dataset name=rpool/zones/z1/share zoneadm -z z1 boot -s zlogin z1 zfs set mountpoint=/share rpool/zones/z1/data Again - some would immediately choose /export instead of /share. Unless you are using samba, there isn't much chance you will be exporting much from a zone so filesystem(5) says it is the wrong place. In this context, /share is indicating that it is shared between boot environments. This goes along the same lines as the /var/share idea that I've been pushing for a while. So as to not muddy the waters with the historical use of share (e.g. /usr/share) it may be appropriate to use common instead of share. I don't really care - so long is the name is indicative of current use and doesn't throw us into UNIX history lessons with new users. Scope creep ahead... On a somewhat related noted, delegated datasets seem to expose administrative decisions made in the global zone that the local zone administrator shouldn't care about. An alias mechanism to hide this detail seems to me to be a reasonable thing to do. # zonecfg -z z1 add dataset set name=pool67fromArraySN-SF23424HW23/acct7823/z1 set alias=share end commit exit # zfs set mountpoint=none pool67fromArraySN-SF23424HW23/acct7823/z1 # zoneadm boot z1 # zlogin z1 zfs set mountpoint=/share share # zlogin z1 zfs list NAME USED AVAIL REFER MOUNTPOINT share 18K 4.86G18K /share I'm done with scope creep now. :) -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
On Tue, Aug 26, 2008 at 5:07 PM, Ethan Quach [EMAIL PROTECTED] wrote: Hey Jerry, I just thought about something regarding the zones dataset namespace. Instead of creating the dataset for zone roots at: rpool/export/zones/z1/rpool/ZBE1 Maybe we should insert the roped off ROOT container dataset like we do in the global zone: rpool/export/zones/z1/rpool/ROOT/ZBE1 so that we confine the place where we know boot environment roots live. The reason we do this is in the global zone is so that we don't have to troll through potentially thousands of datasets (sorting out whatever's been created in the shared area) to find BE roots. This same problem would occur in the zone BE namespace. Thoughts? rpool/ROOT seems to be redundant and it repeats itself. :) In the global zone, rpool/ROOT makes sense because there needs rpool and ROOT perform different duties. In a non-global zone, rpool/export/zones/z1 is equivalent to the global zone's rpool. To maximize synergies (and end abuse of /export - see filesystem(5)), I suggest: This is the equivalent of the global zone's rpool. Or in an environment where there is a pool per zone, it may be z1pool. rpool/zones/z1 This is managed by zoneadm and beadm. If all goes well, they both use libzonecfg to minimize the chance of divergence. rpool/zones/z1/ROOT rpool/zones/z1/ROOT/be1 rpool/zones/z1/ROOT/be2 The rest are available for use within the zone and may be mounted other places rpool/zones/z1/* -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone cloning using zfs?
On Thu, Aug 14, 2008 at 11:20 PM, Lori Alt [EMAIL PROTECTED] wrote: Anybody know how to get zoneadm clone to use zfs cloning? I've got a zone (z1) whose root is a zfs dataset. I configure a new zone (z2) and try to make z2 a clone of z1: # zoneadm -z z2 clone z1 This works, but the clone is constructed by copying z1, not by doing a zfs clone. What am I missing? Is this on S10 or Nevada? With somewhat older nevada releases, I'm pretty sure I have done just as you describe. Currently S10 does not have that support yet, but I think that U6 will fix that. Does zoneadm -z z2 clone -? mention zfs? -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] swap memory cap and swap command output
On Mon, Aug 11, 2008 at 8:35 AM, Glenn Brunette [EMAIL PROTECTED] wrote: My apologies if this is a RTFM moment, but I have been looking and have been unable to find an answer. If memory caps are defined for a given zone, why doesn't the output of swap display the cap? # zonecfg -z web info capped-memory capped-memory: physical: 1G [swap: 200M] As an aside, this configuration doesn't seem to make much sense. It seems to be saying that you can only reserve 200 meg of memory and if you are using more than 1 gig, you risk having the portion over 1 gig paged out by rcapd. I suspect that you really want physical at 1 gig and swap at 1224M (1G + 200M). I really wish that swap didn't have multiple meanings. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] 6715679 - update on attach handling of /etc/release
I just saw a bunch of goodness put back by Jerry - yippeee!!!
http://hg.genunix.org/onnv-gate.hg/rev/288aec05f619
I am a bit confused by the way that /etc/release is handled:
+ if (update_res == Z_OK) {
+ /* Install the new /etc/release file. */
+ (void) snprintf(cmdbuf, sizeof (cmdbuf),
+ exec /usr/sbin/zlogin -S %s
+ '/usr/bin/cat /a/etc/release' /etc/release, zonename);
+
+ status = do_subproc(cmdbuf);
+ if (subproc_status(/etc/release, status, B_TRUE)
+ != ZONE_SUBPROC_OK) {
+ (void) fprintf(stderr, gettext(could not update
+ zone\n));
+ update_res = Z_ERR;
+ }
+ }
Why take this approach rather than changing or overriding the
SUNW_PKG_ALL_ZONES attribute on SUNWsolnm? It seems as though the
approach taken will make it so that the package version doesn't match
up with the release and pkgchk will complain about /etc/release in
non-global zones that have been updated to a newer release.
Without knowing any of the back story and assuming that changing
SUNW_PKG_ALL_ZONES on an already installed package is really bad to
do, it seems as though this could be better handled with a hook here:
usr/src/lib/brand/native/zone/sw_support.c
1115
1116 } else if (strcmp(buf, SUNW_PKG_ALL_ZONES) == 0) {
1117 infop-zpi_all_zones = B_TRUE;
1118
My thought is that if the package name is SUNWsolnm,
infop-zpi_all_zones should be B_TRUE.
--
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Seeking feedback: temporary detach/attach of existing zones to allow for
On Mon, Jun 23, 2008 at 7:53 PM, Jeff Tomer [EMAIL PROTECTED] wrote: I have a number of whole root zones with 'zonepath' set to a file system on SAN storage. I have lost access to the SAN storage, and thus to the zones, and need to patch the global zone in order to regain access to the SAN LUNs. However, I am unable to apply the patches because my access to the non-global zones is impaired -- an interesting corner case that no doubt has impacted others. Here is my workaround: detach all of the non-global zones, apply the patch, and then re-attach (attach -F) all the zones. This seems to work but I am looking for 1) any feedback on whether this is advisable or not, 2) what the long term implications are for management of these zones, and 3) any other suggestions for another workaround. If you are running Nevada, you should be able to use update on attach to get them back. zoneadm -z $zone attach -u Since you say you require a patch, I'm guessing you are running S10. My understanding is that update on attach will come in S10u6. If you can hold on a few months, you will be in good shape. :/ -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] need input for zone update on attach
On Wed, Jun 18, 2008 at 8:47 AM, Steffen Weiberle [EMAIL PROTECTED] wrote: I am not sure I have an opinion yet, as I am not sure what major downgrade means. If that would allow you detach the zone from the new system and re-attach on the original, I can see a benefit. (The inability to attach a zone on its original system is my biggest concern with the upgrade on attach.) The combination of update on attach plus zones on ZFS should make this problem be one that isn't too scary. I imagine the following as being standard practice. zfs snapshot zones/[EMAIL PROTECTED] zoneadm -z $zone attach -u if [ $? != 0 ] ; then zfs rollback zones/[EMAIL PROTECTED] fi Of course, it would be nice if zoneadm would just do this on its own. One thought with 2) is to also consider -P filename, where filename lists the patches or packages. Similar to -x and -X for flarcreate. The only reason I would say not to use another option is to keep the option free for other things in the future. I think that the IDR situation will be rare and the probability that a lot of IDR's exist on a single system is quite unlikely. Assuming that the Indiana/OpenSolaris approach to packaging is integrated as the replacement for current packaging+patching then this functionality will not really be needed post S10 and as such also suggests that keeping the option free for something else may make sense. If I am wrong about the likelihood of having a longish list of patches to ignore, then I think the -P option makes sense. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] need input for zone update on attach
On Tue, Jun 17, 2008 at 4:46 PM, Jerry Jelinek [EMAIL PROTECTED] wrote: If the original system is still available, you can work around this by removing the IDR before migrating the zone. Is it feasible to simply remove it as part of attaching? I don't think that it is possible to install an IDR with patchadd -d and a spot check of a zone that has an IDR (installed in global zone before non-global zone creation) shows that there is a package datastream file at /var/sadm/pkg/$pkg/save/$idr/undo in the non-global zone. I have a few different ideas for how to handle this. 1) change the meaning of attach -u -F Right now -F just forces the attach, changes the zone state to installed and we're done. No update occurs. We could change the interaction of these two options so that we still do the update but ignore any verification warnings. However this would allow a potentially major downgrade. This would be my third choice, but wouldn't be too excited about it. If this is done there needs to be clear warning or error messages in log files under the newly attached zone's /var/sadm directory. 2) attach -u -p xxx -p yyy Add a new -p option which allows you to specify patches to ignore. We would use this to specify IDRs which don't exist on the target, although it could also be used for regular patches that might be broken. The user would have to understand this at a pretty good level to know when to use the option. We might want to extend this idea to specify pkgs as well, in case we have a broken pkg. This allows a potentially major downgrade if the user specifies a lot of patches. If it is not possible to back out the missing IDR, then this would be my second choice. 3) attach -u -i Add a new -i option which means ignore all IDRs. This is pretty specific to the IDR issue, doesn't require a lot of thought for the user, but doesn't give much flexibility if we hit a different problem with bad patches or pkgs. This forces the user to think about the impact of ignoring the IDRs before an update is done. 4) attach -u No change to the CLI but change the implementation to always ignore all missing IDRs. This might still allow a pretty big downgrade with no user input if you had a lot of IDRs on the source system for some reason. This is pretty specific to the IDR issue, doesn't require any thought for the user, but doesn't give much flexibility if we hit a different problem with bad patches or pkgs. Let me know what you think about these choices or if there is another idea that seems better. I really hope it could just be backed out. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] lsof/zone
On Fri, May 16, 2008 at 4:05 AM, elkhaoul elkhaoul [EMAIL PROTECTED] wrote: Hi all, How to get lsof working on the local zone : ### lsof lsof: can't stat(/devices): No such file or directory lsof does not work in zones. The best options you ave are: Option 1: use pfiles in the non-global zone: # cd /proc # pfiles * Option 2: use lsof in the global zone In my opinion, neither option is a great option. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Best practice for patching with failover zones
On Fri, Apr 18, 2008 at 2:27 PM, Jay Morgan [EMAIL PROTECTED] wrote: Scenario (simplified): - 2 node cluster (nodes A and B) using Veritas Application Director (Similar to Veritas Cluster Server in functionality) - Each node is running Solaris 10 11/06 (update 3) with identical patches (recommended patches from around 7/07 or so) - There are two non-global sparse zones (Zones 1 and 2) for services that fail over between the nodes with shared storage for the zone roots (using zone attach/detach to fail zones back and forth) We want to install recent patches on these systems, minimizing downtime. I know Solaris 10 8/07 added live upgrade support for zones, but that isn't an option right now. Initial question - it is my understanding that when zones are detached, they go into the configured state on the detached node, and patchadd will not attempt to patch these configured non-global zones. Correct? Correct. What I'm thinking for best practice: - leave zone 1 on node A, and zone 2 on node B. OK. - disable cluster on node A and set service group for apps in zone 1 to maintenance mode, shut down apps in zone 1, prepare node A for patching. - patch node a and zone1 and reboot, make sure zone 1 comes up appropriately. - re-enable cluster on node A, restart apps in zone 1, verify apps are running appropriately and take apps in zone 1 out of maintenance mode. Assuming the app in zone1 and zone1 are all part of zone1_sg: hagrp -freeze zone1_sg hasys -freeze nodea Patch as normal, reboot. hasys -unfreeze nodea hagrp -unfreeze zone1_sg I suggest freezing just in case you accidentally boot to multi-user mode and vadclientd.bin comes up and starts fixing things. - repeat above process for Node B/Zone 2 - Test failover of Service Groups/Zones between nodes. Again with freeze/unfreeze. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] can non-zones see less RAM than global?
On Sat, Mar 15, 2008 at 6:25 PM, Anne Moore [EMAIL PROTECTED] wrote: Hi All I have a major issue with my OpenSolaris 10 sparc box. I have 16GB of RAM on the box. Every one of my zones see's this 16GB of RAM and so I can only run 3 Oracle zones (because Oracle must use 50% of the total ram it sees, and it can't be changed.) Here's my question: Is there any way in a non-global zone that I can make that non-global zone see only the partial amount of RAM installed on the server? Say, can I make the non-global zone see 8 GB of RAM, instead of the 16GB that is installed on server? If you are Solaris 10 Update 4 (8/07) or at least have recent patches installed you can set various parameters that can be useful. From http://docs.sun.com/app/docs/doc/816-5166/6mbb1kqlf?a=view: zonecfg:my-zone3 add capped-memory zonecfg:my-zone3:capped-memory set physical=50m zonecfg:my-zone3:capped-memory set swap=100m zonecfg:my-zone3:capped-memory end zonecfg:myzone3 exit Also see: http://opensolaris.org/os/community/zones/files/Zones_RM_Improvements.html http://blogs.sun.com/menno/entry/system_v_ipc_resource_controls http://opensolaris.org/jive/thread.jspa?messageID=156766 http://mail.opensolaris.org/pipermail/zfs-discuss/2006-August/033717.html (prstat and rcapd are much better about counting memory now, but I would still contend that if rcapd has to do any work it will induce poor performance across all workloads) -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] new option - cpu-dedicated
On Tue, Mar 11, 2008 at 4:49 AM, Enda O'Connor [EMAIL PROTECTED] wrote: Now please make sure 119254 latest rev is installed first ( it's the patchadd patch ), before adding 120011-14. Also read the README in 120011-14 carefully. Does updatemanager use patchadd -M under the covers? If so, the latest rev of 119254 may hit: 6668239 patchadd -M might fail after intalling 119254-49 or later -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] How to configure Global/Local zone in seperate subnet and use seperate router
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. If you want to add redundancy using IPMP, double the number of physical networks. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] zones on iSCSI LUNs
I have three (hopefully) quick questions: - Are there any current (S10) or future incompatibilities with zone roots on iscsi? - Are there any current (S10) or future incompatibilities with zone roots on SVM disk sets? - Are there any current (Nevada) or future incompatibilities with having one zfs pool per zone? Zone cloning with zfs clones will be broken - anything else? And here's why I ask... I'm working on some improvements to my existing zone configuration and management methodology. As much as possible I am looking to have the improvements be future looking enough that as future improvements come about I have to do the minimal rework. My understanding is that: - Today each zonepath must exist on a UFS (or VxFS or possibly QFS) file system. Read another way, ZFS is not supported for zones today. The key reason for this is the lack of support for upgrade and sporadic support for patching of zones on ZFS. - In the next release of Solaris, zones will have to be on ZFS due to expected changes in packaging, patching, and installation. - There will be a transition period between zfs not supported and zfs required that will likely start with the release of S10U6. My anticipated direction is to discontinue the use of local (within the server chassis) storage for zone roots and transition to using (likely) one or more iSCSI LUNs per zone. Initially, the iSCSI LUNs would either have UFS file systems on them directly or use SVM disksets to allow soft partitions. When the time is right, new LUNs would be allocated for ZFS and data will be migrated. Any SVM disk sets will be destroyed in favor of using ZFS. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones on iSCSI LUNs
On Fri, Feb 15, 2008 at 12:50 PM, Ben Rockwood [EMAIL PROTECTED] wrote: Mike Gerdts wrote: My understanding is that: [...] - In the next release of Solaris, zones will have to be on ZFS due to expected changes in packaging, patching, and installation. I am aware of no such change. - There will be a transition period between zfs not supported and zfs required that will likely start with the release of S10U6. Same here, I'm not aware of this change and would by highly skeptical. Nevada hasn't taken this turn, and again, even if it did that would be imposed simply by the configuration tools and easy to bypass. This is the best reference I can find right now. http://www.opensolaris.org/os/project/caiman/Snap_Upgrade/Notes/Snap_Containers/ There have been several discussions on one or more installation related lists (pkg-discuss, install-discuss, caiman-discuss) that have confirmed that the next generation installation and packaging commands will have ZFS as a prerequisite (for global zone root as well). -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dhcp/zone
On Dec 11, 2007 3:10 AM, elkhaoul elkhaoul [EMAIL PROTECTED] wrote: Hi, I want to install dhcp on local zone... OS : # uname -a SunOS esp43 5.10 Generic_127111-02 sun4u sparc SUNW,Sun-Fire-V490 # zoneadm list -cv ID NAME STATUS PATH BRANDIP 0 global running/ native shared 2 esp43 running/export/zones/esp43 native shared Is dhcp can run on this local zone ? Contrary to what everyone else says, with a bit of customization dhcpd can run zones just fine. Solaris 10 update 3 and later (I forget which Nevada build) have all the required bits in place. http://mail.opensolaris.org/pipermail/install-discuss/2007-March/004266.html -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dhcp/zone
On Dec 11, 2007 9:37 PM, Peter Memishian [EMAIL PROTECTED] wrote: Contrary to what everyone else says, with a bit of customization dhcpd can run zones just fine. Solaris 10 update 3 and later (I forget which Nevada build) have all the required bits in place. http://mail.opensolaris.org/pipermail/install-discuss/2007-March/004266.html Yep, it can be made to work, though I don't think it's officially supported. When I last looked at this issue, the changes needed to the source to make it work without any special tweaks was straightforward. If you offer up hints, I make take this on in the future. I've got a couple other things I want to work on before this one, though. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] netmask warning, misconfiguration
On Dec 3, 2007 5:43 AM, James Carlson [EMAIL PROTECTED] wrote: 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. If using only a local netmasks file, it works quite well. I much prefer to have one authoritative netmasks file per system than having system administrators specifying the mask every time addif ... is added to /etc/hostname.* or a zone is created. It is quite likely that /etc/netmasks is not as desirable in situations where lots of networks are referenced. For example, systems with non-trivial firewall (or similar) rules would most likely benefit from CIDR notation because you may have some rules that apply to 10.0.0.0/8 with more refined rules for 10.27.45.128/25. /etc/netmasks would be worthless for that. For configuring IP addresses on the typical machine bolted to a rack or sitting on a desk, /etc/netmasks is quite manageable, stable, and desirable. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] netmask warning, misconfiguration
On Dec 3, 2007 8:45 AM, James Carlson [EMAIL PROTECTED] wrote:
Besides the look-up ambiguity, there are also the chicken-and-egg
problems that occur when users accidentally configure the system to
use NIS or some other directory service for netmask resolution.
Trying to configure an interface using a service that's reachable only
by talking on that interface doesn't work very well unless the
protocol was designed to be used that way -- and NIS was not. In
fact, at least inside Sun, it's a somewhat common way to produce
apparent hangs on boot.
Getting netmasks from NIS is a bug. /etc/nsswitch.{nis,ldap,etc}
should not suggest that this is a good practice.
I much prefer DHCP or BOOTP for these cases. It's centrally managed,
so you don't have to tweak each machine to have the right information,
and it's standards-based, so you can integrate with other systems.
Don't let the dynamic word in the name get in the road; whether the
addresses are dynamic or stable over time is a matter of
administration, not a requirement of the protocol.
Please continue to spread the word about dynamic frequently. I
can't tell you how many times I have had to express the same to people
that have a fear of it because they assume that every address
allocated will be from a dynamic address range or that anything that
plugs into the network will automatically get an IP address.
--
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Migration - Sun4u to Sun4v - Supported?
On Nov 8, 2007 4:14 AM, Mads Toftum [EMAIL PROTECTED] wrote: On Wed, Nov 07, 2007 at 11:11:13PM -0800, Andrew wrote: Can anyone advise if it is supported to migrate a zone from one SPARC architecture to another? E.G., Sun4u to Sun4v? I presume this should be ok provided the Solaris build on both target and source platforms is the same? Things should run, but there's a recent RFE to make attach work across sun4u and sun4v: 6576592 RFE: zoneadm detach/attach should work between sun4u and sun4v architecture But I'm sure it would work if you hacked the files under /etc/zones. Hacking files under /etc/zones will not help. The problem is that there are a few packages SUNW*.[uv] that are different between sun4u and sun4v. From what I recall, a 15k with SUNWCXall and a T2000 with SUNWCXall (with S10U1) had less than 10 MB differences with one (identical file) conflict between the two. I suspect that if you install the SUNW*.v packages on the sun4u box and install the SUNW*.u packages on the sun4v box, the migration (detach + attach) will go OK. There is likely some room for caution here with regards to how well patching will handle this after the fact. The initial assessment by the likes of Dave Miner and Casper Dik was that things may work on one day but long term supportability was dubious. Initial conversation summarized in the first 30 or so lines of http://www.opensolaris.org/jive/message.jspa?messageID=29843#29843 Casper warns about patching: http://www.opensolaris.org/jive/message.jspa?messageID=29843#29871 I experiment with pkgadd -d . *.v http://www.opensolaris.org/jive/message.jspa?messageID=29843#29919 Casper finds an unimportant conflict: http://www.opensolaris.org/jive/message.jspa?messageID=29843#29910 Dave Miner explains that that multi-platform flash was supposed to work but cautions that there may be dragons. http://www.opensolaris.org/jive/message.jspa?messageID=29843#30095 -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Migration - Sun4u to Sun4v - Supported?
On Nov 8, 2007 6:40 AM, LaoTsao(Dr. Tsao) [EMAIL PROTECTED] wrote: hi it seems these issues will be solved by a brandZ for s10, nv etc not? Is that in the works? I've seen an example of how to do it on your own but I haven't heard of any supported variant. The key gotcha with this approach seems to be the sanity check to be sure that the kernel and SUNWzone* from the global zone remain compatible with the bits in the non-global zone(s). I would like to see this functionality, but as I was trying to articulate why in a thread (I think regarding update on attach) I was having a hard time. I really think that update on attach would also solve the issue at hand, now that I think about it. http://www.opensolaris.org/os/community/arc/caselog/2007/621/ Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Migration - Sun4u to Sun4v - Supported?
On Nov 8, 2007 7:12 AM, LaoTsao(Dr. Tsao) [EMAIL PROTECTED] wrote: I would like to see this functionality, but as I was trying to articulate why in a thread (I think regarding update on attach) I was having a hard time. I really think that update on attach would also solve the issue at hand, now that I think about it. http://www.opensolaris.org/os/community/arc/caselog/2007/621/ Just wondering if zone move from host-A to host-B and get update what happen if this zone need to move back to host-A, does it need to be downgraded? It would need to be downgraded, but the last draft I read of the update on attach spec that I read did not support this. I would not expect it to support it in the future either, as downgrade in Solaris and pretty much every other OS has traditionally be restore. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] apache2 ignoring capped-memory
On 11/4/07, John-Paul Drawneek [EMAIL PROTECTED] wrote: apache seems to be eating all the ram. build 75 sparc its in a zone which its memory is capped, its coolstack apache2 with apc on. Any one else seem this? How is this configured? Most likely, you have confusion between physical and swap. They are just the opposite from what you might think. From zonecfg(1M): capped-memory: physical, swap, locked The caps on the memory that can be used by this zone. A scale (K, M, G, T) can be applied to the value for each of these numbers (for example, 1M is one megabyte). Each of these properties is optional but at least one pro- perty must be set when adding this resource. Only a sin- gle instance of this resource can be added to the zone. The physical property sets the max-rss for this zone. This will be enforced by rcapd(1M) running in the global zone. The swap property is the preferred way to set the zone.max-swap rctl. The locked property is the preferred way to set the zone.max-locked-memory rctl. From rcapd(1M): When the resident set size (RSS) of a collection of processes exceeds its cap, rcapd takes action and reduces the RSS of the collection. That is, if you set the physical cap only, this will still allow memory allocations to continue unbounded. However, so long as rcapd is running in the global zone, pages of physical memory will be filled by paging them out to swap space or other backing store. If rcapd is not running, it seems as though this would have no effect. To make it so that memory allocation fails and Apache and the rest of the zone can't use more RAM (likely crashing Apache or anything else that tries to allocate memory above the limit), you really want to set the swap limit. This is counter-intuitive only because the definition of swap in this context is poorly understood, largely because the term has different meanings based upon the context. In this context, swap is the amount of physical RAM + swap space (swap devices + swap files) that can be used by the zone. In other words, if you want a zone to be able to use 1 GB of physical memory and allow another 1 GB to be paged out, you would want to set physical to 1 GB and swap to 2 GB. Note that when a process requests and is granted a memory allocation, this immediately turns into a swap reservation. Physical memory is not actually considered used until it is touched. The most common scenario I see where this pops up is when several java processes are running with large -Xmx parameters set but don't actually use all of this memory. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] apache2 ignoring capped-memory
On 11/4/07, John-Paul Drawneek [EMAIL PROTECTED] wrote: I have got apache2 in a zone capped-memory: physical: 512M [swap: 2G] [locked: 100M] rctl: name: zone.max-locked-memory value: (priv=privileged,limit=104857600,action=deny) rctl: name: zone.max-swap value: (priv=privileged,limit=2147483648,action=deny) I have got real helixserver in a zone capped-memory: physical: 512M [swap: 1G] [locked: 150M] rctl: name: zone.max-locked-memory value: (priv=privileged,limit=157286400,action=deny) rctl: name: zone.max-swap value: (priv=privileged,limit=1073741824,action=deny) box has got 1280mb of ram - all should be good (ok to my limited knowledge) apache2 gets huge - helixserver stops streaming - reset apache2 helix server starts again. ideas on what evils apache2 is doing? Or a way to find out what resource helix server needs? By having the max swap (3 GB) larger than your physical memory (1.2 GB), as the processes grow in memory usage, they will start to page. Heavy paging will slow the box down tremendously, to the point where performance sharply degrades. Under enough contention, it is quite possible for this degradation to cause processes to pause for many seconds or longer. I just today noticed that pmap has a -S option to show swap reservations. Perhaps this will be helpful. I suspect that what you really need to do is one of the following: 1) Set the swap limit on Apache to something much closer to 512MB. Probably a good idea to set the swap limit for Helix closer the the physical as well. 2) Install another 2 GB of RAM. Paging to swap devices is evil. Workloads that need more memory than you have physical RAM for their working set will not give suitable interactive performance (and even batch performance would be miserable). -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones and NPIV
On 11/3/07, Ran Jack Meng [EMAIL PROTECTED] wrote: Any comment on the idea and the prototype? I love the idea. I had assumed that I would have to implement LDOMs to get this level of integration with NPIV. The key thing that I would be looking for is that I can detach a zone from one box and attach it to another and all would be well without storage reconfiguration - the storage would be accessible by the non-global zone regardless of where it is at but would not be accessible by the global zone or any other non-global zone. If that wouldn't work, I guess I need to get better grounded in how NPIV works and would appreciate any pointers to concise info to help bring me up to speed. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [Fwd: Cloned zones and printers - redux]
On 10/31/07, Norm Jacobs [EMAIL PROTECTED] wrote: Mike Gerdts wrote: It seems as though printers.conf could point to localhost in the master zone and the clones would then also point to their respective selves. Is there something broken with that approach? Not that we don't see it, but we don't recommend configuring more than one system (or zone in your situation) as a print server for a network attached printer. Doing so can cause starvation and doesn't provide you with an accurate view of the print queue because there are multiple queues feeding the device. The bottom line there is that you can end up submitting a print job, appear to be printing or ready to print and sit there while other systems (or zones) are busy printing copies of the phone book. Every time you check the queue, you are either printing or waiting for the device, but the activity on the device is invisible to your system or zone. Now, if the printer in question isn't going to be particularly busy or is only really used by a small number of people, it's not a real problem. In the general case, I agree with you. This, however, is something more of an enterprise print architecture argument rather than addressing the zone configuration. There are cases where a local print queues for the same physical printer may be appropriate. For example, if I have a node-locked licensed application that prints in a format that is not understood by the printer, the local print queue may act as a filter that translates to PS or PCL then forwards to a traditional print server that feeds print jobs to the real printer. If the print server does not have a license for the app (or is otherwise incapable of running the app), it may not be able to use the application to do the file conversion. Several years back I dealt with engineering apps that would generate 100's of pages of garbage if File-Print was used. If the print queue recognized the print job format and put it through the right filter (that called the app in command line mode to do a conversion) it would print a nice single page drawing. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [Fwd: Cloned zones and printers - redux]
On 10/30/07, Norm Jacobs [EMAIL PROTECTED] wrote: I'm not on zones-discuss, but this was forwarded to me. It sounds like you created a local print queue for your network attached printer in your source zone. When you clone that zone, the printers.conf file entry in the new zone references the hostname of the source zone, so the print commands try and contact the print service in the source zone instead of the current zone. You can fix this by configuring a queue for your printer in the global zone (or on another system) and then configuring access to the remote queue. It seems as though printers.conf could point to localhost in the master zone and the clones would then also point to their respective selves. Is there something broken with that approach? -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Solaris 8 Branded Zones
On 10/25/07, Jerry Jelinek [EMAIL PROTECTED] wrote: Mario, While it would be possible to do this, it is in some sense harder than it was for S8. S10 is still a very dynamic release so the interpositioning layer would need constant work to cope with the on-going changes in the kernel/user-land boundary. I've been thinking that I would like this capability as well, but as I tried to articulate why I found very few arguments that I could stand behind long-term. The key thing that this would address for me is being able to move a zone between sun4u and sun4v, which already seems to be on the radar, as mentioned in Jerry's initial message at http://www.opensolaris.org/jive/thread.jspa?messageID=127152 One additional comment. I believe this proposal should also address the recurring question about being able to migrate a zone from sun4u to sun4v (and back). As far as easily moving a zone around, take a look at 6480464 RFE: zoneadm attach should patch/update the zone to the new hosts level I would also be quite interested in having a mechanism to live upgrade a single zone. This way I could do the following to maximize flexibility in scheduling for consolidated servers while minimizing down time for patching. That is, the process would look like: host1# lucreate -Z zonename ... host1# luupgrade -Z zonename ... host1# luactivate -Z zonename ... host1# zlogin zonename init 0 host1# zoneadm -z zonename detach host2# zoneadm -z zonename attach host2# zoneadm -z zonename boot Now that the S8MA project is done I am planning to get back to this RFE. This is a much more straightforward solution to the problem than a new brand. I suspect that the update on attach process may be substantially faster than patching, so maybe the method I mention above isn't terribly important. I think with update on attach, I may be able to accomplish the same with: host1# zlogin zonename init 0 host1# zoneadm -z zonename detach host1# zonecfg -z zonename export -f /zones/zonename/zone.cfg host1# zfs snapshot zonename@host1-detach-timestamp host1# zonecfg -z zonename delete host1# zpool export zonename host2# zpool import zonename host2# zonecfg -z zonename -f /zones/zonename/zone.cfg host2# zoneadm -z zonename attach -u If things went badly with attach -u: host2# zoneadm -z zonename detach host2# zpool export zonename host1# zpool import zonename host1# zfs rollback zonename@host1-detach-timestamp host1# zonecfg -z zonename -f /zones/zonename/zone.cfg host1# zoneadm -z zonemame attach My use case is based upon the notion that I want each zone to be able to move independently, and as such a zpool is created per-zone. Certainly there are other strategies that could be applied (move many zones at once, use zfs send | something | zfs receive, AVS, etc.). -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zlogin invoked by cron hangs after a few minutes
On 10/23/07, Damien Carbery [EMAIL PROTECTED] wrote: Any thoughts? Suggestions? Is there a bug here? We currently use a chroot environment to build JDS but a zones setup would be preferred as it is a supported feature. When I was first implementing Solaris 10 (before the first S10 kernel patch was released), I found similar behavior when running JASS via zlogin. When I caused JASS to dramatically reduce its output (to almost nothing) the problem went away. I don't know if this is related or not - lots has changed in the code since then. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Problem patching zones with kernel patch 120011-14
On 10/15/07, Andrew Blatt [EMAIL PROTECTED] wrote: I try and patch a server with this patch and I get /var/run full: # df -k /var/run Filesystemkbytesused avail capacity Mounted on swap 20480 20480 0 100%/var/run Do you really have that little RAM or did you set a limit on the size of /var/run (mount -o size=20M)? It looks as though things that are going to need a non-trivial amount of temporary space should check to be sure that this space is available. Rather than relying upon /var/run to provide this space (historically this has been pid files, etc. and setting a limit in vfstab sounds reasonable) perhaps the patching utilities should mount up their own tmpfs file system as needed. Ideally there would be an option to a tmpfs mount to reserve the required amount of swap (virtual memory, not blocks in swap device). This would mean that critical operations stand less of a chance of getting messed up by the system running short of memory during patching operations. Perhaps a ramdisk would be better suited, but I assume that the ram part of the name implies bad things on systems without a lot of RAM. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Groups
On 10/10/07, Doug Scott [EMAIL PROTECTED] wrote: It would be nice to have some zones 'or a group' which are independent of the global zone and can be patches/updated together. Is this a good idea or is there another way of achieving the same goals. I would be especially fond of full-root zone that was patched independently from the global zone and a mechanism existed to just be sure that the minimum set of dependencies were met. For example, be sure that there is not a libc vs. kernel mismatch. This seems likely to be a branded zone, but I haven't looked into it much. Use case: Consider a group of machines with the following characteristics: - Minimized global zone (just enough to manage server and boot zones) - Zonepaths on shared storage (e.g. iSCSI, QFS, or similar) - A framework to manage where the zones run Things that could be done: - Zones could easily migrate to another machine so long as dependencies are met (or to meet new dependencies) - A tool substantially similar to live upgrade could be used to patch zones. - The global zones across the various machines could be patched, upgraded, or replaced as a rolling operation with only one short outage to each zone. - Patching and upgrades can be done to one or many zones at a time. That is, we would no longer be stuck with the current method that forces all zones on a box to be patched serially during one long outage to all zones on that box. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ps -Z is broken
On 9/26/07, Peter Tribble [EMAIL PROTECTED] wrote: On 9/26/07, Nicolas Williams [EMAIL PROTECTED] wrote: On Wed, Sep 26, 2007 at 09:52:29PM +0100, Peter Tribble wrote: Isn't this as easy as changing the format specifier from %8.8s to %8s? OK, so then the columns don't line up. How much is this a problem? It's a big problem. Bigger than giving completely incorrect output? I agree that it is a bug. Names of zones, users, groups, projects, etc. should not be truncated unless the command allows me to specify the column width. I get what I deserve if I tell a command to be imprecise but the precision is important. Personally, I think ps needs an option to output non-column oriented text. OK, so I need to work out how wide the column should be and expand it to suit? Don't worry about the alignment. Sure it will be ugly, but ugly is better than wrong. Take vmstat, df, or any number of other commands as a precedent. I stopped using sar at a time when all the numbers started running together and I could no longer trust that the output was correct. In the meantime you can use ptree(1) and friends instead of ps(1) and avoid the problem, I think. I'm not sure how that helps. The question I wanted ps to give me the answer to was simple: show me what processes a user is running, and add on which zone they're in so I know which zones are in use. Now, 'ps -flZ -u fred' would seem to be the ideal command to use, but due to this bug it isn't. How about a variant of: ps -o zone,user,pid,args -u fred This may produce ugly yet correct output (assuming that all zones use the same name service - may break anyway if ps is too smart). You can adjust the columns to match the -flZ output if desired. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] unable to rsh into zone2
On 9/26/07, James Carlson [EMAIL PROTECTED] wrote: Russ Petruzzelli writes: body bgcolor=#ff text=#00 ttrun inetadm, see if rlogin is enabled.../ttbr Note that rlogin and rsh (shell) are two completely separate and unrelated protocols. And the situation is thoroughly confused by the fact that rsh hostname really uses the rlogin protocol and rsh hostname command uses the rsh protocol. I wish I had a dime for every time I had to explain this to someone that was trying to get rsh or rcp to work. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] how long would it take to install a zone on Sun
On 9/19/07, Dan Price [EMAIL PROTECTED] wrote: By default /opt will be *copied* from the global zone. If you want it to be sparse instead (which means it will be a loopback, read-only filesystem) then add an inherit-pkg-dir entry for /opt. This will usually significantly speed up installation, especially if you have a lot of stuff in /opt. I initially thought this was a good idea, but life in the trenches says otherwise. I've found it extremely common that software needs to be installed into /opt - sometimes via pkgadd and sometimes otherwise. If software is installed via pkgadd, single-zone installation of software is just broken with an inherited /opt. If it is installed via another mechanism, you can mount other file systems on subdirectories of /opt - but means that you have to create the mount point in the global zone. This has the potential to complicate zone migration and causes confusion for those that are already struggling with zones and inherited directories. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] 06/06 08/07
On 9/9/07, Morris Hooten [EMAIL PROTECTED] wrote: how can migrate or upgrade my 6 sparse and whole root zones that are on a separate file system than my root disk if i just install a fresh copy of 08/07 instead of upgrading? Sounds like you need the update on attach feature[1] that doesn't yet exist. Jerry - any updates on this? 1. http://mail.opensolaris.org/pipermail/zones-discuss/2007-June/006785.html The approach I take as part of zone migration (that works with S10 3/05 and later bits...) is to recreate the zone using the existing zone configuration, then copy the bits that matter from the old zone to the new zone. Take a look at /etc/lu/synclist (global zone) as a good starting point for the files that matter. If you keep your application data separate from the OS data (separate file systems) this will be easy. If you mix the two, you will have some difficulties. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Patching a machine with local zones
On 9/6/07, Enda O'Connor ( Sun Micro Systems Ireland) [EMAIL PROTECTED] wrote: One other thing, make sure to run patchadd -a patchid-revision first, -a basically does a dryrun, boots any halted zones etc and does dependency checks. Hmmm, I've been looking for dryrun support. A quick look at the man page shows why I haven't found it yet. Is the fact that the -a option is not documented a bug or an indication that it is a private feature? I just need to know what to put in the bug report. if there are any issues with a zone not being bootable the output should clearly indicate this ( examine the output carefully! ), and must be Is any work being done on improving the output of patchadd? As it is today, the output is extremely tedious to read and worse to try to parse for automated checks. I've been silently gnawing on my tongue waiting for pdo.c to become available to see what can be done to improve it, but the wait is getting to be quite long. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Multiple Vlans on Zones
On 9/4/07, Chew Tian Hai [EMAIL PROTECTED] wrote: Hi, We have dedicated 3 Ce NIC ports on the global zone to be configure for 3 Zones on Multiple VLANS.We will be configured as IPMP link-based for each interface.We can set default gateway on one of the VLANs.How can I set the other 2 default gateway Vlans to communciate to other servers in the other subnet since the ZONES still get the route from the Global Zone? A search of the archives will show several messages with similar concerns. See, for example, http://mail.opensolaris.org/pipermail/zones-discuss/2006-October/005474.html. The short answer is that if you don't have an IP address on that subnet in the global zone, you will have to resort to hackery to get the default route added in the global zone after the zone's IP address is up. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones on zfs
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? -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Creating a Virtualization Community Group
On 8/7/07, Ellard Roush [EMAIL PROTECTED] wrote: Hi, There is so much discussion in these areas that it would be most undesirable to combine these 3 different areas. Combining communities does not mean that they all share the same mailing lists. zones-discuss, xen-discuss, et. al. would continue to exist as they do now. I think that what this would mean is... Brandz, Xen, and Zones would be three new projects in the Virtualization[1] community. The following web areas would move into project pages to make way for the new Virtualization Community page. This page may be useful as a place for newbies to figure out which of the various strategies are useful in different circumstances. http://opensolaris.org/os/community/brandz/ http://opensolaris.org/os/community/xen/ http://opensolaris.org/os/community/zones/ A new Logical Domains project would likely start in this community. There would likely be a virtualization-discuss[2] list as a catch all for those discussions that don't fit neatly into one of the project lists above. The contributors and core contributors of existing communities would be recognized as the same in the new community. I would only see this as substantial if there was ill-will between the various groups because core contributors could have -1 wars. I really, really, don't foresee that happening. I personally have nothing against the idea. Aside from giving a one-stop place to compare virtualization strategies (which could easily exist in another place) I'm not sure I see a whole lot of benefit. For now my vote is a +0.25. I don't think the constitution allows that, so I figure out if it is a 0 or +1 after a bit more discussion takes place. 1. I would prefer Server Virtualization - there's lots of other virtualization in Solaris that is not part of this community. 2. Or v12n-discuss to not chew up the entire subject line. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Creating a sparse root zone via a package's postinstall script
On 8/1/07, Fat Ted [EMAIL PROTECTED] wrote: ERROR: Unable to acquire zone administration lock for this system; please try again later ERROR: cannot create zone boot environment zoneadm: zone 'bose-zone': '/usr/lib/lu/lucreatezone' failed with exit code 94. You may be able to work around this problem by having the zone creation happen after the pkgadd completes. A bit of time delay, error checking, possibly a retry loop, and the use of at(1) or batch(1) may be of use. pkgrm would need to do similar tricks. I'm in no way saying this is a good thing to do. I am, however, a proponent of trying things that aren't in the book because that's when you tend to learn the most. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zonecfg question
On 8/1/07, Yanakiev, Vladimir [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] zonecfg -F -z labv490-01z5 delete zonecfg: illegal option -- F usage: zonecfg help zonecfg -z zone (interactive) zonecfg -z zone command zonecfg -z zone -f command-file [EMAIL PROTECTED] Try this: zonecfg -z labv490-01z5 delete -F -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] E20K VCS in non-global Zone
On 7/30/07, Kari, Sampath K [EMAIL PROTECTED] wrote: Thank you Mike. Please let me know which services (via rc or SMF) got affected by this. Mainly if they belong to OS or Infrastructure software or applications? * NFS If you have NFS mounts via /etc/vfstab or the automounter, the mounts may fail during zone boot because of DNS, NIS, LDAP lookups and/or actual mount requests getting no such route errors. During zone shutdown the IP address will get taken away before the zone shutdown begins, making it impossible for apps running in the zone to shutdown cleanly. There are other problems (bugs) in this area that may or may not be fixed in the version of Solaris you are running that will cause the zone shutdown to fail. This failure may require a reboot of the global zone to recover. * NIS, LDAP, etc. Name service lookups that may be required for applications to start may fail or behave differently. For example, if you are using NIS or LDAP for a name service for passwd, the equivalents of passwd, shadow, user_attr, prof_attr, etc. in the name service will be searched. Depending on the configuration of nsswitch.conf, initial startup may say I can't get to the network name service, so let's assume that files is sufficient. If you restart the app at some other time via svcadm restart (or access the account via su - user, login, etc.) you will likely be able to get to the shared name services and entries in there may make it so that various account attributes are different. * Application-specific There are likely many variants of this... Suppose you have an application server that connects to a database at startup. Further suppose various apps in the server may not be written well, the application server needs to be restarted whenever the database connection is lost (e.g. database bounced). When this app server starts up, it will likely (sometimes) fail to connect to the database. As such, you will have to restart the app server after VCS brings up the IP address. This is not a comprehensive list. It is just a sampling of the types of things that I ran into or could see as likely failure modes when trying to get VCS (and similar service groups in VAD) to work with zones. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] One zpool and multiple zones
On 7/25/07, Mikael Kjerrman [EMAIL PROTECTED] wrote: I'm sorry if this has been answered in the past (and quite frankly the search function does not work very well ;-) I typically just use google and include something like site:mail.opensolaris.org and possibly zones-discuss in the search terms. When I tried to use the jive interface I found it to be an overall unrewarding experience. Of course subscribing to a bunch of lists has its own drawbacks too. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 6/06, proc_priocntl and Oracle 10R3
On 6/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: No, you can't do that except by upgrading to a later Solaris 10 release. It seems to me that what is really needed is a fix for 4966416[1]. It looks to me as though the current rev of the zones patch[2] has this. Of course the dependency tree will require a bunch of other patches too. Why would an upgrade be needed? Mike [1] http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4966416. [2] http://sunsolve.sun.com/search/document.do?assetkey=1-21-122660-09-1 ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [install-discuss] updating a zone when attaching
On 6/4/07, James Carlson [EMAIL PROTECTED] wrote: 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? Does the equation change at all if relevant scripts were copied to /var/sadm/patch/patchid when the patch is installed? It would be the responsibility of patchadd (or related behind the scenes tool) to put the scripts there. Presumably a flag saying no scripts are required would be helpful to distinguish between systems that were installed before and after this mechanism was implemented. It would also be useful to be able to fix an existing system to set the aforementioned flags or copy the scripts into place. This could be done either through looking at the unapplied patches or through a web service that just provides the required scripts. A web service may be a lot of work for what should be a relatively short term problem. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [install-discuss] Re: [zones-discuss] updating a zone when attaching
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. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updating a zone when attaching
On 6/4/07, Ellis, Mike [EMAIL PROTECTED] wrote: I like your eaxample... Good way to go if you can't swing the zones over to some other server for import/attach/upgrade. In reality, this is how I think I would do this. How would you envision backing out of the newbe environment if (after doing the zoneimport +upgrade) you decide you want to back out and boot to the pre-lu root-environment? (You can't attach -u the luns for downgrade purposes can you? The zones would be seriously out of whack as a result of the attach/upgrade.) I guess if there WAS zfs in play, at least you could snapshot before attach-upgrading? Exactly. I left that detail out to encourage discussion. :) The whole attach+upgrade thing is a little scary anyway, some sort of backout will be needed... Indeed. As mike said, we're going to have zfs play in this space sooner or later, and its snapshot facilities can really help solve some serious issues here. With hundreds of zones in production today, it is feeling like later is already here. Worst case patching is well over 24 hours in single user mode. (I have developed my own workarounds to make each zone only add about 10 minutes to total outage time in my initial tests.) Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updating a zone when attaching
On 6/4/07, Jeff Victor [EMAIL PROTECTED] wrote: Wee Yeh Tan wrote: On 6/5/07, Mike Gerdts [EMAIL PROTECTED] wrote: With hundreds of zones in production today, it is feeling like later is already here. Worst case patching is well over 24 hours in single user mode. (I have developed my own workarounds to make each zone only add about 10 minutes to total outage time in my initial tests.) I'll be grateful if you can share that. Patching zones is extremely painful due to the downtime you mentioned. With S10 U4, Zulu will allow LU of zoned systems and minimize downtime to reboot time. My understanding this is not the case if using ZFS for zonepaths. But you can create ABE's - and patch them - even if you aren't upgrading. You could: 1) Create an ABE (with zones) - while apps are running on original BE 2) Patch the ABE (with zones) - while apps are running on original BE 3) Reboot into the ABE (with zones) 4) Fallback to the original BE if necessary Is this a S10U4 feature? How does this work with zfs? This would only be useful if the time to reboot is less than the time to patch. Does that method sound useful? Only if it offers some material improvement over zulu, which I understand does not support zfs. Please, as more work goes into live upgrade, release the bits that don't have legacy baggage. Even if it's not fully buildable, existing code with the relevant ARC cases could help tremendously in a clean room implementation. Having such a fundamental part of Solaris not being part of OpenSolaris is painful. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updating a zone when attaching
On 6/4/07, Wee Yeh Tan [EMAIL PROTECTED] wrote: On 6/5/07, Mike Gerdts [EMAIL PROTECTED] wrote: With hundreds of zones in production today, it is feeling like later is already here. Worst case patching is well over 24 hours in single user mode. (I have developed my own workarounds to make each zone only add about 10 minutes to total outage time in my initial tests.) I'll be grateful if you can share that. Patching zones is extremely painful due to the downtime you mentioned. The 10 minute estimate is based upon a server (V440, 36 GB disks I think) going from 118833-36 (February-ish) to 125100-06 (May) using the patches found in the recommended+security clusters along with a bunch of other patches that come along for various reasons. In a nutshell it involves ditching install_cluster from the recommended patch bundles and using patchadd -M `pwd` `cat patch_order`. This avoids bringing each zone up then back down for each patch. Additionally, it calculates dependencies once. In something much larger than a nutshell... It is not clear to me whether it is safe to do a one-shot patching with patchadd with current patch bundles due to the you must reboot now, really code added to 118833-36. For safety sake, I have split out 118833-36 and its prerequisites into a separate patch cluster. If patchadd is broken after installing the first patch bundle (due to lofs mount over pdo), it forces a reboot so that you can then install the rest of the patches later. Some would say that Sun Update Connection is my savior to all my patching woes. Unfortunately, if a patch is tagged as special instructions apply (or something like that) I still have to do a bunch of futzing around between my multiple reboots. Multiple reboots are bad enough. Futzing (hmm... futzing is a real word according the the firefox spell checker) around between them is overly burdensome. SUC needs to become live-upgrade aware to alleviate these problems. One thing to keep in mind is that as zones are patched, you may pay a per-zone copy (to /var/tmp in global zone) penalty if the patches are sitting on NFS. I don't think this exists otherwise, but I am not sure. I think that this is done because the patch needs to be lofs mounted into the zone while patching, but this will break if the source of the lofs mount is an NFS mounted directory in the global zone. For this reason, it seems to be advisable to have the patches on a local disk during patching. Some would argue that this is a best practice in any case. If local disk space concerns make the use of NFS a requirement, it may be worthwhile to explore mount -F tmpfs - /var/tmp prior to beginning patching. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] non-global / global networking without physical interfaces?
On 5/25/07, Steffen Weiberle [EMAIL PROTECTED] wrote: If your system does not have an interface, humm, good question. Even an VNI (not VNIC) requires a physical interface underneath. I imagine the same for a tunnel. It is possible to configure VNI to pass traffic between zones without a related physical interface. However, as soon as you try to communicate with a non-existent IP address (UDP in my test case) you can crash Nevada or hang the process in S10. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] What is the maximum number of local zone can I have?
On 5/15/07, storage-disk [EMAIL PROTECTED] wrote: Hope this is not a new thread. I just have a simple question. What is the maximum number of local zone can I have? Thanks. I thought that it was around 8000, but zone.h seems to indicate that MAX_ZONEID is . You will have to do other tuning to get to that large of a number. John Clingan http://blogs.sun.com/jclingan/ has experimented with this and has achieved hundreds of zones with rather modest[1] hardware. You will tend to run into other practical limits for long term maintenance (e.g. time to patch said system) before you run into problems with the system running a large number of zones. Mike [1] This assumes that you buy into the idea that a 4 processor system with 8GB of RAM is modest - I may be a bit spoiled. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Default RM controls for Containers?
On 5/10/07, Dan Price [EMAIL PROTECTED] wrote: I think fundamentally we hear from two camps: those who want to proportionally partition whatever resources are available, and those who want to see the system as virtual 512MB Ultra-2's or virtual 1GB, 1ghz PCs. The typical scenario I see is that an ISV gives a recommendation like V120 with 1 GB of RAM or better. It is then up to the end user to figure how big of a slice of a T2000 or x4600 that is. Using NDA information from Sun I can do this translation accurately enough for my needs. Each machine in my environment is capable of handling somewhere between 4 and several hundred Zone Power Units - ZPUs. It makes the communication of relative server compute power very easy among those familiar with the scheme used. Providing open access to this information across Sun's product line and opening up the computation methods to allow others to benchmark other systems would be very helpful. Perhaps in the future ISV's would say more meaningful things like 1 - 8 threads with at least 17 ZPUs and 6 GB RAM. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Setting up 2 Oracle databases in Solaris 10 (zones ?)
On 4/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: In the past, we had always allocated 2 different servers, as a recommendation from Oracle. We are now trying to see if it makes sense for us to get 1 server, say a v490 with 4 Dual Core processors with 16 Gb of RAM, to house these 2 databases. With zones, I know that we can setup different root disks, as I had done during training. While you can do this, you aren't going to get (for the purposes you are likely stating) any more isolation that you could with processor sets, using different disks, etc. with Solaris 9 on a V490. Perhaps you should be looking at either two systems or looking at an M4000 with two domains. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone hung in shutting_down status
On 4/21/07, Sean Sprague [EMAIL PROTECTED] wrote: Which process did you try to kill? 1919 or 1956? Normally killing 1919 would cause 1956 to go away. Is 1919 in some state that it can't be killed? I guess that 1956 could be preap'd as well. I am more used to seeing defunct processes owned by init... Regards... Sean. I would also expect that 1956 could be preap'd. However, in order for the zone to go down 1919 also needs to go away. Having 1956's parent (1919) go away could change things enough that 1919 is automatically reaped the normal way and the zone can go down. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones on NFS
On 4/17/07, Matty [EMAIL PROTECTED] wrote: Howdy, Ben brought up the idea of running zones on NFS file systems a few months back: http://www.opensolaris.org/jive/thread.jspa?messageID=81240#81240 Have the zones team given any consideration to implementing a supported straight forward solution for this? This capability would have come in handy this week at my job, and it sure would be a useful feature to have. This is an often requested feature that I would be very interested in as well. Is there a discussion somewhere of what the real stumbling blocks here are? It seems as though it comes down to... zonepath needs to be be mountable rw from the global zone. zonepath/dev needs to be rw,devices mountable from the global zone, then lofs mounted into the non-global zone. Yuck. zonepath/root needs to be rw mountable in the global zone (at least during install and uninstall) and non-global zone during normal operation. All of this seems rather straight-forward, except for the lofs mount. This could be worked around by rather than having a normal dev directory, a file dev.ufs is created. As the zone is being mounted, dev.ufs could be lofi mounted at zonepath/dev. At this point it is UFS, not NFS and can be lofs mounted into the non-global zone. Surely I am missing something else. What is it? Any interesting complications with patching and/or live upgrade? Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: lu* commands in zone install WAS: [install-discuss] Flash Archives vs backup
[Removed OP from reply, added zones-discuss, updated subject] On 3/29/07, Dave Miner [EMAIL PROTECTED] wrote: Are there any parts of flash that can be opened? Any interface specs, ARC cases, etc? These would be great improvements that the community could work on. Flash has some unresolved issues in opening the code. However, now that you mention it, the specs and ARC cases actually should be clean, such that you and other interested parties could work on a clean-room version. I'll look into that a bit and see what I can sort out. Cool - that would be extremely helpful. Initially I was resigned to just wait for the next generation of the related technologies to come out. Then I noticed that there were lots of lu* commands used during zone creation. With zone creation being such a key part of life with Solaris, it really seems as though this needs to be open for the community to work with it. Yeah, that piece is somewhat problematic, though the reliance on LU there is mostly for infrastructure, and not much on the actual LU functionality. The plan kicking around in my head was to break the connection by cutting zone installation over to using essentially the same code as zone cloning; there's a fair amount of similarity already, anyway. Sounds good on the surface, but some details suggest a devil is lurking somewhere nearby. How does this play with zones that use inherit-pkg-dir? How about files that are added but not part of a package? When a zone is cloned, there is the implication that you want all of the customizations (sans sysidcfg stuff) to come over as well. If the global zone is cloned, this is likely not the case and as such more care should be taken to only take what is part of the package database. That puts us in a situation where we are doing something like reading /var/sadm/install/contents filtering out all of the files/dirs in an inherit-pkg-dir, removing /dev entries, etc. to generate a list of files to give to cpio. I suspect this is pretty much what ludo/lucreatezone is already doing. An interesting question comes up when ZFS root comes about. Could the global zone be cloned to form full-root non-global zones? If /usr, /lib, /platform and /sbin are separate zfs file systems in the global zone, could the global zone be cloned to form sparse non-global zones? Arguably the value of sparse zones goes down substantially when ZFS clones are involved, but it does provide interesting food for thought. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Any plans for a Vmotion-like Zone migration tool?
On 3/20/07, Nils Nieuwejaar [EMAIL PROTECTED] wrote: When migrating a zone, you would have to find some way to extricate the kernel state for just that some subset of a system's processes, devices, network connections, etc. - then insert that state into the middle of a kernel already running on another machine. To put it mildly, that would be hard. OpenVZ (similar to zones, from my understanding) can do this on Linux. http://wiki.openvz.org/Checkpointing_and_live_migration http://openvz.org/news/announcements/openvz-sparc-20070102 If you want live migration on Solaris, and you are using x86/x64 machines, then you should be looking at Xen. http://www.opensolaris.org/os/community/xen Does running on sun4v LDOMs help provide a path to this? To someone that hasn't really looked at how LDOMs get their initial state, it seems as though this would be quite doable. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] strange: I can't login to host , but I can login its zone, same ip subnet
On 3/11/07, steeles [EMAIL PROTECTED] wrote: Isn't it weird !!! Host sun server has the same IP subnet as its zone, and point to same gateway. My machine is on another subnet, and has been routed to zone subnet. On this machine, what do the following say? route get ip or hostname of global zone route get ip or hostname of non-global zone Weird thing is that I can telnet/ssh to its zone, but I can't telnet/ssh to host!!! Can you ping it? If you can ping it but not log in, perhaps you have rules set in /etc/hosts.allow or /etc/hosts.deny on the global zone that are denying access to other subnets. When using the test above, be consistent in the use of hostnames or IP addresses. That is, don't test route get with hostname but ping by IP address. This will just compound your confusion in the event that you have bad DNS entries. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Several zonepaths on a single slice
On 2/7/07, Paul Davis [EMAIL PROTECTED] wrote: For this config, HW RAID is a non-negotiable requirement and SVM cannot be used to mirror the internal drives. It comes from a historic aversion toward the old SDS (Disksuite Suite). You can use soft partitions on top of hardware RAID. Suppose your hardware RAID'd disk is visible to the OS as c1t0d0 and you have slices 6 (many gigabytes) and 7 (100MB) available: # Create the metadatabases metadb -a -c 3 -f c1t0d0s7 # Create 30 soft partitions, 500 MB each i=1000; while [ $i -lt 1030 ] ; do metainit d$i -p c1t0d0s6 500m newfs /dev/md/rdsk/d$i i=`expr $i + 1` done -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Several zonepaths on a single slice
On 2/6/07, Paul Davis [EMAIL PROTECTED] wrote: SVM with soft partitions is not an option and there will be no SAN attached storage to mount small slices for zonepaths. Other than the obvious issue of zones sharing a single partition (disk slice), are there any other concerns with this configuration? Just out of curiosity, why are soft partitions not an option? Mike ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Capped memory observability
I just got a chance to start playing with the capped memory resource controls in build 56. At first blush, this looks to be *very* good stuff. My initial testing included some very basic single process memory hog tests and multiple process mmap(..., MAP_SHARED,...) tests. In each case, the limits kicked in as I expected, and prstat -Z running from the global zone gave what appeared to be accurate information. Great job! One of the effects of setting capped-memory resource control for swap is that the size of /tmp is also limited. Unlike when a tmpfs size limit is set with the size=... mount option, df /tmp does not display a value that is reflective of the limits that are put in place. Similarly, vmstat and swap -l running inside the zone give no indication that there is a cap smaller than the system-wide limits. Am I missing something here? I do see that some of the values I am looking for are available through kstat (thank you!). Is there some more user-friendly tool (already or coming) to use inside the zone? Oh, and the question that everyone at work will ask when I tell them about this - when will it find its way into Solaris? :) Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Failover IP-Address in Zone
On 12/7/06, Zoram Thanga [EMAIL PROTECTED] wrote: Mika Borner wrote: Are you using Sun Cluster by any chance? If not, you can accomplish what Unfortunatly Sun Cluster is not an option yet. Ahh...that's too bad :) I'm looking for a way to achieve this with standard OS tools. In that case you'll need to have something running in the global zone control the plumbing and unplumbing of the IP address in the NGZ. That is, you can't have the failover IP address be a part of the zones' configuration. Is there an existing RFE to fix this? I have been meaning to file one for quite some time but just haven't gotten around to it. The way I work around this is I have a tool used for managing zones (similar in many respects to the recently announced zonemgr) that has enable and disable subcommands. Among other things, the disable subcommand comments network interfaces. That is, it adds an attribute (or multiple) that includes the information about the interface and removes the net resource(s). I then have an uncomment function that reverses the work done by the comment function. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone installation problem.
On 12/6/06, Jerry Jelinek [EMAIL PROTECTED] wrote: lofs mount. Why are you using inherited-pkg-dirs for some of the /opt subdirectories? Is there a reason you don't want to just use lofs mounts for those too? In my environment, I have made inherited /opt by default for all new zones created. This has caused problems here and there when zones need to install software in /opt (or mount existing NFS/SAN file systems there). The workaround has been one of the following: 1) Create the mount point in the global zone (yuck) 2) Rebuild the zone without inherited /opt (yuck) As I look forward to possibly including blastwave in standard images, I am thinking that Chris' approach of inherit-pkg-dir of /opt/csw (and any other kinda big directories in /opt) is the more proper way to go. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] How to get global zone information from non-global zone
On 11/25/06, Wee Yeh Tan [EMAIL PROTECTED] wrote: Hi Mike, Can you share why you want the NGZ to know about the GZ? There is little technical reason that most people will need to know. However, due to a variety of reasons (integration with monitoring, asset management, some notion that knowing the real box name will make things better, etc.) many non-root users feel that they need to know. Giving people this visibility is easy enough and is of little consequence in my environment. The key reason that I would need to know is if I am looking into a performance problem on the machine and I need to do something from the global zone (run dtrace, snoop, adjust resource allocations). Taking a quick look at /etc/hardwarename can be useful to allow me to avoid looking at some other external cross-reference that would likely be maintained manually (and therefore likely to degrade over time). The key reason that I want to provide it is so that our monitoring group can track any migrations of zones between servers and correlate that movement to performance or availability changes. For example, if a zone migrates from a V240 to a T2000, it would be really nice to have people not get too excited about going from 80% CPU utilization down to 15% utilization or suddenly having a few GB of RAM free. Assuming anyone is watching for such a situation, it would be normally be indicative of a portion of the application having crashed. The reason I ask is that we are already doing zones but we will be scaling up the effort quite tremendously and I want to get my bases covered. The key thing that I am looking for is a way to handle lots of zones efficiently as almost every server has somewhere between 1 and 30 of them. For example, I am looking at various clustering products to provide free failover so long as a few basic rules are followed. Of course, my ulterior motive is that I am looking for a management framework that will allow me to say vacate that server - it needs to go back to the lessor. A cluster that can scale to hundreds of machines and thousands of resources would be ideal. If it can handle this number of resources and the aspects of site failover in the event of a disaster, I would be extremely happy. I currently use our network operations centre software to track which zone is which but the zone owners do not really know which hardware they are in. I personally have not seen any issues whether the zone owners are in the know so I will let the zone owners know if they ask -- but so far, no one ever did. As my users get more comfortable with zones, they tend to demand this information less. Keeping users within their comfort zones has been a big part of introducing the new features that come with Solaris 10. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On 10/27/06, Dan Price [EMAIL PROTECTED] wrote: A (large) customer recently asked me to implement a feature whereby they could monitor zone activity via syslog. The motivation is that for this customer, any zone state change not during maintenance windows is a cause for alarm. I've had a similar request in my organization as a means of helping to identify which physical machine a zone is on by viewing centralized syslog data. Arguably, my use case is of limited value unless zones are rebooting all the time (hence no RFE for my use case). So here are my questions: - Do you think this is useful? Yes. - Do you think the log level (Info) is right? daemon.info is *not* logged by default, whereas notice is. (So basically: do you want these messages in /var/adm/messages by default, or not?) Info is OK for normal state transitions. If a reboot fails and it ends up installed rather than running, I would expect that is an daemon.err (or is it daemon.error...) because something went wrong. - Do you think the facility of 'daemon' is OK? With Solaris syslog you can't AFAIK route messages based on the value of 'program' (which in this case is 'zoneadmd'). There's a good RFE! :) 'daemon' works for me. - Any comment about whether the info provided is sufficient? For example, when a zone reboots it goes through numerous state transitions, but I chose to express this as one big transition-- does that work for everyone? Perhaps if zoneadmd is running in a debug or verbose mode (selected by zonecfg(1M) property or /etc/default/zones?) then it could log detailed state transition info to daemon.debug. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On 10/27/06, Dan Price [EMAIL PROTECTED] wrote: As for GPEC, that's what our existing C api is based upon. Take a look at zonecfg_notify_*() in libzonecfg. It's a real horror show but it does solve the get the state and then subscribe to future changes and don't miss anything in between problem. We could potentially build this up into some new command like 'zoneadm monitor' but I don't necessarily see that as being in conflict with doing something in the short term with syslog-- and 'zoneadm monitor' can't be consumed by upper level monitoring agents without a lot of work by lots of What if zoneadm monitor -a (all zones) had the ability to spit syslog entries and/or SNMP traps? Perhaps if the SNMP route is taken, a subagent to snmpd(1M) would be the right approach. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones and VLAN tagging.
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. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] question about zones status check. thanks
On 8/17/06, Chun-Huan Freesia Shen [EMAIL PROTECTED] wrote: Hi experts, This is chunhuan from SC. I have a question to consult you. How can I confirm that the zones (global/non-global) status is ok or not through explorer file gathered by version 5.5 ? I would expect that the answer to whether a zone is ok is just as subjective as whether a Solaris 9 installation is ok. Even though its official state of a zone may be running (or a S9 box is in run-level 3) that doesn't mean that someone hasn't removed /dev/null, put in a trojan libc, had file systems that failed to mount, or had services that didn't start. As such, I would argue that (almost) all of the checks that would be done to determine if the global zone on Solaris 10 is ok should also be done in a local zone. That is, look for missing patches, be sure that svcs -x is clean, be sure that ~root/.rhosts doesn't say + +, etc. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones, clusters, and maintainability
putting the hostname in zonecfg - it makes it so much more clear what you are intending. Zones start after the name service and this supported configuration works just fine.) The VCS resource would then perform the following when onlining the zone: ifconfig ipge0 addif zone1 zone zone1 netmask + broadcast + up The key thing to consider here is that outbound connections from this zone may be coming from the zone1.example.com or server1-zone1.example.com address. Plan firewall, TCP wrappers, etc. rules accordingly. This configuration would allow you to manually boot each zone on each machine with no worries of IP conflicts (can't wait for zoneadm boot -s nonet). As an added safeguard, you probably want VCS to be responsible for starting the apps within the zones, rather than using SMF or rc scripts within the zone. This will ensure that an errant zoneadm boot doesn't cause multiple instances of the application to be up at the same time. Now, in the event that you don't want or need network connectivity while the zone is not active on the node, you could configure the zone without an IP address and use the ifconfig command above (through a cluster resource) to bring the network up. This would likely offer added split brain protection and get rid of the worries about firewall, tcp wrappers, etc. mentioned above. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
