Xen Project Version Compatibility: Difference between revisions
m (→Xen 3.x vs Xen 4.x: "the case than" -> "the case that") |
Rcpavlicek (talk | contribs) m (moved Xen Version Compatibility to Xen Project Version Compatibility: Trademark) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 7: | Line 7: | ||
= Live Migration Between Versions = |
= Live Migration Between Versions = |
||
Xen supports migration (including live migration and save restore) both within a stable release branch (e.g. between any versions in the ''4.2.x'' branch) and from one major release to the next (e.g. from release ''N'' to release''N+1''). This allows one to upgrade a pool of Xen hosts by evacuating and upgrading the hosts one by one. |
Xen Project supports migration (including live migration and save restore) both within a stable release branch (e.g. between any versions in the ''4.2.x'' branch) and from one major release to the next (e.g. from release ''N'' to release''N+1''). This allows one to upgrade a pool of Xen Project hosts by evacuating and upgrading the hosts one by one. |
||
Although it is not formally supported skipping a major release (e.g. migration from release ''N'' to release ''N+2'') may often work. |
Although it is not formally supported skipping a major release (e.g. migration from release ''N'' to release ''N+2'') may often work. |
||
| Line 13: | Line 13: | ||
Migrating down a version (e.g. from release ''N+1'' down to release ''N'') is not normally supported. |
Migrating down a version (e.g. from release ''N+1'' down to release ''N'') is not normally supported. |
||
= Xen 3.x vs Xen 4.x = |
= Xen 3.x vs Xen Project 4.x = |
||
The release following Xen 3.4 was named 4.0. However this was just a version number bump and does not imply anything particular with regards to compatibility guarantees between those two versions. From a compatibility point of view Xen 4.0 could just as easily have been called Xen 3.5. |
The release following Xen 3.4 was named 4.0. However this was just a version number bump and does not imply anything particular with regards to compatibility guarantees between those two versions. From a compatibility point of view Xen Project 4.0 could just as easily have been called Xen 3.5. |
||
In particular it is ''not'' the case that Xen 4.x is incompatible with guests using the Xen 3.x hypervisor API and the Guest API guarantees mentioned above continue to hold. Likewise live migration from version 3.4 to version 4.0 is supported. |
In particular it is ''not'' the case that Xen Project 4.x is incompatible with guests using the Xen 3.x hypervisor API and the Guest API guarantees mentioned above continue to hold. Likewise live migration from version 3.4 to version 4.0 is supported. |
||
[[Category:Compatibility]] |
[[Category:Compatibility]] |
||
Latest revision as of 00:09, 22 April 2014
Guest ABI Guarantees
The hypervisor API exposed to guests was declared to be a stable binary interface (ABI) with the release of Xen 3.0.0 in December 2005. Any changes to the guest visible ABI are done in a backwards compatible manner and new interfaces are optional and opt-in for guests.
If the hypervisor ABI is changed in a way which breaks an existing guest then this should be considered a bug.
Live Migration Between Versions
Xen Project supports migration (including live migration and save restore) both within a stable release branch (e.g. between any versions in the 4.2.x branch) and from one major release to the next (e.g. from release N to releaseN+1). This allows one to upgrade a pool of Xen Project hosts by evacuating and upgrading the hosts one by one.
Although it is not formally supported skipping a major release (e.g. migration from release N to release N+2) may often work.
Migrating down a version (e.g. from release N+1 down to release N) is not normally supported.
Xen 3.x vs Xen Project 4.x
The release following Xen 3.4 was named 4.0. However this was just a version number bump and does not imply anything particular with regards to compatibility guarantees between those two versions. From a compatibility point of view Xen Project 4.0 could just as easily have been called Xen 3.5.
In particular it is not the case that Xen Project 4.x is incompatible with guests using the Xen 3.x hypervisor API and the Guest API guarantees mentioned above continue to hold. Likewise live migration from version 3.4 to version 4.0 is supported.
