Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
server: get migration target specs from their sources (#807)
Change how migration targets decide what VM configuration to use: instead of having the client send a configuration as part of its request to start migration, have the target inherit the configuration the source sends in the live migration preamble. The benefits are that - Clients (i.e. the control plane) no longer have to remember how they configured their migration sources, and - Most migration compatibility checks are no longer needed--the target's configuration is compatible with the source's because it *is* the source's configuration. Some source components do need to be reconfigured over a migration. These include Crucible and viona backends: Crucible backends need new generation numbers for each client, and viona backends may change the names of the host VNICs to which they bind when a VM moves from host to host. To accommodate this, make the sync phase substitute the target VM's Crucible and viona backend configuration into the configuration received in the preamble. This will be formalized more in subsequent changes. The eventual goal is to change the request-migration API so that clients don't send targets any instance spec at all. When this happens, targets won't have a spec until the migration protocol has already begun to run. To prepare for this: - Create the VMM's tokio runtime just before creating VM components instead of creating it up front and running the entire VM initialization process on it. This is needed because the runtime's thread count depends on the number of vCPUs in the VM, and that information comes from the instance spec. - Slightly adjust the `instance_spec_get` API to reflect that a spec might not be available if a VM is currently initializing via live migration. Tests: cargo test, PHD.
- Loading branch information