In 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.

Monotonic 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.

Or, 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.