Tags: area, d101, dsk, operating, own, rejected, sap, setting, software, solaris, space, swap, system, unfortunately, zone, zones

Zones and Swap space

On Software » Solaris Operating System

4,753 words with 7 Comments; publish: Wed, 14 Nov 2007 01:26:00 GMT; (40046.88, « »)

Hi,setting up several zones for SAP i'm trying to give each zone it's own swap area. Unfortunately "swap -a /dev/md/dsk/d101" is rejected with "not owner" error messages on the local zone. Is it possibly to define dedicated swap area for local zones ? How to do ?Thx.

All Comments

Leave a comment...

  • 7 Comments

    • Hi Wolfgang,

      seems as if adding swapspace for each zone seperatedly is not supported, I'll get this error when I try to add a swapfile (not swapdevice) in a non-global zone:

      "/swapfile" is not valid for swapping.

      It must be a block device or a regular file with the

      "save user text on execution" bit set.

      Whereas the same commands for creation of /swapfile and adding the swapfile work in the global zone.

      Have you thought about adding all the swapdevices in the global zone and using resource management to limit memory/swap usage? I don't know if this will work.

      #1; Thu, 05 Jul 2007 20:20:00 GMT

    • Until the ability to create per-zone swap areas is implemented, I'm looking for a way to limit the impact of having multiple zones share the same swap area. I'm particularly interested in limiting the potential impact of having an application within a non-global zone filling swap by writing to /tmp. So far, I've looked at using the "size=" mount option to limit the size of a non-global zone's tmpfs file system, and I've also looked at setting up a non-global zone's /tmp directory to be mounted on a separate disk partition using the following zonecfg entries and removing the "swap /tmp" entry from the non-global zone's vfstab file:

      dir: /tmp

      special:/dev/dsk/c#t#d#s#

      raw:/dev/rdsk/c#t#d#s#

      type: ufs

      One problem with both of these methods is that they could be reversed by the non-global zone's administrator, or someone else who was able to obtain the non-global zone's root password.

      Is anyone aware of a way that either of these methods could be implemented so that they couldn't be circumvented by someone who has the non-global zone's root password? Is there some other method that could be used as a workaround?

      I'm also interested in knowing how the vfstab file for non-global zones are created...are they created or copied from a template or copied from the global zone's vfstab file and edited?

      Thanks,

      Carolyn

      #2; Thu, 05 Jul 2007 20:20:00 GMT

    • I think a non global zone's vfstab is created when the zone is configured.

      I found a way to set it read only, even for the root user of the non global zone. With this, you can ensure that the zone's admin won't mess with the swap device.

      1. create a vfstab file for the local zone, and put it outside the zone's path

      2. replace the local zone's vfstab file with a directory named vfstab.

      3. with zonecfg, add a new file system to the zone. The directory is /etc/vfstab, the special is the absolute path of the file created in step 1, the type is "lofs", and the options is "ro".

      Then boot the local zone, and /etc/vfstab will be loopback mounted, and read only. :)

      I tried it, and worked . With this trick, I think you can mount almost any configuration file read only for the local zone.

      regards,

      Imre Csatlos

      #3; Thu, 05 Jul 2007 20:20:00 GMT
    • Oh wow, this is really cool! :-)I'll definitely give this a try.Thanks a lot!Carolyn
      #4; Thu, 05 Jul 2007 20:20:00 GMT
    • This is a fab tip. Thank you.
      #5; Thu, 05 Jul 2007 20:20:00 GMT

    • Yes, this was a really great tip. Just as Imre Csatlos indicates, I'm starting to think of other areas where this will really come in handy.

      I tested this yesterday and indeed was able to limit access to the mounting of /tmp onto swap using the method Imre provided. One thing I realized after I started testing though, is that although I can now block the possibility of someone using /tmp in a non-global zone to fill up swap, anyone who has the root password in a non-global zone could just mount swap to another directory and fill it up anyway! I'm going to do some more testing today to see if there's any way to prevent this.

      The workaround Imre's suggested will definitely come in handy when trying to eliminate accidental instances of applications or users filling swap from within a non-global zone, but if someone really wants to do it and they get the root password, they can. The other workaround we've considered is just eliminating swap altogether, but we're not yet sure if that's a real option for our systems.

      Thanks,

      Carolyn

      #6; Thu, 05 Jul 2007 20:20:00 GMT

    • Currently, there is a single swap area that is shared across

      the global zone and all of the zones on the system. In the future,

      we expect to support the ability to create a per-zone swap area or

      a limit on swap resources that can be consumed by a non-global

      zone.

      #7; Thu, 05 Jul 2007 20:20:00 GMT