Re: [zones-discuss] Zone Resource Management Issue.
Hello Ketan, On Dec 13, 2010, at 8:35 AM, Ketan wrote: One of our box T5440 has been configured with 5 zones and following resource management parameters has been applied to 1 zone say zone1 zone.max-shm-memory 4G zone.max-locked-memory 4G so if i want to check the zone.max-locked-memory what would be the best way as if i try to use prstat -Z the RSS column shows 10G being used the by the zone1 though max-locked-memory is set to 4G only RSS memory does not mean that it is locked just that it is present in memory, with your setting you could have any amount of non-locked, non-share memory. I would have a look at the larger processes with using pmap with the x option, looking at the locked column and sizes. If you want to limit the use of physical memory for the zone, try using rcapd (it does not limit the usage but tries to enforce it asynchronously by pushing out pages to disk). Regards Henrik http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Resource Management Issue.
On 13 dec 2010, at 10:50, Ketan vibhu...@gmail.com wrote: Ok got it .. but still if i want to check what's current usage by a whole zone/project for locked-memory what would be the best way .. i 'm using kstat -c project_caps -n 'lockedmem*' That should work, I have used it without problem and the zonestat script by Jeff also uses this. but with this command the usage is very less as reported by the application user which says that db is doin very slow and they are getting memory related errors module: capsinstance: 0 name: lockedmem_project_ class:project_caps usage 2488147563 value 36335423324 Are you saying the zone has more memory locked than kstat shows? Have you verified that the memory is in fact locked by using pmap as I suggested earlier? Have you tried to enable logging for the resource controls with rctladm to see which limits are limiting the database? Regards Henrik http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Zones and storage pools
Hi all, I would like you take on this for a large zone installation. I am going to create zones on zpools with a pool for the zoneroot and another pool for for application data, the second pool can differ in layout, disk system and properties and can easily be separated from the zone and moved to another zone, global or local. Previously we have defined the filesystems for the application data specifically in the zone config for every filesystem, but to leverage some of the ZFS power to the users or have simpler zone configuration I would like to dedicate the pool to the zone. I would ideally like to do two things: 1. Have all filesystem configuration for the zone in the pool as we have with the global zone, only specify the pool(s) for the zone and all filesystems would be mounted inside the zone, this without giving away all control to the local zone. 2. Delegate ZFS operations to the zone so that privileged users only can perform a subset of ZFS operations from inside the zone (or deligate to local users), something like: (zfs allow -z zone01snapshot,mount,rollback zone01_pool01). 3. Be able to do all administration of the pool from inside the global zone even if a dataset is exported to a pool. Today I am for example unable to create a dataset to a pool owned by a zone and set the mountpoint (which should be relative to the zone): Today I can give away a pool to a zone but it will have control over without the ability to restrict it and I would the not be able to create new datasets for the pool with alternate mountpoints without going through zlogin. As an RFE I would also like to see an option to boot zones into single-user mode even if filesystems for pools besides zoneroot are unavalable. Does anyone have similar setup? How do you handle datasets for local zones? All input is appreciated. Thanks Henrik http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones and storage pools
On Nov 3, 2010, at 1:22 AM, Ian Collins wrote: On Nov 3, 2010, at 12:06 AM, Ian Collins wrote: On 11/ 3/10 11:56 AM, Henrik Johansson wrote: I would ideally like to do two things: 1. Have all filesystem configuration for the zone in the pool as we have with the global zone, only specify the pool(s) for the zone and all filesystems would be mounted inside the zone, this without giving away all control to the local zone. Why don't you want the zones to be able to manage their own filesystems? One of the main reasons for zoned filesystems is to allow filesystems to have mount points relative to the zone's root filesystem. It would depend on what kind of users we have in the zone and how the zone is used, for some it would be fine to give away all control for other we would like to keep them from deleting snapshots/datasets or changing properties like quota. If the zones is compromised or if a privileged users does something nasty we would like to be able to rollback it from the global zone only. I guess you can solve those two by setting the quota on the filesystem containing the zoned filesystem and replicating snapshots. I guess replication would solve the problem but with lots of overhead. The quota problem should work if we dedicated a dataset below the pool itself to the zone as it's root dataset. But for some zones we would really like to limit all zfs operations such as rename, destroy and create. The solution to this would be to make sure there are no users inside the zone with such privileges, as long as the zone is not compromised it would be fine. We would like the administrative gains of having all filesystem configuration inside the pool but for some customers we handle their data needs even if they have privileged equal to root inside the zone so we would like to restrict what they can do. Would a quota be enough? That could help but the root scenario would break the privileges as described above. I must look into what we can do with our roles for ZFS management inside the zone. Changing properties for the zone could also affect the global zone and other zones on the same global zone, lets say you would enable gzip-9 compression and write lots of data, that would bypass all resource limits for the zone and drastically change the amount of cycles required for zones datasets . Even worse for zones in Solaris.Next you could enable deduplication which could eat the metadata part of the ARC. This would decrease the amount of separation provided by zones with resource management. I can see those being a problem if the cycles consumed by compression are not assigned to the zone (I'm not sure if they are or not), otherwise a zone cpu-cap would protect the rest of the system. As for dedup, don't enable it on the zone dataset pool! The zone is not accounted for the resources consumed by ZFS so that could be a problem. I don't and won't assign gzip compression or deduplication to any datasets, but a privileged user in the zone could do just that. Henrik http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] vxfs in non-global zone
On 17 mar 2010, at 04.12, Derek McEachern derekmceach...@gmail.com wrote: Thanks for the responses. We don't plan on running the zone root on vxfs, it will be on ufs. The VRTSvfxs package installs with parameters SUNW_PKG_ALLZONES='true' SUNW_PKG_HOLLOW='true' SUNW_PKG_THISZONE='false' so package content is not delivered to the zone just the package information so it appears to be installed. I think we are going to experiment with mounting the vxfs into the zone from the global. This works well as said earlier, i'we worked with sites that has hundereds of zones using vxfs by loopback mounts. Henrik http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] vxfs in non-global zone
I am away from home and om mobie device so i'll make it short. This work fine if you don't ever put the zoneroot on vxfs, if you do you will not be able to use all upgrade options and the Veritas supplied scripts for live upgrade only works with a vanilla install (no separate LUN for zones etc) Someone mentioned that not all packages was present in the local zone, I think that most of the VRTS packages (or to many at least) has PKG_ALLZONES set to to, so they must be installed on all zones(to have a supported system) I might be off target, it's late and I'm not supposed to do this on my vaccation;) Henrik http://sparcv9.blogspot.com___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Virtualization performance
Hi all, I read this blog posting, the author switched from VMWare to BSD Jails and saw drastic performance increment. We known for long that Solaris zones which are similar to Jails have very little overhead to other solutions, but the trend seems to be towards VMWare as a magic fits- all solution for all X86 virtualization. Has anyone similar experiences to share with zones? I've always advocated zones if the workloads fits the separation it provides, and pointed out that VMWare are probably not the best solution for I/O intensive loads. But I have myself not used any hypervisor based solution for systems with heavy workloads. http://www.playingwithwire.com/2009/06/virtual-failure-yippiemove-switches-from-vmware-to-freebsd-jails/ Henrik Johansson http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zonestat v1.4 Available
Nice work Jeff! Some thoughts: Would not 1024 be bettet suited than 1000 for shorten? Currently if I set a swap capping with zonecfg to 256G it is displayed as 275G in zonestat. It would be nice to check for patch 127127-11, 137137-09 etc instead of looking at /etc/release since the system could have been patched instead of upgraded. Regards Henrik http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Moving zones between different sparc architecture
Hello there, On Feb 5, 2009, at 9:36 PM, pol.barthel...@sun.com wrote: Hello, It is supported to move zones from a sun4u to a sun4v or vice-versa ? Update on attach deals with this, it was integrated in snv_82, but if you want a supported version you probably want to use Solaris 10 instead, it was included in 10/08. Regards Henrik Johansson http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Does update on attach add information from the new systems kernel patch ?
Geoff and Jerry, On Feb 4, 2009, at 2:17 AM, Geoff Shipman wrote: Jerry, I received update they did not use a force option to the attach just the -u. They noted that no log file was created in the /var/sadm/system/logs directory of the NGZ. This attach was stymied originally by a Veritas package VRTSat that had patch 117499-02 with garbage characters in the obsoletes field of the pkginfo file. Once they followed Symantecs instructions on removal of the patch and access a clean version from the Symantec ftp site the attach went OK, allowing the zoneadm attach to recreate the SUNWdetach information. The NGZ still shows garbage in the pkginfo information for VRTSat from the showrev -p data and the kernel patch 13-01 is not listed in the showrev output. We have had some issues with the damaged VRTSat package, the fixed version of the same version of the patch together with the instructions did not solve the whole problem for us when using it with zones. If I remember correctly this fix did in fact damage the package database, or at least make it inconsistent with the files present on the system. The solution was to remove the whole VRTSat package, reapply the package and then apply the working version on the patch version directly without applying the damaged version first. The pkgadd procedure would complain regarding already present or missing files but after this we ended up with a consistent package database again. It's late here in Sweden but i can give you the exact information on what I experienced and how it was solved tomorrow morning if it's of any interest. Regards Henrik Johansson http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
On 6 nov 2008, at 15.16, Jerry Jelinek [EMAIL PROTECTED] wrote: Henrik Johansson wrote: The easiest way would probably be to identify packages that are not to be updated, in my experience packages do not differ that much between local zones in production environments, but that is only based on the system I have worked with. I always keep zones as similar as possible, but full zones still leaves the possibility to make some changes to the packages and patches in case its necessary. Unfortunately we have no way to know which pkgs you deliberately want to be different between the global and non-global zone and which you want to be in sync. Thats why a list where the user could control that would be needed. Yes, what I ment was that the operator should identify these packages. So what we would get is something like an upgrade but with optional control of packages that do not need to be in sync between the zones. Henrik http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Update on attach and upgrades
Hi all, Some thoughts regarding update on attach, and why I don't think it will be as useful as it could be. Perhaps Jerry or someone could enlighten me or give me some feedback. This mainly applies to whole root zones, since they do not have any inherited package directories. The update to the local zone only updates packages that have the SUNW_PKG_ALL_ZONES set to true or are in a package inherited directory. This means it is not similar to an upgrade performed by the installation system or live upgrade. One useful scenario for update on attach was to have one node upgraded without zones and then migrate the zone one after the other to the upgraded host and have them upgraded on attach (quite useful when you have 20+ zones in one machine). This will leave the zone in a supported state, however the zone will have a mix of packages from the old and new machine, depending on if they are required to be consistent between all zones. Since many installations using local zones keeps the local zones in sync with the global zone, this is not an optimal situation. If we use update on attach today, that zone will be different from the other zones created after the upgrade or zones that have been upgraded at the same time as the global zone. In the case of one machine being upgraded to a later update of Solaris, that will be quite a few packages with different versions. This is not an acceptable solution for many environments. Shouldn't it be possible to implement the functionality to update all packages that have newer versions in the global zone? That could perhaps be an additional flag to attach -u, maybe -a? I know packages could be of different version on purpose, but then this option should not be used, or implement an option to supply a list of packages to upgrade or leave alone. Regards Henrik http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
On Nov 6, 2008, at 12:47 AM, Jerry Jelinek wrote: I think that just updating the non-global zone for every pkg that is installed in the global is probably not quite right since you want to be able to have different software in different zones, including the global zone. Upgrade is already used today for non-global zones, this would just be something similar but individually per zone, an it would be an option to the update, default would still be the current update. If you upgrade today, you all your packages will be upgraded in the locale zones. It would be possible to leverage the solution we have today so that the list of pkgs that must be in-sync was augmented by some sort of user input. For example, as you suggested, one idea might be for you to set up a file containing a list of additional pkgs that should be in-sync. You could pass that to the attach command and those additional pkgs would be synced up. That would be fairly simple to do but it would require the user to figure out what pkgs to put in the list. You'd have to look at some released version of Solaris and decide which pkgs to add. This might be a bit of a maintenance issue since the set of pkgs changes over time and over each update release. The easiest way would probably be to identify packages that are not to be updated, in my experience packages do not differ that much between local zones in production environments, but that is only based on the system I have worked with. I always keep zones as similar as possible, but full zones still leaves the possibility to make some changes to the packages and patches in case its necessary. If this seems like something people are interested in, I'd like to hear more comments and we could refine a proposal. I'll then file an RFE and work up an ARC proposal. I know my employer would greatly appreciate something like this, it would make life easier with hundreds of zones, and again, to be able to mimic the upgrade behavior would be useful. When i first heard that update on attach i saw the possibility to more easily manage upgrades in our environment, but the current implementation does not help us. ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] S10U6 zone features
Any word if we will get any of these features/fix in S10U6, it would make life with zones quite a bit easier... Zone update on attach (PSARC/2007/621) Attach/dettach between sun4u and sun4v (6480464) Vanity naming (PSARC 2006/499) 6637869 zone attach doesn't handle obsolete patches correctly Regards Henrik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Installing a zone with JET
On May 27, 2008, at 11:54 PM, Crambit Team wrote: Hi, I meant to boot over the net a zonelikne boot net - install but you can't because you don't have OBP at that level Must be a flag into the zonecfg command or zoneadm. Zones are not separate Solaris instances, they are created from, and depends on an already installed instance of Solaris. Installing over a network makes no sense for a zone (in S10). What are you trying to do? Regards Henrik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Installing a zone with JET
Hello Team! On May 25, 2008, at 5:31 PM, Crambit Team wrote: Hi all, does anyone know how to jumpstart a new zone over net? Is there a kind of flag to set when you create a zone? JetZONES should handle zone related tasks in Jet, it is included in the Jet package available on sun.com, but there seems to be a later version available also: http://tech.groups.yahoo.com/group/JETJumpStart/message/1956 Regards Henrik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] LDoms
Hello Sanjay, On Apr 16, 2008, at 11:57 PM, Sanjay Akula wrote: Can any one tell me how LDoms works? Does this is an independent OS on each zones or it is dependent on Global zone? I'm new to LDoms. LDOMS is not related to the zones other that that it is another way of virtualization in a Solaris environment. Every LDOM has its own Solaris instance with separate kernels which in turn can contain zones. LDOMs are independent OS-instances as long as you are not using I/O-domains, in that case all LDOMS depends on a single instance of Solaris, but they can be patched individually. Here is a somewhat outdate blueprint: http://www.sun.com/blueprints/0207/820-0832.pdf Regards Henrik ___ zones-discuss mailing list zones-discuss@opensolaris.org
