4 ms·
how does using the monotonic api protect against time discontinuity as seen when a vm is migrated from one hypervisor to another for example?
by querulous 11y ago
how does using the monotonic api protect against time discontinuity as seen when a vm is migrated from one hypervisor to another for example?
- jschwartzi 11y agoMonotonic clocks are guaranteed never to go backwards, for one. In POSIX it would be a major violation of the API, although implementations are free to substitute clock sources if the monotonic source is not provided.
- derefr 11y agoOr, to put it more bluntly: a hypervisor that allows its VMs to be paused SHOULD NOT expose a monotonic time source to said VMs. (In the RFC meaning of "SHOULD NOT".) Enabling monotonic time should disable the ability to pause/migrate/snapshot the VMs, and vice-versa.
- antirez 11y agoIn this case, even in a broken implementation, the time freezes during the migration and is restored immediately after. This is bad since it makes even softwares using the monotonic API not able to count time reliably, however the result is that the time is over-counted, and never under-counted. If the algorithm is designed so that we want to count "at least 5 seconds" it is safe even during VM migrations. This is true for Redlock for example, but in general if one wants to exploit this system model, and can setup the algorithm so that over counting is harmless (if not for liveness), is a good idea. Btw this problems could be mitigated by changing the majority. For instance in the case of a distributed lock, it's possible to acquire the lock in 50% + 2 instances in order to consider the lock valid, so that in one instance the clock can misbehave safely.