Xen Roadmap

Xen Roadmap

[Ian Pratt]

We've now gone a fortnight without anyone reporting a bug in the 1.2
tree, so I think we can finally declare 1.2 as ready for official
release. Thanks to all those that provided bug reports, documentation
or feedback.

I thought it might be helpful to post a roadmap of where we're
planning on going with Xen development over the next few months. 

For Linux (and NetBSD) virtualization, I believe Xen offers a solution
that provides excellent stability, performance, security, and control
over resource usage. However, there are new features that we can add
that we hope will secure Xen's position as the "definitive open source
VMM" :


The Xen Roadmap Overview
========================

 * Bi-directional console. Currently VM console is output only, and
hence it's only possible to log into guests that are running sshd (or
telnetd etc). The new console facility will provide each domain with
one or more virtual serial ports, which can be accessed via a
'port server' in domain 0. [2 weeks]

 * "live migration". The 1.2 release supports suspend/resume migration
of domains, but we have are developing a 'live' migration feature that
will enable virtual machines to be moved beetween Xen hosts on a LAN
without having to stop the VM. [2 months]

 * New IO architecture. Drivers for block and network devices will be
moving out of Xen and into 'driver domains'. This will result in a
wider range of supported hardware (such as iSCSI etc) since it will be
possible to import drivers straight from Linux. It will also enable
greater flexibility in how IO requests are 'plumbed', enabling
transparent copy-on-write virtual disks, and more sophisticated
network firewalling and tunnelling. [3 months]

 * Enhanced QoS features. Xen already enables control over the CPU and
network usage of domains, but we plan to improve this support by
adding soft real-time scheduling capabilities to enable upper and
lower bounds to be set on a domain's resource usage.  Providing better
support for more accurate disk scheduling and accounting is on the
agenda too, as are more flexible memory usage controls [3 months]

 * Linux 2.6 port. Although most production servers are still running
2.4, we need to start thinking about transitioning to 2.6. We would
aim to make a strong case for the port's inclusion in the kernel.org
and vendor trees, having demonstrated a sizable user community. 
[2 months]

 * SMP guest operating systems. Xen has supported SMP hosts since the
1.0 release, but we're now moving toward support for SMP guests as
this is a necessary feature for some Enterprise Xen users. [5 months]

 * x86_64 Xen port. We have a design for a Xen port to AMD64/IA32e
which will support xeno-x86_64 guest OSes. [1 month from start]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

We'd love to hear from any experienced programmers who'd like to join
the core Xen development team, or otherwise contribute. 

We'd also be particular grateful for any help the user community can
provide writing and maintaining documentation, and also contributing
more sophisticated VM management tools (particularly with respect to
managing VMs across a set of hosts). Having more OS ports contributed
is always nice too ;-)

Thanks for your support.

Cheers,
Ian


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: Xen Roadmap

[Aniruddha Bohra]

Hi,
	I have a question regarding this :

>  * "live migration". The 1.2 release supports suspend/resume migration
> of domains, but we have are developing a 'live' migration feature that
> will enable virtual machines to be moved beetween Xen hosts on a LAN
> without having to stop the VM. [2 months]

	Does this live migration include migration of open files,
sockets, pipes etc ? Or is this limited to the process migration.
What I mean is :
	If I have a VM running a web server, and I try to migrate,
will I lose the connection, or will it continue seamlessly?

	Some other questions that arise if the above is true are:
1) If it does, will the client application/server application change
    in any way ?
2) How do the TCP bytestreams get synchronized after migration?
3) How big a state do you envision you would need to transfer ?

Thanks,

Regards
Aniruddha





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: Xen Roadmap

[Ian Pratt]

 
> 	Does this live migration include migration of open files,
> sockets, pipes etc ? Or is this limited to the process migration.

We mean migration of whole operating systems and applications
running in a VM. 

> What I mean is :
> 	If I have a VM running a web server, and I try to migrate,
> will I lose the connection, or will it continue seamlessly?

It should continue seamlessly.
 
> 	Some other questions that arise if the above is true are:
> 1) If it does, will the client application/server application change
>     in any way ?

No.

> 2) How do the TCP bytestreams get synchronized after migration?

When the VM migrates to a new host, the LAN switch/router is
tricked into sending packets for the VMs IP address to the new
host.[*]

Some packets could get lost in the changeover period, but TCP
will just deal with this in the normal way.

We could forward packets that arrive at the old host to the new
one for a period, but this is probably unnecessary in most
circumstances.

> 3) How big a state do you envision you would need to transfer ?

If the VM has xMB of memory in use, we'll have to transfer at
least that much [**]. However, it won't be transfered in one go, but
incrementally while the VM is still running. [The disk state is
another issue -- its probably best to either use a SAN, iSCSI or
an NFS filesystem]

Ian

[*] There are two ways of doing this (assuming same physical subnet).
 1) Have the new machine spoof an arp reply for itself to the
broadcast address
 2) Give the VM its own MAC address and migrate that to the new
host. The LAN switch will update its CAM when it spots the MAC
active on a new port.

[**] We could exploit para-virtualization and patch the guest
such that it prepares itself for migration by 'forking' itself
and then purging the buffer cache to minimise it's memory
footprint. It would probably just mean a whole lot more page
faults on the destination machine, though.


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: Xen Roadmap

[Woloszynski, Charles]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

Ian:

Thank you for the roadmap information.  I was wondering if this roadmap is
just for 1.3, or if it is a roadmap for features and the mapping to which
release will be done ala the kernel; when a feature is ready, it will be
added into the baseline?

It looks like a bunch of features all hit in about 3 months; is that linked
to 1.3 by any chance?  

My project is dependent on getting the L2 switching code into Xen so I can
use IPv6. Is this part of the new IO model or something else?  I did not see
it listed as a planned feature.

Thanks,

Charlie

P.S.  As you might be able to tell, I am now beginning to depend on Xen for
certain features in my project, so I am trying to make sure I know about
when they might arrive, so I can schedule time appropriately.

Charlie Woloszynski
Innovative Concepts Inc.
703-893-2007 x506 
charles.woloszynski@innocon.com


[-- Attachment #2: Type: text/html, Size: 1484 bytes --]

RE: Xen Roadmap

[Andrew Warfield]

> >  * "live migration". The 1.2 release supports suspend/resume
migration
> > of domains, but we have are developing a 'live' migration feature
that
> > will enable virtual machines to be moved beetween Xen hosts on a LAN
> > without having to stop the VM. [2 months]
> 
> 	Does this live migration include migration of open files,
> sockets, pipes etc ? Or is this limited to the process migration.
> What I mean is :
> 	If I have a VM running a web server, and I try to migrate,
> will I lose the connection, or will it continue seamlessly?

VM migration is not at all the same as process migration, and generally
avoids a lot of the hairy problems involved with the latter.  As the
thing migrating is an entire OS instance, things that are local to that
OS like pipes and file handles(assuming the file-backing is
NFS/xenostore) should continue to work just fine.  The only snag is the
open network connections.

As the initial plan is to support mobility within a single LAN,
connections may experience a blip(while the VM is actually switching
over), but should be able to continue just fine. The migrated host will
keep the same IP.

For beyond-the-lan moves, age-old mobility issues apply... you are at
the mercy of IP's lack of support for this sort of thing.

> 1) If it does, will the client application/server application change
>     in any way ?

applications don't need to change.

> 2) How do the TCP bytestreams get synchronized after migration?

TCP sees the same IP endpoint, although there could potentially be a few
dropped packets, the connections should cope fine though.

> 3) How big a state do you envision you would need to transfer ?

The OS instance has to move in its entirety, but the plan is to do much
of this transfer _while_ the original VM runs, and then to a small diff
and switch.  Should perform very nicely indeed.

a.


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click