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 software

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.