Monthly Archives: July 2010

Xen Directions South America Agenda Announcement

Xen Directions South America is 1 month away and I am pleased to release the current agenda which is in final review with the event organizers and Linuxcon Brazil team.


I will be updating the event home page at with this agenda next week once it is finalized. I also will publish the speaker profile document at that time as well.

Looking forward to seeing everyone in Brazil next month.

Project ThreeEyes Officially Announced

Xen Community –

As you are well aware, over the past 2+ years I have made numerous changes to the website ( to make it easer to use for developers, users, researchers, journalists, customers, etc.  However, in that time I have not been able to change the underlying system to include content management, Web 2.0 integration, and other modern features found in websites. I am pleased to announce that I am starting a new project today to begin the complete overhaul of the website to include an open source platform such as Drupal with content management support, Web 2.0 integration, etc. This project is called ThreeEyes based on there being three main design goals – Integrate, Inform, and Interact.

The current project plan is Project_ThreeEyes and is ready for community review. Please send me any comments you have or post them as comments to this blog posting.

Yahoo! to use Xen for Cloud

From  Alessandro Perilli:

In a roundtable hosted by Association for Computing Machinery (ACM) that took place last month, the Vice President of Cloud Computing at Yahoo! Surendra Reddy revealed that the search giant is adopting the open source hypervisor Xen.

The information was provided during a discussion about the challenges of networking management inside cloud computing infrastructures:

We are moving to Xen and building a new data-center architecture with flat networks. We tried to use VLANs, but we have taken a different approach and are going to a flat layer 2 network. On top of this we are building an open vSwitch model placing everything in the fabric on the server.

My problem is in responding to the service requirements of my applications and addressing things such as latency and throughput. The data needed to address these issues is not available from either a network virtualization solution or the hypervisor.

Also, my uplink from the switches is 10 gigabits per second or multiple 10 gigabits per second, but my NICs are only one gig. If I run 10 VMs on a box, then all of the bandwidth aggregates on one or two NICs.

Request for Comment: Virtual disk configuration, PV vs. emulated, backward

Ian Campbell has proposed the following in xen-devel at

Currently the configuration syntax available in a domain configuration has several ways of specifying devices, some of which have slightly unexpected semantics wrt whether or not an emulated device is created, what the major number in xenstore is etc. Some also expose details of the guest OS’s choice of major number (or rather exposes Linux’s choice to all guests AFAICT).

In an attempt to clean this up, or at least make the strange behaviour more explicit, I’d like to propose some extensions to the dXpY syntax supported by libxl such that the other existing ways of specifying devices become syntactic sugar for specific well defined configurations in the new syntax, whilst preserving backwards compatibility.

I hope that the following will also form the basis for a future document (gasp!) describing the available syntax, which combinations are valid etc (unless someone can point me to an existing document I can update).

Virtual Disk Configuration

A virtual disk is defined in the guest configuration file as d<X>p<Y> where <X> is the disk number and <Y> is the partition number. In addition a number of options can be specified.

p0 indicates the entire disk.

Device number encoding in xenstore

Given a disk specified as dXpY the device encoding used in xenstore has two potential formats, legacy and extended. Both of these are already defined and implemented in guest frontend drivers. The extended encoding is generally preferred but for backwards compatibility the legacy format must still be supported.

The legacy encoding is (major and minor 8 bits each): (major << 8) | minor

The extended encoding is (disk == 19 bits, partition == 256 bits): (1 << 28) | (disk << 8) | partition

Note that the extended encoding for d0p0..d0p255 overlaps in the minor number space with the legacy encodings of d0p0..d15p15 and therefore these must not be used simultaneously.

Configuration Options

Each disk dXpY can optionally be followed by one or more of the following key value pairs (precise syntax TBD, but comma separated is common in similar situations).

Option keys and values with a _ prefix are for internal use only and are used only to provide legacy semantics for syntactic sugar and must not otherwise be used.

pv = true | false

Should a PV backend/frontend pair be created in xenstore to correspond to this device.

Default: true for HVM guests, ignored for PV guests (treated as true)

extended = true | false

Request use of extended device encoding in xenstore.

extended = false is only valid for d0..d15 (as d16+ cannot be represented in the legacy encoding)

When extended = false and in the absence of a specific _vdevice configuration option (see below) the encoding will use major==202 and minor==”(disk << 4) | partition”.

Default: false for d0p0..d0p255, false if _vdevice option present (see below), otherwise true.

emul = none | ide[01].[01] | _ide[01].[01] | …

none = No emulated device to be created.

ide[01].[01] = Emulate IDE device. First [01] => primary, secondary. Second [01] => master, slave

_ide[01].[01] = As per ide[01].[01] however emulation is enabled iff no other disk is explicitly configured with emulation.

In the future sata<X>.<Y> or similar might be added here.

Default: none HVM guests, ignored for PV guests (treated as none)

_vdevice = <N>:<M> | <Q>

Enforce use of legacy device encoding in xenstore with the given major:minor or explicit value.

Default: unset, encoding determined by “extended” option (see above)

Backward compatible disk configuration

Given the above configuration options several short hands are defined for backwards compatibility with existing configuration files and guests.

These will be implemented by a straight textual substitution before parsing the configuration.

hda => d0p0,pv=true,emul=ide0.0,_vdevice=3:0
hdb => d1p0,pv=true,emul=ide0.1,_vdevice=3:64
hdc => d2p0,pv=true,emul=ide1.0,_vdevice=22:0
hdd => d3p0,pv=true,emul=ide1.1,_vdevice=22:64

xvda => d0p0,pv=true,emul=_ide0.0,_vdevice=202:0
xvdb => d1p0,pv=true,emul=_ide0.1,_vdevice=202:16
xvdc => d2p0,pv=true,emul=_ide1.0,_vdevice=202:32
xvdd => d3p0,pv=true,emul=_ide1.1,_vdevice=202:64
xvde => d4p0,pv=true,emul=none,_vdevice=202:80

xvdo => d15p0,pv=true,emul=none,_vdevice=202:240
xvdp => d16p0,pv=true,emul=none

xvdz => d25,pv=true,emul=none

xvda[1..15] =>
xvdb[1..15] => etc

Note that all the above are Linux (guest) specific.

The sd* syntax is not covered. It’s unclear if this is used in the wild or what the existing semantics of emul= are for SCSI devices. If someone cares to investigate the existing behaviour then it can be added.

Otherwise it is expected that additions will not be made to this set of shorthands and that new functionality (e.g. emulation types) will be available only via the explicit syntax.

(is there any non-Linux specific syntax used by other guest OSes which needs to be supported?)

Implementation notes

The behaviour specified by the emul=_ide[01].[01] syntax is currently implemented by qemu (effectively as a workaround for users forgetting to specify any emulated disks). I propose that as part of implementing this new syntax we push responsibility for these semantics up into libxl.

libxl currently uses the legacy encoding for devices specified as xvd or dXpY iff the particular configuration can be represented using the legacy format (e.g. for d0p0..d15p15 or xvda..xvdp) in order to (1) avoid the clash between the extended representation of d0p0 and the legacy representations of d1..d15 and (2) to provide compatibility with guests which do not support the extended device encoding.

The proposal above suggests instead that d1+ should be encoded using the extended format unless overridden using the extended=false option or one
of the shorthands which uses the_vdevice option. Only d0 would default to legacy encoding.

This (1) avoids the clash in minor numbers since d0 is the only disk which can clash with legacy encodings and (2) provides compatibility with old guests through their use of the xvd* syntax.

XCP Documentation Update

I have taken down the Xen Cloud Platform Administrative Guide from the website for some maintenance. Several people have found some content that needed to be removed and I am having problems re-converting the updated XML file into pdf. The document will remain UNDER CONSTRUCTION until I can get a new pdf created. Please let me know if you are an XML expert and I can send you the updated copy for compile(?). Source Code License Change Request

A few weeks back, Ian Campbell and Stefano Stabellini proposed that some files in the community have their license changed:

The Xen source base includes two low level libraries (  and which provide low level services to toolstacks and  other components of the Xen system.

These two libraries are currently licensed under the umbrella of the top level COPYING file, i.e. GPLv2.

libxenlight has the aim of reducing maintenance burden across all  toolstacks and is rapidly gaining momentum as a common shared  implementation of core toolstack functionality. In order to maximise  the amount of sharing possible the decision was made to license  libxenlight under the LGPLv2. However libxenlight makes use of  libxenctrl and libxenguest and is therefore effectively GPL which reduces the opportunities for libxenlight to be used. Specifically this is a problem for libvirt bindings since libvirt is LGPL.

Therefore we would like to propose relicensing both libxenctrl and  libxenguest (i.e. the contents of tools/libxc) under the LGPLv2 and  libelf (xen/common/libelf, shared with tools and hypervisor) under a  dual GPLv2/LGPLv2 license.


At this time, I am happy to report that I have been in touch with all the developers who have worked on these files and have received approval for this change. Here is the current approval list:

Brendan Cully – Approved
Bryan Payne – Approved
Dave McCracken – Approved
Nguyen Anh Quynh – Approved
Shiram Rajagopalan – Approved
Tristan Gingold – Approved
George Coker – Approved
Hap9 – Approved

VA Linux – Approved
Intel – Approved
Fujitsu – Approved
Citrix – Approved
Oracle – Approved
Novell – Approved
Red Hat – Approved
AMD – Approved

We are in the final approval stages from Stratus, IBM, and HP as well as the following developers:

Bin Ren
Derek Murray
Geoffrey Lefebvre
Guy Zana
Jody Belka
Justin Gibbs
Kip Macy
Yuji Shimada
Michael Fetterman
Simon Kagstrom

If you are aware of any issues with this licensing change, please contact myself, Ian Campbell or Stefano Stabellini in the next two weeks as we intend to switch the license on August 11, 2010.