1. Will the IP address change after migration?
Both types of live migration exist, including changing and not changing IP address .
- Based on Google cloud , it can migrate clients’ VM without affect the customers. That means the IP address of a VM would not be changed in this case.
- To retain the same IP address, hyper-V requires the source and destination hosts to be within the same subnet. I think Google cloud may not have this requirement.
- I think the virtual network  would be able to remove the restrictions on the locations of the destination hosts. “Hyper-V Network Virtualization decouples virtual networks for customer virtual machines from the physical network infrastructure.”
2. Will the migration interrupt the Internet service?
This depends on the implementation. The answer is different regarding different implementation.
- According to google cloud , there will be no service interruptions.
- During post-migration brownout, the VM executes on the target. The source VM is present, and may be providing supporting functionality for the target. For instance, until the network fabric has caught up the new location of the VM, and source VM provides forwarding services for packets to and from the target VM.
- According to hyper-V 
- the migration is not downtime-free, the interruption is almost immeasurably brief. Usually the longest delay is the network layer while the virtual machine’s MAC address is registered on the new physical switch port and its new location is propagated throughout the network.
- According to , in order to use live migration the VM needs to keep the same IP address across date centers in order to achieve the goal of continuous access from clients to the virtual machine during and after the migration.
3. How the network is migrated?
The most challenging issue in VM migration is to keep the network working.
In LAN, different hypervisors using different strategies.
- It uses ARP to bind the IP address to the new host.
- The VM sends ARP signal, broadcast that the IP address is moved to a new host. But this may not be allowed for security reasons.
- VMotion uses VNIC to ensure the network connection.
- The VNIC will be migrated with VM as well. Every VNIC has a unique MAC address in LAN and is connected to one or multiple NIC.
- Since VNIC has a MAC address that is irrelevant to the physical network address, the network will be continued as normal using VM live migration.
- Note due to the restrictions of Ethernet, the source and destination hosts have to be in the same subnet.
- The VM will be given a new IP address in the destination host. In order to ensure the network connection, we can use IP tunnel with combination of dynamic DNS, i.e., we can build a IP tunnel between the source IP and destination IP address, and use it to forward the packets from source host to destination host. Once migration is done, VM can response to the new network. It means the DNS is updated, and the network connection will refer to the new IP address.
 Google cloud VM live migration
 Hyper-V live migration
 Live Migration — Implementation considerations
 Hyper-V 网络虚拟化概述
- Probability the system operates correctly at any given moment
- Ability to run correctly for a long interval of time
- Failure to operate correctly does not lead to catastrophic failures
- Ability to “easily” repair a failed system
- Different types of failures
- [Lamport et al. (1982)]
- Each process learn the true values sent by correct processes
- Every message that is sent is delivered correctly
- The receiver knows who sent the message
- Message delivery time is bounded
- Byzantine Agreement Result
- In a system with m faulty processes agreement, agreement can be achieved only if there are 2m+1 functioning correctly.
- This result only guarantees that each process receives the true values sent by correct processors, but it does not identify the correct process!
Byzantine General Problem
- Phase 1: Generals announce their troop strengths to each other
- Phase 2: Each general construct a vector with all troops
- Phase 3: General send their vectors to each other and compute the majority voting
Reliable Group Communication
- Reliable Multicast
- All nonfaulty process which do not join/leave during communication receive the message
- Atomic Multicast
- All message are delivered in the same order to all processes
- A view reflects current membership of group
- A view is delivered when a membership change occurs and the application is notified of the change
- Receiving a view is different from delivering a view
- All members have to agree to the delivery of a review
- View synchronous group communication
- The delivery of a new view draws a conceptual line across the system and every message is either delivered on one side or the other of that line
- All message are delivered in the same order to “all” processes
- Group view
- The set of processes known by the sender when it multicast the message
- Virtual synchronous multicast
- A message multicast to a group view G is delivered to all nonfaulty process in G
- If sender fails after sending the message, the message may be delivered to no one
Virtual Synchrony Implementation
- Only stable messages are delivered
- Stable message
- A message received by all processes in the message’s group view
- Assumptions (can be ensured by using TCP)
- Point-to-point communication is reliable
- Point-to-point communication ensures FIFO-ordering
- Total ordering does not imply causality or FIFO!
- Provide atomic operations at servers that maintain shared data for clients
- Provide recoverability from server crashes
- Without concurrency control, we have lost updates, inconsistent retrievals, dirty reads, etc.
- Concurrency control schemes are designed to allow two or more transactions to be executed correctly while maintaining serial equivalence
- Serial Equivalence is correctness criterion
- Schedule produced by concurrency control scheme should be equivalent to a serial schedule in which transactions are executed one after the other.
- Optimistic concurrency control
- Time-stamp based concurrency control
Use of Locks in Strict Two-Phase Locking
When an operation accesses an object within a transaction
- (1) If the object is not already locked, it is locked and the operation proceeds
- (2) If the object has a conflicting lock set by another transaction, the transaction must wait until it is unlocked
- (3) If the object has a non-conflicting lock set by another transaction, the lock is shared and the operation proceeds
- (4) If the object has already been locked in the same transaction, the lock will be promoted if necessary and the operation proceeds
- When promotion is prevented by a conflicting lock, rule 2 is used
Resolution of Deadlock
Optimistic Concurrency Control
Drawback of locking
- Overhead of lock maintainance
- Reduced concurrency
Optimistic Concurrency Control
- In most applications, likelihood of conflicting accesses by concurrent transaction is low
- Transactions proceed as though there are no conflicts
- Three phases
- Working Phase
- Transactions read and write private copies of objects
- Validation phase
- Each transaction is assigned a transaction number when it enters its phase
- Update phase
Validation of Transaction
Timestamp Based Concurrency Control
- Each transaction is assigned a unique timestamp at the moment it starts
- In distributed transactions, Lamport’s timestamps can be used.
- Every data item has a timestamp
- Read timestamp = timestamp of transaction that last read the time
- Write timestamp = timestamp of transaction that most recently changed an item
Timestamp ordering write rule
Concurrency Control for Distributed Transactions
- Distributed deadlocks possible
- Timestamp ordering
The Two-Phase Commit Protocol
- Problem with two-phase commit
- If coordinator crashes, participants cannot reach a decision, stay blocked until coordinator recovers
- Three-phase commit
- There is no single state from which it is possible to make a transaction directly to another COMMIT or ABORT state
- There is not state in which it is not possible to make a final decision, and from which a transaction to COMMIT can be made.
Basic Architecture for Replica Data Management
Five phases in performing a request
- Front end issues the request
- Either sent to a single replica or multicast to all replicate managers
- Replica managers coordinate in preparation for the execution of the request
- i.e., agree is requests is to be performed and the ordering of the request relative to others
- Reach consensus on effect of the request, e.g., agree to commit or abort in a transactional system
Mechanism for Sequential Consistency
- Primary-based replication protocols
- Replicated-write protocols
- Active replication using multicast communication
- Quorum-based protocols
- Front ends only communicate with primary
- FE issues a request containing a unique identifier to the primary replica manager
- The primary takes each request in the order in which it receives it
- The primary executes the request and store the response
- If the request is an update, the primary sends the updated state, the response and the unique id to all backups. The backups send an acknowledgement.
- The primary responds to the front end, which hands the response back to the client.
- Implements linearizability if primary is correct, since primary sequences all the operations
- If primary fails, the system retains linearizabilty if a single back becomes the new primary and if the new system configuration takes over exactly where the last left off
- If primary fails, it should be replaced with a unique backup
- Replica managers that survive have to agree upon which operation has been performed when the replacement primayr is over
- Requirements met if replica managers organized as a group and if primary uses view-synchronous communication to propagate updates to backups.
- Front end multicasts request to each replica using a totally ordered reliable multicast
- System achieves sequential consistency but not linearizability
- Total order in which replica managers process requests may not be the same as real-time order in which clients made request.
Implementing Ordered Multicast
- Incoming messages are held back in a queue until delivery guarantees can be met
- The hold-back queue for arriving multicast messages
- Coordinate all machines needed to determine delivery order
- Use a separate sequence number for each process
- Total ordering
- Use a sequencer
- Distributed algorithm with three phases
- Causal order
The ISIS algorithm for total ordering
Causal Ordering using Vector Timestamps
- Assign a number of votes to each replica
- Let N be the total number of votes
- Define R = read quorum, W = write quorum
- R+W > N
- W > N/2
- guarantee that no two writes at the same time
- since if yes, than the vote for w_1 and w_2 are larger than N
- Only one writer at a time can achieve write quorum
- Every reader sees at least one copy of the most recent read (takes one with most recent version number)
- None of the protocols for sequential consistency scale
- To read or write, you have to either
- Contact a primary copy
- Use reliable totally ordered multicast
- Contact over half the replicas
- All this complexity is to ensure sequential consistency
- Even the protocols for causal consistency and FIFO consistency are difficult to scale if they use reliable multicast
- Can we weaken sequential consistency without losing some important features?
Highly Available Service
- Emphasis on giving clients access to the service with reasonable response time, even if some results do not conform to sequential consistency
- Eventual consistency
- Domain-specific conflict detection and resolution
- Coda (file system)
- Disconnected operation
- Use vector timestamp to detect conflicts