Virtualization Blog

Discussions and observations on virtualization.

XenServer 6.5 Can Do True UEFI Boot


We were interested in getting XenServer 6.5 to boot via UEFI.  Leaving servers in Legacy/BIOS boot was not an option in our target environment.  We still have to do the initial install with the server in Legacy BIOS mode; however, I managed to compile Xen as an EFI bootable binary using the source and patches distributed by Citrix.  With that I am able to change the servers boot mode back to UEFI and boot XenServer.  Here are the steps I used to compile it.


  1. Prepare a DDK
  2. Prepare a build environment
  3. Build some prerequisites
  4. Unpack the SRPM
  5. Compile Xen

DDK Preparation

Development will be done inside a 6.5 DDK. This is a CentOS 5.4-based Linux that has the same kernel as Dom0 and some of the required development tools. 

Import the VM template per Citrix DDK developer documentation.

After importing, set the following VM options:

  • 2 vCPUs
  • Increase memory to 2048MB
  • Resize disk image to 10GB
  • Add a network interface for SSH

Start the VM, set a root password, and then finalize resizing the disk by running:

# fdisk /dev/xvda 
cmd: d  -del
cmd:  n  -new
cmd:  p  -primary
cmd:  1  -num 1
	use default size
cmd:  w  -save

Preparing the Build Environment

Install rpmdevtools:

# yum --disablerepo citrix install rpmdevtools
# rpmdev-setuptree

I also needed several packages many of which were provided on the binpkg ISO from Citrix. I made them available by inserting XenServer-6.5-binpkg.iso and running the following:

# mount /dev/xvdb /mnt
# mkdir /opt/binpkg
# cp -a /mnt/domain0/RPMS/* /opt/binpkg
# cd /opt/binpkg
# createrepo /opt/binpkg
# cat >/etc/yum.repos.d/binpkg.repo

I also added the epel repository:

rpm -Uvh

and I added the following packages:


Building the Prerequisites

This page: says that it is required to use gcc 4.5 or better and that that binutils must be compiled with --enable-targets=x86_64-pep. I could not satisfy this with packages in the repositories, so I compiled and installed some requirements for gcc:

and made sure the required files could be found:

# export LD_LIBRARY_PATH=:/usr/lib:/usr/local/lib:/usr/local/lib64:/usr/lib64
# ln -s /usr/lib64/

then I compiled binutils using:

# tar xzf binutils-2.22.tar.gz
# mkdir binutils-build
# cd binutils-build
# ../binutils-2.22/configure --disable-werror --enable-targets=x86_64-pep
# make
# make install

then I compiled gcc I using: I adapted compilation instructions from:

# cd gcc-4.6.2
# sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/
# case `uname -m` in
i?86) sed -i 's/^T_CFLAGS =$/& -fomit-frame-pointer/' 
gcc/ ;;
# sed -i 's@./ true@' gcc/
# mkdir -v ../gcc-build
# cd ../gcc-build
# ../gcc-4.6.2/configure --prefix=/usr 
--libexecdir=/usr/lib --enable-shared 
--enable-threads=posix --enable-__cxa_atexit 
--enable-clocale=gnu --enable-languages=c,c++ 
--disable-multilib --disable-bootstrap --with-system-zlib
# make -j3
# ulimit -s 16384
# make -k check
# ../gcc-4.6.2/contrib/test_summary
# make install

Unpack the SRPM

At this point everything is ready to compile Xen as an EFI bootable binary.  The source code for Xen with Citrix's patches is available here: so download XenServer-6.5.0-source-main-1.iso and mount it at /mnt/cdrom:

# mount -r /dev/xvdb /mnt/cdrom

Now install the SRPM:

# rpm -ivh /mnt/cdrom/xen/xen-4.4.1- 

Compile Xen

The source code and required scripts are now all under /root/rpmbuild/, so just run:

# cd ~/rpmbuild
# QA_RPATHS=$[ 0x0020 ] rpmbuild -bc SPECS/xen.spec

The -bc flag causes the process to follow the spec file and patch the source, but then stop just before running the make commands. The make commands would fail to compile with warnings about uninitialized variables being treated as errors. Fix this by changing line 45 of ~/rpmbuild/BUILD/xen-4.4.1/xen/ to read:

CFLAGS += -Werror -Wno-error=uninitialized -Wredundant-decls

and line 39 of ~/rpmbuild/BUILD/xen-4.4.1/ to read:

HOSTCFLAGS = -Wall -Werror -Wno-error=uninitialized -Wstrict-prototypes -O2 -fomit-frame-pointer

after making those changes run:

# cd ~/rpmbuild/BUILD/xen-4.4.1/
# make clean
# make max_phys_cpus=256 XEN_TARGET_ARCH=x86_64 -C xen
XEN_VENDORVERSION=-xs90192 debug=n build

and the compile will finish successfully.  I probably could have just made a quick patch to add the -Wno-error flag and allowed the rpmbuild to run the full spec file, but I didn't actually need to compile xen-tools etc, those are already compiled and installed on the XenServer installation. The only file needed is ~/rpmbuild/BUILD/xen-4.4.1/xen/xen.efi. With that in hand I created a xen.cfg file like this:


options=console=vga,com1,com2 com1=115200,8n1,0x3F8,4
com2=115200,8n1,0x2F8,3 loglvl=all noreboot
kernel=vmlinuz-3.10-xen root=UUID=b4ee0ace-b587-41df-a66b-16f89731b2a8
rw ignore_loglevel acpi_rsdp=0x7B7FE014

where the root UUID is the boot disk created during the XenServer install and the RSDP number came from running:

# dmesg | grep RSDP

I ran that in an EFI booted live Linux environment. I found that some
vendors' UEFI implementations were able to provide the RSDP during boot
and some were not, so without specifying it in the xen.cfg I had trouble
with things like usb peripherals.

Boot XenServer

With the xen.efi and xen.cfg I was able to boot XenServer in UEFI boot mode using refind.  We have done extensive testing on several different servers and found no problems.  I was also able to repeat the process with the source code provided by the service packs up to and including Service Pack 1.  I haven't tried any further than that yet.

Editors Note

For those of you wishing to retain Citrix commercial support status, the above procedure will convert the XenServer 6.5 host into an "unsupported configuration".


Continue reading
8195 Hits

XenServer at FOSDEM

Having just released Creedence as XenServer 6.5, 2015 has definitely started off with a bang. In 2014 the focus for XenServer was on a platform refresh, and creating a solid platform for future work. For me, 2015 is about enabling the ecosystem to be successful with XenServer, and that's where FOSDEM comes in. For those unfamiliar with FOSDEM, it's the Free and Open Source Developers European Meeting, and many of the most influential projects will have strong representation. Many of those same projects have strong relationships with other hypervisors, but not necessarily with XenServer. For those projects, XenServer needs to demonstrate its relevance, and I hope through a set of demos within the Xen Project stand to provide exactly that.

Demo #1 - Provisioning Efficiency

XenServer is a hypervisor, and as such is first and foremost a provisioning target. That means it needs to work well with provisioning solutions and their respective template paradigms. Some of you may have seen me present at various events on the topic of hypervisor selection in various cloud provisioning tools. One of the core workflow items for all cloud solutions is the ability to take a template and provision it consistently to the desired hypervisor. In Apache CloudStack with XenServer for example, those templates are VHD files. Unfortunately, XenServer by default exports XVA files, not native VHD; which makes the template process for CloudStack needlessly difficult.

This is where a technology like Packer comes in. Some of the XenServer engineers have been working on a Packer integration to support Vagrant. That's cool, but I'm also looking at this from the perspective of other tools and so will be showing Packer creating a CentOS 7 template which could be used anywhere. That template would then be provisioned and as part of the post-provisioning configuration management become a "something" with the addition of applications.

Demo #2 - Application Containerization

Once I have my template from Packer, and have provisioned it into a XenServer 6.5 host, the next step is application management. For this I'm going to use Ansible to personalize the VM, and to add in some applications which are containerized by Docker. There has been some discussion in the marketplace about containers replacing VMs, and I really see proper use of containers as being efficient use of VMs not as a replacement for a VM. Proper container usage is really proper application management, and understanding when to use which technology. For me this means that a host is a failure point which contains VMs. A VM represents a security and performance wrapper for a given tenant and their applications. Within a VM applications are provisioned, and where containerization of the applications makes sense, it should be used.

System administrators should be able to directly manage each of these three "containers" from the same pane of glass, and as part of my demo, I'll be showing just that using XenCenter. XenCenter has a simple GUI from which host and VM level management can be performed, and which is in the process of being extended to include Dockerized containers.

With this as the demo backdrop, I encourage anyone planning on attending FOSDEM to please stop by and ask about the work we've done with Creedence and also where we're thinking of going. If you're a contributor to a project and would like to talk more about how integrating with XenServer might make sense, either for your project or as something we should be thinking about, please do feel free to reach out to me. Of course if you're not planning on being at FOSDEM, but know folks who are, please do feel free to have them seek me out. We want XenServer to be a serious contender in every data center, but if we don't know about issues facing your favorite projects, we can't readily work to resolve them.

btw, if you'd like to plan anything around FOSDEM, please either comment on this blog, or contact me on Twitter as @XenServerArmy.


Recent Comments
Tobias Kreidl
Thank you for sharing this, Tim. Some progress has already been made in being able to export VHD files and even VHD snapshots, so ... Read More
Monday, 26 January 2015 20:39
Felipe Franciosi
For those arriving in Brussels a day earlier, I'll be presenting at the CentOS Dojo and talking about Optimising Xen Deployments f... Read More
Tuesday, 27 January 2015 09:07
Tobias Kreidl
Tim, Would like to see a summary of your experiences and impressions at FOSDEM after it has concluded.
Sunday, 01 February 2015 15:54
Continue reading
9893 Hits

Post-Creedence details to be presented at Xen Project User Summit

Last month I posted seeking feedback from you our community on what the post-Creedence world should look like. The response was impressive, and we've started incorporating what you want in a virtualization platform into our plans for the next release of XenServer; occurring after Creedence. While it's a bit early to divulge those details, I plan as part of my session on Creedence at the Xen Project User Summit to give you a roadmap for what to expect, what the code name will be for the project, and how you can help move the project forward. There will also be a few other surprises at the event for XenServer attendees, so if are able to be in New York City on September 15th please do try and join us. Not only will you be able to see what the new XenServer has to offer, but you'll see what the core hypervisor community is up to and potentially push them to help deliver features you feel valuable.     

Recent Comments
Russell Pavlicek
And don't forget that the leaders of the Xen Orchestra project will be presenting at Xen Project User Summit too. If you've ever ... Read More
Tuesday, 26 August 2014 20:06
Tobias Kreidl
I would like to see XenServer/XenDesktop embrace similar technology to the VMware Project Fargo, where a clone on demand of a live... Read More
Saturday, 30 August 2014 15:00
Sam McLeod
Hi, will the talks be uploaded online after for those who can't attend? Thanks,
Thursday, 11 September 2014 04:13
Continue reading
10025 Hits

Whatever happened to XenServer's Windsor architecture?

b2ap3_thumbnail_Slide1.JPGAt the 2012 Xen Project Developer Summit in San Diego I talked about the evolution of XenServer's architecture, specifically our forward looking R&D work looking at a set of architectural changes known as "Windsor". The architecture includes a number of foundational overhauls, such as moving to a 64 bit domain-0 with a PVops kernel and upgrading to the upstream version of qemu (XenServer currently uses a forked Xen Project version and therefore doesn't benefit from new features and improvements made in the more active upstream project). Those of you following the development snapshots will have seen a number of these key component overhauls already.

The more notable changes in the new architecture include various forms of improved modularity within the system including "domain-0 disaggregation" as well as improved intra-component modularity and better internal APIs.

We wanted to do this for various reasons including:

  1. To improve single-host scalability (e.g. the number of VMs and the amount of aggregate I/O the system can sustain) by parallelizing the handling of I/O over a number of driver domains
  2. To enable better multi-host scalability in scale-out cloud environments, primarily by allowing each host to run more independently and therefore reduce the bottleneck effect of the pool master
  3. To create the capability to have additional levels of tenant isolation by having per-tenant driver domains etc.
  4. To allow for possible future third party service VMs (driver domains etc.)

So where are we at with this? In the single-host scalability area, something that Citrix customers care a lot about, we had a parallel effort to try to improve scale and performance in the short term by scaling up domain-0 (i.e. adding more vCPUs and memory) and tactically removing bottlenecks. We actually did better that we expected with this so it's reduced the urgency to build the "scale-out" disaggregated solution. Some of this works is described in Jonathan Davies' blog posts: How did we increase VM density in XenServer 6.2? and How did we increase VM density in XenServer 6.2? (part 2)

XenServer today does have some (officially unsupported) mechanisms to run driver domains. These have been used within Citrix in a promising evaluation of the use of storage drivers domains for a physical appliance running the Citrix CloudBridge product, performing significant amounts of caching related I/O to a very large number of local SSDs spread across a number of RAID controllers. This is an area where the scale-out parallelism of Windsor is well suited.

On the multi-host scalability side we've made some changes to both XenServer and Apache CloudStack (the foundation of the Citrix CloudPlatform cloud orchestration product) to reduce the load on the pool master and therefore make it possible to use the maximum resource pool size. For the longer term we're evaluating the overlap between XenServer's pool-based clustering and the various forms of host aggregation offered by orchestration stacks such as CloudStack and OpenStack. With the orchestration stacks' ability to manage a large number of hosts do we really need to indirect all XenServer commands through a pool master?

Disaggregation has taken place in the Xen Project XAPI toolstack used in XenServer. A prerequisite to moving the xapi daemon into a service VM was to split the higher level clustering and policy part of the daemon from the low level VM lifecycle management and hypervisor interface. From XenServer 6.1 the latter function was split into a separate daemon called xenopsd with the original xapi daemon performing the clustering and policy functions. In the network management part of the stack a similar split has been made to separate the network control function into xcp-networkd - this created immediate value by having a better defined internal API but is also a prerequisite for network driver domains. The current development version of the XAPI project has had a number of other modularity clean-ups including various services being split into separate daemons with better build and packaging separation.

b2ap3_thumbnail_demu.jpgWe're also using intra-component disaggregation for XenServer's virtual GPU (vGPU) support. A "discrete" emulator (DEMU) is used to provide the glue to allow the GPU vendor's control plane multiplexer driver in domain0 to service the control path parts of the vGPU access from the guest VM. This is done by, in effect, disaggregating qemu and having the DEMU take ownership of the I/O ports associated with the device it is emulating. This mechanism is now being added the the Xen Project to allow other virtual devices to be handled by discrete emulators, perhaps even in separate domains. Eventually we'd like to put the DEMUs and GPU driver into a driver domain to decouple the maintenance (particular required kernel version) of domain-0 and the GPU driver.

I view Windsor like a concept car, a way to try out new ideas and get feedback on their value and desirability. Like a concept car some of Windsor's ideas have made it into the shipping XenServer releases, some are coming, some are on the wishlist and some will never happen. Having a forward looking technology pipeline helps us to ensure that we keep evolving XenServer to meet users' needs both now and in the future.

Recent Comments
Tobias Kreidl
@James C: You can do that with Linux VMs -- and have been able to for years, it's just not supported by Citrix. We have run some s... Read More
Saturday, 03 May 2014 15:42
James Bulpin
We are looking at using the kernel mode block backend (blkback) for raw block devices, such as LVM (not LVHD) on SSDs and raw SAN ... Read More
Wednesday, 07 May 2014 16:47
Tobias Kreidl
We have done this for years on Linux boxes with directly-attached iSCSI connections, with significant performance gains. I wrote a... Read More
Saturday, 03 May 2014 16:10
Continue reading
20267 Hits

XenServer at the Xen Project Developer Summit

Last month Edinburgh was host to the latest Xen Project Developer Summit.  For those who attended, and for those who couldn't make it this time, the session recordings and presentations have just been posted.  The event saw content ranging from Xen on ARM and Xen in automotive infotainment, through to deeper discussions on fault tolerant system design and video display handling from a significant number of non-Citrix presenters.  Of course there were several XenServer related sessions, and I’m including the abstracts and links for them below.

“Unlimited” Event Channels

David Vrabel, Citrix

Event Channels are Xen's mechanism for paravirtualized interrupts. These were limited to only 4096 which then limits the number of guests that a host may support to around 300 to 500. This presentation will give a brief introduction to event channels, a detailed look at the new, innovative FIFO-based event channel ABI that increases the limit to over 100,000 as well as having several other useful features (e.g., multiple priorities). Some of the key performance measurements of the new ABI will be shown.

View presentation          View session recording

Test-as-a-Service and XenRT

Alex Brett, Citrix

In this presentation, Alex Brett will show how Citrix has constructed a Test-as-a-Service environment which is used by the wider XenServer engineering team, highlighting the benefits the approach provides, together with an introduction to the (recently open sourced) XenRT automation framework which powers it, and discuss how this could be applied within the Xen Project community.

View presentation          View session recording

Increasing XenServer’s VM Density

Jonathan Davies, Citrix

As the number of CPU cores in server-class hardware increases, the demand on a virtualisation platform increases for greater VM density. Most commercial virtualisation platforms now support several hundred VMs per host. This talk will describe the scalability challenges that were overcome in Citrix XenServer 6.2 to enable support for up to 500 fully virtualised or 650 paravirtualised VMs per host. These include limits with event channels, blktap, xenstored and consoled. It will also discuss how dom0 CPU utilisation was reduced in order to make a large number of VMs responsive and thus usable, and will present benchmark measurements quantifying these improvements.

View presentation          View session recording

Open Source Citrix Windows PV Drivers

Paul Durrant, Citrix

Citrix has recently spent several months making sure all the key parts of XenServer are open source. Part of this effort made the XenServer Windows Paravirtual (PV) drivers available in source form under a BSD 2 clause license on GitHub. Building these drivers outside of the internal Citrix XenServer build environment was quite hard and the resulting binaries would only run correctly in a XenServer host environment. I have recently spent many weeks modifying the drivers so that they should work on any recent upstream Xen host environment thus making it much easier for anyone outside of Citrix to build and deploy the drivers. I would therefore like to give a brief tour of all the drivers, their source, what each of them does, and how they all interact. I will also discuss plans for posting signed versions of these drivers onto Windows Update for general use by the community.

View presentation          View session recording

xenserver-core: What it is, How it is Built and How to get Involved

Euan Harris, Citrix

XenServer is open source and freely available, but it is packaged as an appliance image which must be installed on dedicated hardware. xenserver-core repackages the core components of XenServer so they can easily be built and installed on a standard Linux distribution. Its main goals are: * to make it easy to download, modify and build XenServer components, or just learn how they work; * to help upstream distributions to include up-to-date XenServer packages; * to provide an environment for experimentation. This talk will explain the motivations behind xenserver-core and how it relates to the open-sourcing of XenServer. For developers, it will cover how to get the code, how to build it and how to contribute back to the project. For packagers, it will explain the project's development and release processes and what an upstream maintainer can expect from it.

View presentation          View session recording

SecureServe: A Multi-level Secure Server Virtualization Platform on Xen

Jason Sonnek, Adventium Labs

Due to the rapid shift toward cloud computing, virtual desktop infrastructure (VDI) and thin client computing, many organizations in the government desire a high assurance, multi-level secure server virtualization platform that is low-cost, open and enterprise ready. In this presentation, Jason Sonnek will present SecureServe, a recently launched effort to develop such a platform by building on the open-source Citrix XenServer. The SecureServe project will draw upon research in a number of areas, including dom0 disaggregation, Xen Security Modules mandatory access controls and static/dynamic attestation. In this presentation, Jason will describe the project objectives and requirements, the project's relation to Citrix XenClient XT and XenServer Windsor, current development status and plans for moving forward.

View presentation          View session recording

Delivering Continuous Deployment of Xen-API at Cloud Scale

John Garbutt, Rackspace

Currently xen-api is really only installed today as part of XenServer. It has traditional enterprise style releases, with controlled upgrades and hotfixes when required. When deploying OpenStack Rackspace, with the help of the OpenStack community, have adopted an approach where any check-in could be deployed, and the system upgraded, from any other checkin from that last release, or earlier in the current release. It would be interesting to see if xen-api could move towards a model. At a minimum having more regular check points where an upgrade would be possible. When running a cloud, a very small amount of control plane downtime is possible, but ideally there should be zero downtime for user's virtual machines. We should explore the ability to only upgrade Xen as a last resort, but still be able to update as much the control and data plane as possible, while keeping VMs alive.

View presentation          View session recording

Multiple Device Emulators for HVM Guests

Paul Durrant, Citrix

Currently Xen only allows a single device emulator to be attached to each HVM guest in a system and, to date, this has been QEMU generally running as a process in the same domain as the toolstack, or in a stub domain. To enable the deployment of virtual GPUs to HVM guests in XenServer, patches were created to allow multiple device emulators to be attached to each HVM guest. QEMU continues to be used to emulate the majority of the devices, but a second process is spawned to handle the virtual GPU. This opens up the possibility of the GPU vendors supplying 'appliance' driver domains in future. I'd like to give an overview of the changes that we've made to Xen and QEMU to enable the use of multiple emulators, the potential benefits to driver domains, plus the knock on effect of emulator disaggregation on the 'unplug' protocol and what we could do about this.

View presentation          View session recording

Xen and XenServer Storage Performance

Felipe Franciosi, Citrix

The development of low latency storage media such as modern Solid State Drives (SSD) brings new challenges to virtualisation platforms. For the first time, we are witnessing storage back ends which are so fast that the CPU time spent in processing data significantly impacts the delivered throughput. This is aggravated by CPU speeds remaining largely constant while storage solutions get faster by orders of magnitude. To meet user demands and fully exploit SSD performance under Xen, new technologies are necessary. This talk will discuss the Xen storage virtualisation data path when using various back ends (e.g. blkback, tapdisk, qemu). It will explain why it is hard to exploit SSD performance with current technologies and present measurement data for a variety of workloads. Finally, it will show how techniques such as persistent grants and indirect I/O can help to mitigate the problem.


View presentation          View session recording

Recent comment in this post
Tobias Kreidl
Very interesting information, so thank you , Tim, for posting this. Above all, it is encouraging to see Citrix grabbing the stora... Read More
Monday, 30 December 2013 19:15
Continue reading
35794 Hits
1 Comment

A More Open Xen = A Stronger XenServer

[Originally posted on the Citrix blog by Tom McCafferty]

b2ap3_thumbnail_xen_project_logo.pngLast week, Citrix joined other industry leaders (Google, Cisco, Intel, Verizon) to create a collaborative open source project under the Linux Foundation to drive the future development of the Xen virtualization technology now named Xen Project. This is a significant development for the open source community at large, and was premiere news at the Linux Foundation Collaboration Conference earlier this month. The acceptance of into the Linux Foundation is also a testament to the dedication Citrix has put behind the Xen technology since acquiring XenSource in 2007.

Why make the move?
As we’ve moved into the Cloud Era, Citrix has found itself in the enviable position of having been the caretaker of the most successful hypervisor in the cloud. With Xen and XenServer now powering the majority of public cloud revenue in the world and growing interest as part of trend to low-power ARM processors, interest in Xen has been growingly rapidly.  This rapid project growth led the Xen project contributors to determine that the project and sub-projects would be better managed by a governing body like the Linux Foundation to provide the project a trusted, neutrally governed vehicle that can continue to drive its success.

The Linux Foundation is the natural home for this project as it is already home to a huge amount of industry collaboration and value creation, most notably with Linux but even more recently withOpenDaylight for the acceleration of SDN and the New York Stock Exchange led high performance Middleware Agnostic Messaging OpenMAMA project. Right out of the gate, big names have pledged their support to the new Xen Project. From mega clouds like Amazon Web Services, Terremark and Google, to leading advanced processor companies like Intel, AMD, and ARM/Calxeda, to virtualization platform providers such as Citrix and Oracle.

What does this mean for Citrix?
Xen provides the core hypervisor functionality for the XenServer virtualization platform which is a recognized industry leading solution used in datacenters around the globe. XenServer also provides the core platform technology for Citrix products like XenDesktop, NetScaler and CloudPlatform, which are powering thousands of clouds and thousands of datacenters today. With the creation of the new Xen Project and the guidance of the Linux Foundation, XenServer will now benefit from the development of other industry leaders along with informed input of the most demanding virtualization users on the planet.   Advancing the development of the underlying Xen hypervisor through better industry-wide collaboration strengthens our ability to ensure that XenServer will be a strong product and platform for future innovations as well.

This is an exciting time in the virtualization space where new opportunities and use cases are rewriting the rules for how a hypervisor should function and interoperate with datacenter infrastructure. Having an all-star cast of partners to work with on the newly dubbed Xen Project should provide all of the project supporters with powerful innovations that will shape the future of many of their respective open source and commercial efforts.  I for one am very excited about the impact this will have on Citrix XenServer and our users should be as well.

Stay on top of XenServer innovations with our Master Classes

Continue reading
15590 Hits

Transition from to XenProject

[Originally posted by Lars Kurth on the Xen blog].

This is just a quick note to you all, to outline the transition and timetable from the old main website to the new site. Other sites, such as,, and others will follow.

What will happen?

The site, will be moved to and all pages will clearly be marked as archived. We will redirect:

The intention is that web searches for xen and xen project will lead to the new website, while making sure that the old content is still available. Also, we want to ensure that linkx to will not be broken.

What has already happened?

We already created and set up the infrastructure for redirects. We also have a list of proposed redirects to We also removed all links to from

What is next?

We will be testing redirects on some of the less used pages in the coming days. Once we are confident, that all this works we will activate the redirects. The plan is to do this on June 8th.

How does this impact me?

Fundamentally, there should be no significant impact. If you check the Xen web pages regularly, you will be redirected to a corresponding new page or the archive.

If you have web real estate that links to, links will just be redirected to the new website. Although no links will be broken, you may want to …

  • Double check whether redirects go a location that matches your content
  • Ensure that links go to the new xenproject site (instead of the archived version)


If you are a vendor that is listed in the Xen Eco-system Pages, you are likely to see referrals from impacted. Thus, we would want to encourage you to create a new directory entries in the Xen Project Directory (which you can now do yourself, by creating a listing). We migrated static eco-system pages in the project and research categories (as these are more static). However we expect that other categories (Products, Consulting and Hosting) are owned (and changed as needed) by the respective vendors that provide a product or service.

Recent comment in this post
Can any one tell me free back up tools for XenServer 6.2.0 and also xendesktop..
Tuesday, 09 July 2013 12:07
Continue reading
6931 Hits
1 Comment

About XenServer

XenServer is the leading open source virtualization platform, powered by the Xen Project hypervisor and the XAPI toolstack. It is used in the world's largest clouds and enterprises.
Commercial support for XenServer is available from Citrix.