vmm: Announce the migration memory mode through the protocol - #8819
vmm: Announce the migration memory mode through the protocol#8819phip1611 wants to merge 1 commit into
Conversation
3ccce95 to
e1817db
Compare
| pub tls_dir: Option<PathBuf>, | ||
| /// Memory transfer mode. | ||
| #[serde(default)] | ||
| pub memory_mode: MigrationMode, |
There was a problem hiding this comment.
Hint for reviewers: technically a breaking change but I tihnk we didn't ship this yet and even if we did, postcopy is officially experimental
Remove memory_mode from VmReceiveMigrationData. The old design is error-prone and inflexible. Memory migration is entirely sender-driven. On-behalf-of: SAP philipp.schuster@sap.com Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
e1817db to
7adab83
Compare
| let mut migration_config: VmMigrationConfig = serde_json::from_slice(&migration_config_bytes)?; | ||
| let state_bytes = fs::read(input_dir.join(SNAPSHOT_STATE_FILE)).map_err(Error::ReadFile)?; | ||
|
|
||
| migration_config.set_memory_mode(if ondemand { |
There was a problem hiding this comment.
This is confusing. Why is there a mixture of terminology here. Is ondemand the same as postcopy?
There was a problem hiding this comment.
I'm unsure about the offload demon. Please take a look @sboeuf,
No I think this approach should be fine as well. As long as we make sure the UFFD ranges are registered soon enough. @phip1611 I don't have a strong opinion going with either approach but can you please describe in a bit more details what this new approach buys us through the commit message. Also, did you actually run into an issue or this is all theoretical? This kind of feature has to be driven by some orchestration layer anyway, and having the config being sent from the sender or having the explicit knob on the receiver doesn't make a huge difference IMO. |
IMHO important cleanup/fix of the API. I missed this in @sboeuf PR I think. The new solution is more flexible and easy to integrate.