Add Support for Migration Statistics API Call#43
Add Support for Migration Statistics API Call#43phip1611 wants to merge 11 commits intocyberus-technology:gardenlinuxfrom
Conversation
e29356d to
4101b11
Compare
f49e577 to
fdf5858
Compare
f612cf6 to
e9a3321
Compare
e9a3321 to
ecb5f45
Compare
e6c80dd to
fe8cd0d
Compare
fe8cd0d to
a87fe95
Compare
a87fe95 to
6d68c0c
Compare
vm-migration/src/progress.rs
Outdated
| /// [live-migration protocol]: super::protocol | ||
| #[derive(Clone, Debug, serde::Serialize, serde::Deserialize)] | ||
| pub struct MigrationProgressAndStatus { | ||
| /// UNIX timestamp of the start of the live-migration process. |
There was a problem hiding this comment.
please note that this structure will be public API for ever and once we reploy it, it will be hard to change
6d68c0c to
c934e0e
Compare
708695d to
40e58e3
Compare
I've updated the code.
I don't see how this would help. These statistics are not "nice helpers that we need sometimes to debug". They are a fundamental and important functionality we want to export via API. I hope the new PR description makes the intent here clearer. |
ceb915e to
5b63ea5
Compare
amphi
left a comment
There was a problem hiding this comment.
Looks good, just a few small comments and nits.
vmm/src/lib.rs
Outdated
| // Give management software a chance to fetch the migration state. | ||
| // The VMM already executes on the other side and keeping Cloud Hypervisor running for a | ||
| // couple of more seconds is fine. | ||
| info!("Sleeping five seconds before shutting off."); |
There was a problem hiding this comment.
I think this waiting, and maybe also the mark_as_finished() a few lines above, should happen in check_migration_result. Otherwise the management software would see the mark_as_failed very late.
There was a problem hiding this comment.
Agree about the sleep. Not sure about the other. Other thoughts?
There was a problem hiding this comment.
Update. all of this need to happen in the end of the migration thread, not in check_migration_result. Otherwise, the API thread is blocked and API users can never query the latest state.
a83f554 to
7ee8334
Compare
7ee8334 to
f937d87
Compare
679c6f1 to
307475e
Compare
307475e to
f32b6f7
Compare
On-behalf-of: SAP philipp.schuster@sap.com Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
The logging is not very spammy nor costly (iterations take seconds to dozens of minutes) and is clearly a win for us to debug things. On-behalf-of: SAP philipp.schuster@sap.com Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
This is the first commit in a series of commits to introduce a new API endpoint in Cloud Hypervisor to report progress and live-insights about an ongoing live migration. Having live and frequently refreshing statistics/metrics about an ongoing live migration is especially interesting for debugging and monitoring. For the first time, we will be able to see how live-migrations behave and create benchmarking infrastructure around it. The ch driver in libvirt will use these information to populate its `virsh domjobinfo` information. We will add a new API endpoint to query information. Further, the endpoint will be interesting to query information about a previously failed or canceled live migration. Specifically interesting about this API endpoint is that it will be the first endpoint that needs the "asynchronization" of the API: more than one API request in parallel. This needs support at least in the HTTP API and the internal API. The "SendMigration" call is long-running and active even if someone is querying the new endpoint. On-behalf-of: SAP philipp.schuster@sap.com Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
This is part of the commit series to enable live updates about an ongoing live migration. See the first commit for an introduction. On-behalf-of: SAP philipp.schuster@sap.com Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
This is part of the commit series to enable live updates about an ongoing live migration. See the first commit for an introduction. In this commit, we add the HTTP endpoint to export ongoing VM live-migration progress. This work was made possible because of the following fundamental prerequisites: - internal API was made async - http thread was made async This way, one can send requests to fetch the latest state without blocking in any code path of the API. On-behalf-of: SAP philipp.schuster@sap.com Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
This is part of the commit series to enable live updates about an ongoing live migration. See the first commit for an introduction. This commit prepares the avoidance of naming clashes in the following. On-behalf-of: SAP philipp.schuster@sap.com Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
This is part of the commit series to enable live updates about an ongoing live migration. See the first commit for an introduction. This commit actually brings all the functionality together. The first version has the limitation that we populate the latest snapshot once per memory iteration, although this is the most interesting part by far. In a follow-up, we can make this more fine-grained. On-behalf-of: SAP philipp.schuster@sap.com Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
This is part of the commit series to enable live updates about an ongoing live-migration. See the first commit for an introduction. There isn't really an error that can happen when we query this endpoint. A previous snapshot may either be there or not. It also doesn't make sense here to check if the current VM is running, as users should always be able to query information about the past (failed or canceled) live migration. On-behalf-of: SAP philipp.schuster@sap.com Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
This is part of the commit series to enable live updates about an ongoing live migration. See the first commit for an introduction. On-behalf-of: SAP philipp.schuster@sap.com Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
b171d24 to
6b18d8f
Compare
TL;DR
This extends the internal API with a
vm_progressfunction and adds avm.migration-progressHTTP endpoint including support inch-remoteviach-remote migration-processto query the latest migration progress.Motivation
Monitoring a live-migration with live updated information is very important for debugging, development, and monitoring. This is something that verbose logging can't achieve as there is a clear desire to have that structured information somewhere on the outside - and also to prevent spammy logs.
The most interesting part is the pre-copy phase where we get information on each new memory iteration. The first version is rather coarse-grained with one update per memory iteration. More to follow.
The ch driver in libvirt will use these information to populate its
virsh domjobinfoinformation.Further, the endpoint will be interesting to query information about a
previously failed or canceled live migration.
Prerequisites
The two major pre-requisites were:
Steps to Undraft
ch-remote