the semantics of time-independent zones

Well, after spending a day sifting through Solaris timekeeping code and a few hours hacking (eg. waiting for builds to finish), I managed to get a zone that really couldn't care less about the system time. Great... what?? In all my fervor to get things done, I never stopped to think about some important semantic questions related to having processes running in disparate "times" on the same machine.

  • First, it's pretty clear that when the time is changed in a time-independent non-global zone (here abbreviated TWZ as a tribute to my love of the nickname "timewarp zone"), the system time should not be changed, but rather the stored time offset of the TWZ should be altered such that system time + offset = requested TWZ time. However, what about if the global zone time is changed? If I add two hours to the global zone time, do I want my TWZs to also be 2 hours in the future? If they're truly independent, probably not--which means going through all the TWZs and again modifying their offsets accordingly. Is there any reason to not keep them independent (aside from avoiding the overhead of zone offsets)?
  • Second, the TWZ shares a filesystem with the global zone. More specifically, the global zone can see the TWZ's files, though not vice-versa. If the TWZ is a year ahead and touches a file, what is the access time as perceived in the global zone? Clearly, the action actually happened right now in the global zone--not a year from now. But, creating this dual-time view of the filesystem is difficult. Consider the case of a TWZ being a year ahead, touching a file, then going yet another year ahead. The TWZ should see that it was created a year ago, while the global zone should see that it was created just then. What information do we need to store this? It's not enough to store the file in "real" system time and then just apply the TWZ offset--if we did that, we'd think that the file was created at the two-year offset. So it seems the only way to maintain the dual-time filesystem illusion is to store yet more information: what zone created it, and at what time offset. And we might not have to just worry about two different times: in the case of shared mounts (NFS), there could be an arbitrary number of different TWZs sharing a filesystem. Suddenly multi-time FS (MTFS?) doesn't seem very viable. If you've made it this far, I'll keep the next ramble shorter:
  • Third, and most administratively, is there any need to be able to change the time of a zone from without? Clearly it should be alterable from within; but should there be a facility (eg. zone property) for changing it from the outside? Keep in mind that this could always be solved by use of zlogin [command].

Posted on: Jun 15, 2007

Posted by: dank

Category: Sun

Permanent link to this entry

Comments:

But consider a system with NTP running in the global zone. NTP is constantly jiggering the clock to keep it in sync with the real time. If a local zone is 2 hours ahead of the global zone and NTP sets the global zone ahead 2 seconds, should the TWZ's offset be adjusted so that it is ahead by 1 hour 59 minutes and 58 seconds? Also consider this, if the TWZ is defined as having a time other than the actual time, what is it relative to? If it is relative to the global zone, then the TWZ's clock should in fact move ahead or backward when the global zone's time is changed. If it relative to the real time, how does it get a notion of the real time if not from the global zone? I would submit that the offset from the global zone must be administratively controlled only and never adjusted automatically. If it is adjusted automatically and the global zone is allowed to have anything other than the "real" time, then you can make no assertions whatsoever about the time in the TWZ.

Posted by Brian Utterback on June 20, 2007 at 08:50 AM PDT #

The TWZ's offset may be relative to the global zone, and hence the system clock, but that does not necessarily imply anything about the relationship of the TWZ time to that of the global zone. The goal of this is to have a completely independent time in the zone, yet have that time be consistent with our notions of the progress of time--eg. 1 hour in a TWZ is the same amount of time as 1 hour in my global zone. Hopefully, I will be able to make the assertion that if I walk away from my TWZ console and return one hour later, one hour appears to have elapsed in TWZ time, regardless of time changes in the global zone. If we need to get a sense of "real" time from within the zone, there's always NTP, though there will be no way of knowing what time the global zone thinks it is. In order to achieve this, the offsets of TWZs must be adjusted inversely as you state; I don't think that keeping time relative to "real" time is practical. This does not seem to necessitate removal of control from within the zone: if a TWZ root user knows that the progress of time forward will be consistent, they can simply set the current time.

Posted by dan kuebrich on June 20, 2007 at 01:57 PM PDT #

You need to blog more, dude. " Incidentally, LDoms are distinct from Solaris containers, which were developed for Sparc-based and Opteron-based servers. (Solaris containers are sometimes called Solaris zones.) With containers, a single Solaris kernel, a single file system, and a virtulized set of network and device interfaces is used to create multiple, isolated execution environments for Solaris applications. Applications running inside a container can't see what is going on outside of that container or access resources outside of the container. This is a very powerful means of creating virtual private servers, but does not provide a completely isolated software stack in each virtualized instance. With LDoms, companies will be able to have up to 32 logical partitions--just like those IBM has on mainframes and Power-based servers and Hewlett-Packard has on its Itanium-based Integrity machines. Each logical partition will be able to run a full instance of Solaris 10, and according to Wake, should companies want to, they will also be able to run Solaris containers inside of these LDom partitions. " http://www.itjungle.com/tug/tug101906-story03.html Little outdated, but this is what I thought zones were. LDoms are coolio!

Posted by Adam on June 28, 2007 at 08:19 AM PDT #

SO COOL http://sg.sun.com/sunnews/events/presentation/files/20070327_virtualization/02-logical-domains.pdf

Posted by Adam on June 28, 2007 at 08:37 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

This blog copyright 2007 by dank