Dmitry Safonov wanted to implement a namespace for time information. The
\ntwisted and bizarre thing about virtual machines is that they get more
\nvirtual all the time. There’s always some new element of the host system
\nthat can be given its own namespace and enter the realm of the virtual
\nmachine. But as that process rolls forward, virtual systems have to share
\naspects of themselves with other virtual systems and the host system
\nitself\u2014for example, the date and time.<\/p>\n
Dmitry’s idea is that users should be able to set the day and time on their
\nvirtual systems, without worrying about other systems being given the same
\nday and time. This is actually useful, beyond the desire to live in the past
\nor future. Being able to set the time in a container is apparently one of
\nthe crucial elements of being able to migrate containers from one physical
\nhost to another, as Dmitry pointed out in his post.<\/p>\n
As he put it:<\/p>\n
The kernel provides access to several clocks:
\nCLOCK_REALTIME,
\nCLOCK_MONOTONIC, CLOCK_BOOTTIME. Last two clocks are monotonous, but the
\nstart points for them are not defined and are different for each running
\nsystem. When a container is migrated from one node to another, all clocks
\nhave to be restored into consistent states; in other words, they have to
\ncontinue running from the same points where they have been dumped.<\/p><\/blockquote>\nDmitry’s patch wasn’t feature-complete. There were various questions still
\nto consider. For example, how should a virtual machine interpret the time
\nchanging on the host hardware? Should the virtual time change by the same
\noffset? Or continue unchanged? Should file creation and modification times
\nreflect the virtual machine’s time or the host machine’s time?<\/p>\nEric W. Biederman supported this project overall and liked the code in the
\npatch, but he did feel that the patch could do more. He thought it was a little
\ntoo lightweight. He wanted users to be able to set up new time namespaces at
\nthe drop of a hat, so they could test things like leap seconds before
\nthey actually occurred and see how their own projects’ code worked under
\nthose various conditions.<\/p>\nTo do that, he felt there should be a whole “struct timekeeper” data
\nstructure for each namespace. Then pointers to those structures could be
\npassed around, and the times of virtual machines would be just as
\nmanipulable and useful as times on the host system.<\/p>\nIn terms of timestamps for filesystems, however, Eric felt that it might
\nbe best to limit the feature set a little bit. If users could create files
\nwith timestamps in the past, it could introduce some nasty security
\nproblems. He felt it would be sufficient simply to “do what distributed
\nfilesystems do when dealing with hosts with different clocks”.<\/p>\nThe two went back and forth on the technical implementation details. At one
\npoint, Eric remarked, in defense of his preference:<\/p>\nMy experience with
\nnamespaces is that if we don’t get the advanced features working there is
\nlittle to no interest from the core developers of the code, and the
\nnamespaces don’t solve additional problems. Which makes the namespace a
\nhard sell. Especially when it does not solve problems the developers of the
\nsubsystem have.<\/p><\/blockquote>\nAt one point, Thomas Gleixner came into the conversation to remind Eric that
\nthe time code needed to stay fast. Virtualization was good, he said, but
\n“timekeeping_update() is already heavy and walking through a gazillion of
\nnamespaces will just make it horrible.”<\/p>\nHe reminded Eric and Dmitry that:<\/p>\n
It’s not only timekeeping, i.e. reading time, this is also affecting all
\ntimers which are armed from a namespace.<\/p>\nThat gets really ugly because when you do settimeofday() or adjtimex() for a
\nparticular namespace, then you have to search for all armed timers of that
\nnamespace and adjust them.<\/p>\nThe original posix timer code had the same issue because it mapped the clock
\nrealtime timers to the timer wheel so any setting of the clock caused a full
\nwalk of all armed timers, disarming, adjusting and requeing them. That’s
\nhorrible not only performance wise, it’s also a locking nightmare of all
\nsorts.<\/p>\nAdd time skew via NTP\/PTP into the picture and you might have to adjust
\ntimers as well, because you need to guarantee that they are not expiring
\nearly.<\/p><\/blockquote>\nSo, there clearly are many nuances to consider. The discussion ended there,
\nbut this is a good example of the trouble with extending Linux to create
\nvirtual machines. It’s almost never the case that a whole feature can be
\nfully virtualized and isolated from the host system. Security concerns,
\nspeed concerns, and even code complexity and maintainability come into the
\npicture. Even really elegant solutions can be shot down by, for example, the
\npossibility of hostile users creating files with unnaturally old timestamps.<\/p>\nNote: if you’re mentioned above and want to post a response above the comment section, send a message with your response text to ljeditor@linuxjournal.com.<\/em><\/p>\n