Re: [zones-discuss] Zone Resource Management Issue.
On 13 dec 2010, at 10:50, Ketan 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
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] 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] Zones and storage pools
Hello Ian, Thanks four your answer, more below. 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. 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. 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. 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] vxfs in non-global zone
On 17 mar 2010, at 04.12, Derek McEachern 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] Deduplicated zones
Hi all, If anyone is interested or have comments. I did a very quick test with zones on a deduped zpool and the footprint seems quite low, a little over 10MB per zone after the initial for OSOL default installed zone. http://sparcv9.blogspot.com/2009/11/dedupliation-with-zones.html (I know the spelling is wrong in the URL, not trivial to change without making a new post thought) Regards Henrik http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] NFS zones via file based zpools or lofi/loopback
Hello Michael, On Aug 19, 2009, at 7:17 PM, Michael Barrett wrote: Say you create a zpool based on a file that lives on a NFS mount. Then you mount that zpool to a local mount point and give it to your zone to live on. I'm assuming that under the covers this is just another version of this loopback method: http://blogs.sun.com/jph/entry/containers_on_nfs Is there anyone out there running like this? Any performance issues that jumped out at you? Since using files as backing store for a pool is not recommended, putting them on NFS will probably not make things better. It will only be as reliable as the remote filesystem and NFS implementation together. People have lost their pools in far less complex configurations, talk to the ZFS people but i doubt they will approve. I would feel more safe with UFS if I where to put a filesystem on files or perhaps iSCSI: http://blogs.sun.com/JeffV/entry/zoit_solaris_zones_on_iscsi Regards 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
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] 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] Can I configure my zones on a ZFS filesystem?
On Jun 29, 2008, at 10:57 AM, Enda O'Connor wrote: > Hi > When was this, or to be precise what rev of patch utils was > installed,119254/11955 SPARC/x86. > > Patching zones on zfs is supported at this point. > Did you report this, what errors did you see etc. > > The original doc mentioned patch and upgrade, most recent mentions > upgrade only.as not being supported. > > If you install 119254/119255 currently on sunsolve, patching zones on > zfs will work, or if it doesn't then you need to report it, as it's > a bug. > Enda > Elizabeth Schwartz wrote: >> It is NOT resolved in Solaris 10 u3, although the patch documentation >> does imply otherwise. . I built some zones on zfs root paths under u3 >> and when I tried to install the 10_Recommended patch cluster, it >> bombed out at patch 120011-14. I ended up having to blow away all the >> zones, patch, and rebuild. >> >> Note that the original documentation only said that building zones >> with zfs zonepath would cause a problem with *upgrade*; it now talks >> about upgrade and *patching*. (Solaris patching seems to do more >> upgrading than it once did...) 120011-14 is a deferred-activation patch, they did not work on ZFS before 119254-46 (6581814), i've had the same problem. As Enda said, it will probably work with the latest version of this patch. I've look at the latest recommended cluster, 119254-53 is patch no 14 in the patch_order file, and 120011-14 is patch no 30, do you have the latest recommended cluster? Regards Henrik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10U6 zone features
On Jun 25, 2008, at 2:04 PM, James Carlson wrote: > > If you need information on S10 updates, you should contact your local > support folks. S10 updates aren't OpenSolaris, so there's no reason > to discuss their schedules or content here, and there's no necessary > relationship between features that get integrated into Nevada and ones > that end up in any particular update. > > I didn't look at the others, but the one networking (not zones) > feature you list there -- vanity naming (CR 6577618) -- doesn't appear > to have an MR entry for S10, so I would have to guess that no backport > is in progress, at least right now. > > The way a backport often ends up happening is that a contract customer > for one of those older supported releases makes a formal request > through Sun's support group. That doesn't happen on opensolaris.org. I'd just wanted the information on U6, it's a bit to late for a formal request, but i'll do that next time. I'd agree that this was not the right forum I concentrated on zones-discuss part of the address. But you people who know all this read this list ;) Vanity naming is not a zone feature, the reason I mentioned it is that it wold be a nice feature when migrating zones between machines with different NIC:s. Many thanks to all of you who answered anyway! Regards Henrik ___ 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
