Migration Guide To Xen4.1+: Difference between revisions

From Xen
Jump to navigationJump to search
mNo edit summary
m (Fix typo)
 
(20 intermediate revisions by 5 users not shown)
Line 5: Line 5:
<!-- Original date: Sun Mar 27 08:26:16 2011 (1301214376000000) -->
<!-- Original date: Sun Mar 27 08:26:16 2011 (1301214376000000) -->


⚫
Xen 4.1.0 includes a new toolstack <code>xl</code>. This new toolstack is intended to be a drop in replacement for the <code>xm</code> command line interface to the <code>xend</code> toolstack. <code>xl</code> is built on the <code>libxl</code> toolstack library which is intended as a common library which will be used by all toolstacks in the future.
{{Needs_Refactor|Has some Wiki conversion formatting issues that need fixing, e.g. <pre>[[self:HostConfiguration/Networking|HostConfiguration]/Networking]</pre>}}


⚫
The <code>xend</code> toolstack remains supported in Xen 4.1.0 however users are strongly recommended to upgrade to <code>xl</code>.
= Migration Guide To Xen 4.1+ =


<b>Beginning with Xen Project 4.5, the <code>xend</code> toolstack will no longer be supported or be provided with the software.</b>
⚫
Xen 4.1.0 includes a new toolstack <code><nowiki>xl</nowiki></code>. This new toolstack is intended to be a drop in replacement for the <code><nowiki>xm</nowiki></code> command line interface to the <code><nowiki>xend</nowiki></code> toolstack. <code><nowiki>xl</nowiki></code> is built on the <code><nowiki>libxl</nowiki></code> toolstack library which is intended as a common library which will be used by all toolstacks in the future.


__TOC__
⚫
The <code><nowiki>xend</nowiki></code> toolstack remains supported in Xen 4.1.0 however users are strongly recommended to upgrade to <code><nowiki>xl</nowiki></code>.


== General upgrade notes ==
= General upgrade notes =


In this release the Xen build system will no longer clone and build a kernel on behalf of the user. There is no coupling betweeen a Xen release and the kernel used in either dom0 or domU nor any coupling between the dom0 kernel and the domU kernel.
In this release the Xen build system will no longer clone and build a kernel on behalf of the user. There is no coupling betweeen a Xen release and the kernel used in either dom0 or domU nor any coupling between the dom0 kernel and the domU kernel.


For guest domain (domU) use users are strongly encouraged to take advantage of the Xen guest support which is present in many mainstream distributions. See Self:XenDomUSupport for more information.
For guest domain (domU) use users are strongly encouraged to take advantage of the Xen guest support which is present in many mainstream distributions. See [[XenDomUSupport]] for more information.


For domain 0 use please see the [[XenDom0Kernels]] page for more information and guidance.
For domain 0 use please see the [[XenDom0Kernels]] page for more information and guidance.


== Toolstack upgrade notes ==
= Toolstack upgrade notes =


=== xl upgrade notes and migration steps from xend ===
== xl upgrade notes and migration steps from xend ==


The <code><nowiki>xl</nowiki></code> toolstack is intended to remain backwards compatible with existing <code><nowiki>xm</nowiki></code> domain configuration files. It is therefore expected that any existing configurations should work with <code><nowiki>xl</nowiki></code> with the following exceptions:
The <code>xl</code> toolstack is intended to remain backwards compatible with existing <code>xm</code> domain configuration files. It is therefore expected that any existing configurations should work with <code>xl</code> with the following exceptions:


* Arbitrary embedded python is not supported. Therefore it will be necessary to remove any python code from your configuration files.
* Arbitrary embedded python is not supported. Therefore it will be necessary to remove any python code from your configuration files.
* Managed domains (e.g. <code><nowiki>xm vm-create</nowiki></code>, <code><nowiki>xm vm-start</nowiki></code> etc) are not supported by <code><nowiki>xl</nowiki></code>. Other toolstacks which support managed domains are [http://www.xen.org/products/cloudxen.html Xen Cloud Platform's] <code><nowiki>xapi</nowiki></code> toolstack and [http://libvirt.org/ libvirt].
* Managed domains (e.g. <code>xm vm-create</code>, <code>xm vm-start</code> etc) are not supported by <code>xl</code>. Other toolstacks which support managed domains are the [[XAPI]] toolstack and [[Libvirt]].
* <code>xl</code> does not support the <code>w!</code> notation to share disks between several DomU's
* For a complete comparison see [[XL vs Xend Feature Comparison]]
⚫
The other notable difference is that <code>xl</code>, unlike <code>xend</code>, will not perform any host networking configuration for you. The <code>xend</code> code to reconfigure on startup is extremely fragile, prone to bugs when either distro or Xen are upgraded and rather difficult to debug. Instead <code>xl</code> takes the approach of deferring such network configuration to the distribution configuration tools which are usually well understood and documented. Therefore upon upgrading to <code>xl</code> it is necessary to configure your host networking stack appropriately. Please see [[Network_Configuration_Examples_(Xen_4.1+)]] for more details on how to do this.


⚫
Please report any other configuration file incompatibilities to the Xen developers on the [mailto:xen-devel@lists.xensource.com xen-devel mailing list]. Also, please describe your use-case, which will help developers decide how important the missing feature is.
⚫
The other notable difference is that <code><nowiki>xl</nowiki></code>, unlike <code><nowiki>xend</nowiki></code>, will not perform any host networking configuration for you. The <code><nowiki>xend</nowiki></code> code to reconfigure on startup is extremely fragile, prone to bugs when either distro or Xen are upgraded and rather difficult to debug. Instead <code><nowiki>xl</nowiki></code> takes the approach of deferring such network configuration to the distribution configuration tools which are usually well understood and documented. Therefore upon upgrading to <code><nowiki>xl</nowiki></code> it is necessary to configure your host networking stack appropriately. Please see [[self:HostConfiguration/Networking|HostConfiguration]/Networking] for more details on how to do this.


⚫
=== xl Upgrade Checklist ===
⚫
Please report any other configuration file incompatibilities to the Xen developers on the [mailto:xen-devel@lists.xensource.com xen-devel mailing list].


⚫
* Configure your host networking using the configuration tools provided by your distribution. (See: [[Network_Configuration_Examples_(Xen_4.1+)]])
⚫
==== xl Upgrade Checklist ====

⚫
* Configure your host networking using the configuration tools provided by your distribution. (See: [[self:HostConfiguration/Networking|HostConfiguration]/Networking])
* Remove any python code from domU configuration files.
* Remove any python code from domU configuration files.
* Disable xend startup script
* Disable xend startup script
* Use <code><nowiki>xl</nowiki></code> command instead of <code><nowiki>xm</nowiki></code>
* Use <code>xl</code> command instead of <code>xm</code>

=== Find an incompatibility? File a Bug ===

<code>xl</code> is designed to be compatible with <code>xm</code>, except for the cases listed above. If you find a situation where <code>xl</code> seems to be incompatible, please file a bug report using the process described in [[Reporting_Bugs_against_Xen_Project]].


=== xend upgrade notes ===
== xend upgrade notes ==


The upgrade form previous <code><nowiki>xend</nowiki></code> versions is intended to be transparent, with the following exception:
The upgrade from previous <code>xend</code> versions is intended to be transparent, with the following exception:


* In previous releases <code><nowiki>xend</nowiki></code> unconditionally reconfigures the host network stack on startup, according to the <code><nowiki>network-script</nowiki></code> configuration item in <code><nowiki>/etc/xen/xend-config.sxp</nowiki></code>. In this release <code><nowiki>xend</nowiki></code> will only reconfigure the host network stack if the network stack does not appear to have been configured already (e.g. no bridges currently exist). This change allows administrators who wish to configure the network stack themselves (e.g. following the guidance on [[self:HostConfiguration/Networking|HostConfiguration]/Networking]) to do so by default while preserving the existing behaviour for those who do not. In addition this new behaviour allows for smoother transitions back and forth between <code><nowiki>xend</nowiki></code> and <code><nowiki>xl</nowiki></code> (as described in the <code><nowiki>xl</nowiki></code> upgrade notes) since it means you can safely make the necessary configuration changes to use <code><nowiki>xl</nowiki></code> and not have to undo them if you switch back to <code><nowiki>xend</nowiki></code>. In this case it is recommended to use the <code><nowiki>xenbrN</nowiki></code> naming convention for maximum compatibility.
* In previous releases <code>xend</code> unconditionally reconfigures the host network stack on startup, according to the <code>network-script</code> configuration item in <code>/etc/xen/xend-config.sxp</code>. In the 4.1 release (and beyond), <code>xend</code> will only reconfigure the host network stack if the network stack does not appear to have been configured already (e.g. no bridges currently exist). This change allows administrators who wish to configure the network stack themselves (e.g. following the guidance on [[Network_Configuration_Examples_(Xen_4.1+)]]) to do so by default while preserving the existing behaviour for those who do not. In addition this new behaviour allows for smoother transitions back and forth between <code>xend</code> and <code>xl</code> (as described in the <code>xl</code> upgrade notes) since it means you can safely make the necessary configuration changes to use <code>xl</code> and not have to undo them if you switch back to <code>xend</code>. In this case it is recommended to use the <code>xenbrN</code> naming convention for maximum compatibility.


[[Category:Xen]]
[[Category:Xen]]
Line 52: Line 57:
[[Category:Beginners]]
[[Category:Beginners]]
[[Category:Tutorial]]
[[Category:Tutorial]]
[[Category:Compatibility]]

Latest revision as of 16:14, 7 January 2015


Xen 4.1.0 includes a new toolstack xl. This new toolstack is intended to be a drop in replacement for the xm command line interface to the xend toolstack. xl is built on the libxl toolstack library which is intended as a common library which will be used by all toolstacks in the future.

The xend toolstack remains supported in Xen 4.1.0 however users are strongly recommended to upgrade to xl.

Beginning with Xen Project 4.5, the xend toolstack will no longer be supported or be provided with the software.

General upgrade notes

In this release the Xen build system will no longer clone and build a kernel on behalf of the user. There is no coupling betweeen a Xen release and the kernel used in either dom0 or domU nor any coupling between the dom0 kernel and the domU kernel.

For guest domain (domU) use users are strongly encouraged to take advantage of the Xen guest support which is present in many mainstream distributions. See XenDomUSupport for more information.

For domain 0 use please see the XenDom0Kernels page for more information and guidance.

Toolstack upgrade notes

xl upgrade notes and migration steps from xend

The xl toolstack is intended to remain backwards compatible with existing xm domain configuration files. It is therefore expected that any existing configurations should work with xl with the following exceptions:

  • Arbitrary embedded python is not supported. Therefore it will be necessary to remove any python code from your configuration files.
  • Managed domains (e.g. xm vm-create, xm vm-start etc) are not supported by xl. Other toolstacks which support managed domains are the XAPI toolstack and Libvirt.
  • xl does not support the w! notation to share disks between several DomU's
  • For a complete comparison see XL vs Xend Feature Comparison

The other notable difference is that xl, unlike xend, will not perform any host networking configuration for you. The xend code to reconfigure on startup is extremely fragile, prone to bugs when either distro or Xen are upgraded and rather difficult to debug. Instead xl takes the approach of deferring such network configuration to the distribution configuration tools which are usually well understood and documented. Therefore upon upgrading to xl it is necessary to configure your host networking stack appropriately. Please see Network_Configuration_Examples_(Xen_4.1+) for more details on how to do this.

Please report any other configuration file incompatibilities to the Xen developers on the xen-devel mailing list. Also, please describe your use-case, which will help developers decide how important the missing feature is.

xl Upgrade Checklist

  • Configure your host networking using the configuration tools provided by your distribution. (See: Network_Configuration_Examples_(Xen_4.1+))
  • Remove any python code from domU configuration files.
  • Disable xend startup script
  • Use xl command instead of xm

Find an incompatibility? File a Bug

xl is designed to be compatible with xm, except for the cases listed above. If you find a situation where xl seems to be incompatible, please file a bug report using the process described in Reporting_Bugs_against_Xen_Project.

xend upgrade notes

The upgrade from previous xend versions is intended to be transparent, with the following exception:

  • In previous releases xend unconditionally reconfigures the host network stack on startup, according to the network-script configuration item in /etc/xen/xend-config.sxp. In the 4.1 release (and beyond), xend will only reconfigure the host network stack if the network stack does not appear to have been configured already (e.g. no bridges currently exist). This change allows administrators who wish to configure the network stack themselves (e.g. following the guidance on Network_Configuration_Examples_(Xen_4.1+)) to do so by default while preserving the existing behaviour for those who do not. In addition this new behaviour allows for smoother transitions back and forth between xend and xl (as described in the xl upgrade notes) since it means you can safely make the necessary configuration changes to use xl and not have to undo them if you switch back to xend. In this case it is recommended to use the xenbrN naming convention for maximum compatibility.
Retrieved from "https://wiki.xenproject.org/index.php?title=Migration_Guide_To_Xen4.1%2B&oldid=13596"