Author Archives: Mike McClurg

Announcing XCP 1.6 Beta Release

Xen.org is happy to announce that XCP 1.6 Beta is available! The release is available from the download page:

This release supersedes the XCP 1.5 beta release. A few months ago, the XCP team decided to concentrate their efforts on fixing internal build system issues so that we could release new XCP versions more efficiently. We will be recommending that XCP 1.5 beta users upgrade to XCP 1.6 final when it is released.

New features and improvements

XCP 1.6 has many new features and improvements, most notably Storage XenMotion, improved integration with XenCenter, and massive VLAN scalability improvements. Please read the release notes for details.

Usage survey

For the first time, Xen.org is asking XCP users to contribute to our usage survey. We want to know more about how and why people use XCP, so that we can continue to make it better. Upon clicking the “download” link, you will be taken to an optional survey page. You don’t have to take the survey if you don’t want to, but we highly encourage everyone to participate.

Test day

Because of the great feedback we got from the Xen 4.2 test days, we’re going to be having a test day specifically for the XCP 1.6 beta (also see test instructions). This test day is scheduled for Tuesday, 9 October. We will be making reminder announcements on the xen-api mailing list.

If you find any issues with XCP 1.6 beta, please report them on the xen-api mailing list with the subject line containing [XCP-1.6-BETA].

Release schedule

The release schedule for XCP 1.6 is as follows:

  • XCP 1.6 Beta release: 1 October
  • XCP 1.6 Beta test day: 9 October
  • XCP 1.6 Final release: 24 October

We will stick to the final release date as long as there are no critical bugs that can’t be fixed in time.

Announcing Project Zeus: XenAPI in Fedora, CentOS and the EPEL

The XCP team would like to announce Project Zeus, our port of the XCP toolstack to Fedora and CentOS (through the EPEL). This is a follow-on to Project Kronos, which brought the XCP toolstack to Debian-based systems. This will give users the ability to do ‘yum install xcp-xapi’ to build a system that is functionally equivalent to the normal XCP. Our target for this project is Fedora 17, which will be released in May.

We don’t have any code to share yet, but packaging is currently underway. We will be able to reuse most of the work that we did in Project Kronos to port xapi to Debian, so Zeus should take significantly less effort to accomplish. I’d like to thank Pasi Kärkkäinen, M A Young, David Nalley and Eric Christensen for volunteering to lead the packaging effort. Here are some useful links:

XCP 1.5 Beta now available

I’m happy to announce that XCP 1.5 Beta is available! This release comes with a number of new features, most notably the Xen 4.1 hypervisor. Please go to the downloads page to download and test the beta release. If you would like to report a possible bug, please email the xen-api mailing list with the subject “XCP 1.5 BETA BUG: <subject>” (and see this for a list of bug reporting guidelines for the Xen community).

  • Host Architectural Improvements. XCP 1.5 now runs on the Xen 4.1 hypervisor, provides GPT support and a smaller, more scalable Dom0.
  • GPU Pass-Through. Enables a physical GPU to be assigned to a VM providing high-end graphics.
  • Increased Performance and Scale. Supported limits have been increased to 1 TB memory for XCP hosts, and up to 16 virtual processors and 128 GB virtual memory for VMs. Improved XCP Tools with smaller footprint.
  • Networking Improvements. Open vSwitch is now the default networking stack in XCP 1.5 and now provides formal support for Active-Backup NIC bonding.
  • SR-IOV Improvements. Improved scalability and certification with the SR-IOV Test Kit. Experimental SR-IOV with XenMotion support with Solarflare SR-IOV adapters.
  • Integrated Site Recovery (Disaster Recovery). Remote data replication between storage arrays with fast recovery and failback capabilities. Integrated Site Recovery works with any iSCSI or Hardware HBA storage repository.
  • Virtual Appliance Support (vApp). Ability to create multi-VM and boot sequenced virtual appliances (vApps) that integrate with Integrated Site Recovery and High Availability. vApps can be easily imported and exported using the Open Virtualization Format (OVF) standard.
  • VM Import & Export Improvements. Full support for VM disk and OVF appliance imports directly from XenCenter with the ability to change VM parameters (virtual processor, virtual memory, virtual interfaces, and target storage repository) with the Import wizard. Full OVF import support for XCP, XenConvert and VMware.
  • Enhanced Guest OS Support. Support for Ubuntu 10.04 (32/64-bit). Updated support for Debian Squeeze 6.0 64-bit, Oracle Enterprise Linux 6.0 (32/64-bit) and SLES 10 SP4 (32/64-bit). Experimental VM templates for CentOS 6.0 (32/64-bit), Ubuntu 10.10 (32/64-bit) and Solaris 10.

Note that XCP 1.5 is the open source edition of Citrix XenServer 6.0.

XCP 1.1 has landed!

The XCP team would like to announce that we have released XCP 1.1. I wanted to thank community members who have tested RC1 for doing so and wanted to let you know that no significant issues have been found. Thus, we promoted the XCP 1.1 RC1 release candidate to final release status: so if you’ve already installed the RC1 release, there is no reason to upgrade.

New XCP Features
Here are some features included in XCP 1.1:

  • Security updates and bug fixes
  • IntelliCache: Enables you to use a combination of Shared storage and local storage caching.
  • Local Storage Spans All Physical Volumes: When EXT local storage is used on a host containing multiple physical disks, the local Storage Repository (SR) now spans all the disks in a single LVM volume group.
  • Reset-on-boot VM behaviour: Disks with the on-boot option set to reset, is now available for disks in any type of SR. (Previously it was only available for disks in NFS and EXT SRs.)
  • Enhanced guest OS support: Support for Red Hat Enterprise Linux (RHEL) 6.
  • For OpenStack and others: support for ebtables and other netfilter options have been added to the kernel. These options have been disabled by default, but can be re-enabled with simple sysctl commands. These are the same kernel changes that will be included the upcoming XCP 1.5 release and have been included in XenServer 6.0.
  • The Xapi version override feature has been added back in. This allows users to effectively rebrand their XCP boxes as XenServer hosts, in order to work better with products such as XenCenter.

Thank you!
Thanks again to all our beta testers. And extra thanks to everyone for being exceedingly patient with our long beta period! We’re in the middle of revamping our internal build system right now. Once we finish this work, XCP releases should be easier for us to produce. This work will also allow us to produce development snapshots of XCP releases in between stable point releases, to allow people to test new features as they make it into XCP’s and XenServer’s mainline.

I hope everyone enjoys using XCP 1.1. Keep an eye out here for news on the upcoming XCP 1.5 release schedule!

New Docs!
Note that new XCP documentation has been written on the wiki: thank you to the community members who have contributed. In particular I wanted to thank Andrew Eross from Locatrix for the new XCP HowTo documents. We still need to create a nice and easy to use index for XCP docs, but in the meantime you can easily find the docs by searching for XCP.

XCP 1.1 RC1 Release

The XCP team would like to announce that, after a long time in beta, we’ve released XCP 1.1 RC1, which we hope will become our final release. Here is a list of issues that we’ve resolved since the beta release:

  • The license expiry bug has been resolved. This was the cause of the DMC issues reported in the beta, so those issues are resolved as well.
  • For OpenStack and others, support for ebtables and other netfilter options have been added to the kernel. These options have been disabled by default, but can be re-enabled with simple sysctl commands. These are the same kernel changes that will be included in the upcoming XenServer 6.0 release.
  • The Xapi version override feature has been added back in. This allows users to effectively rebrand their XCP boxes as XenServer hosts, in order to work better with products such as XenCenter.
  • It is possible to upgrade from XCP 1.0 to XCP 1.1 RC1, but it is not possible to upgrade from the beta to the RC.

Thanks to all the people who participated in the beta program, and who filed bug reports for us. It’s always really exciting for us hear from people who are using XCP, and we hope that this release is the best version of XCP yet.

Introducing Thomas Goirand, XCP packager

I’d like to introduce you to Thomas Goirand, who has volunteered to help us package the XenAPI toolstack for Debian as part of the Kronos project. Thomas is a Debian package maintainer and CEO of GPLHost. Thomas attended DebConf in Bosnia two weeks ago, where he did a great deal of work for the XCP-to-Debian packaging effort. We asked Thomas to write a short summary of his history with Xen, and his Project Kronos packaging efforts to date.

Hi my name is Thomas Goirand and I am CEO of GPLHost and Debian maintainer.
GPLHost has been providing a VPS hosting service based on Xen, since Xen 2.07 and we have been extremely happy with Xen. In particular on performance, stability and feature richness. When the idea of cloud computing started to take off, GPLHost was thinking about providing a cloud computing service. But we were in the same situation as in 2004/2005, when there was only UML as hypervisor and there was no open source technology that was fitting the bill. So when OpenStack started as a project, it was quite natural that we wanted to contribute and offer Openstack to our customers.

OpenStack development was one of the rare instances, where Debian was downstream of Ubuntu as OpenStack is developed on Ubuntu first, closely following the Ubuntu release cycle. One would think that Opestack code for Debian and Ubuntu is identical: Not true! About 2-3 dozens of patches were necessary to have OpenStack Nova, Glance and Swift ready for a Debian upload. Examples of differences are: Ubuntu uses upstart, when Debian uses insserv. As a consequence, init scripts had to be written nearly from scratch. Anyway, this work is done and OpenStack is available in Debian SID, as well as in our private repository for the Squeeze backport. By the way, I am searching for co-maintainers for these important packages.

In its current state, OpenStack can only be used with KVM as hypervisor, if you want to use Debian. You can of course use OpenStack with XCP, which is a CentOS appliance. But since I am a Debian developer and all GPLHost infrastructure is based on Debian, running an RPM based distribution is not an option. So I investigated if it is possible to package Xen-API (xapi) for Debian. The answers I got from both the OpenStack and xen-devel list were quite disappointing: XCP was, from the beginning, designed as an appliance, with many core packages being modified (kernel, lvm, and other libraries…). Porting it would be hard, because a lot of packages would have to be modified. This would make it quite difficult to port without the help of upstream XCP (yes, I’m talking about Citrix here).

Later, someone told me that my questions on public mailing lists sparked some internal discussion inside the XCP project which is led by Citrix. This led to the creation of project Kronos, whose goal it is to make Xen-API independent of CentOS and to also move away from an appliance only model. The first goal is to have a full Xen-API support for Ubuntu and that “apt-get install xen-api” would magically install everything. But the work would be done in Debian first and synched from SID to Ubuntu (which is part of the normal release cycle for Ubuntu). I was delighted. Of course, as Ian Campbell told me at Debconf 11, “it was ready to burst”, and I believe it would have probably happen anyway, even without me asking. Nevertheless, I am happy I asked at the time and am also happy to work on the packaging.

Anyway, the XCP project started porting their code from the CentOS XCP appliance. Since then, I started the packaging work, together with the help of “upstream” XCP (as in: Mike McClurg, Jonathan Ludlam, and others at Citrix in Cambridge).

Currently, the following packages are more or less ready:

  • libblktap
  • Xen 4.1.1 (modified current packaging to build the Xen OCaml libraries)

The following will still need to be built:

  • blktap DKMS package (since blktap wont ever make it to kernel.org)
  • xen-api-libs
  • xen-api

Even though I don’t really know much about OCaml, I know enough about Debian packaging to help out. And thanks to the help of Ian Jackson and Ian Campbell, who are both Debian Developers working on Xen and thanks to the OCaml task force at Debian who all agreed to review the packages, I believe it will be possible to create packages with good quality straight from the start. For those of you who never wrote packages (being RPM or .debs), you got to understand that writing quality packages is a tedious task and that it really improves quality to have more than a pair of eyes looking at the result.

Since DebConf 2011 we have the Linux 3.0 kernel available in Debian, including upstream kernel.org support for Xen dom0 (others have already blogged about the inclusion of the dom0 features in kernel.org for the 3.0 release). Thanks you to the Debian kernel team and in particular to Ben Hutching who did this one upload. With a little bit of extra effort, it will soon be possible to run XCP directly from Debian, with Xen 4.1.1 and Linux 3.0, all of which are available right now in SID. This means that this support should be available in Ubuntu as well: it looks we may be too late for Ubuntu 11.10, so we are working towards having XCP support in Ubuntu for the 12.04 LTS release (well, in my case, I’m working for Wheezy support, not for Ubuntu…).

All this is very exiting, and I am really looking forward to the work being done, for the first tests, with XCP first and then with OpenStack.