WikiAccueil > XEN dans la technique > Roadmap
| Temps | T12004 | T22004 | T32004 | T42004 | T12005 | T22005 | T32005 | T42005 | T12006 | T22006 | T32006 | T42006
|
| 2.0 | | | TESTING | STABLE | | | | | | | |
|
| 2.1 | | | | DEV | TESTING | STABLE | | | | | |
|
| 3.0 | | | | | | DEV | TESTING | STABLE | | | |
|
| 3.X | | | | | | | | | | | | |
Research Roadmap
In addition to the stable series, Xen is being used by a number of research projects which are investigating the opportunities provided by high-performance virtualization. These projects provide an ideal way to try out new features, but probably won't intercept the stable series roadmap for some time.
- Deterministic replay. Running in a virtual machine, it becomes possible to record lightweight checkpoints of guests OSes as they run, and log incoming events and interrupts. Thus, execution can be rolled back and replayed in a deterministic fashion. This is great for debugging, and can also be used to run two systems in lock-step to provide software fail-over.
- Shared buffer-cache and VM 'forks'. We have plans to investigate CoW memory sharing between VMs, as this can be useful for supporting large numbers of VMs e.g. in 'honeypot' applications. 'Forking' VMs could also be useful e.g. when starting a web browser applet that you want to ensure can't commit to persistent state.
- Multi-level secure Xen. Virtual machine monitors can have an important role to play in building multi-level secure systems. For example, one could use one VM for accessing a corporate network while browsing the web on another. A Mandatory Access Control system could be used to mediate the flow of data between the two.
- I/O interposition. The virtual I/O devices can easily be modified to simulate delay and loss, thus enabling a whole distributed system to be emulated in a virtual environment. Combined with deterministic replay this should result in a great tool for debugging distributed systems.
The Xen 3.0 Roadmap
- SMP guest operating systems. Xen has supported SMP machines since the 1.0 release, but we're now moving toward support for SMP guest OSes as this is a necessary feature for some Enterprise Xen users.
- x86_64 Xen port. A port to Opteron/EM64T is already in progress and will support xen-x86_64 guest OSes with both 32 and 64 bit applications.
- Other Xen ports. A port to IA64 is making good progress, and we'd like to see support for other architectures (such as ARM and PPC) added in due course. We intend to add support for x86 h/w virtualization extensions as information about them becomes available.
- 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 tools support for disk scheduling and accounting is important too
- Cluster management. We wish to add tool support to provide a better unified interface to managing a cluster of Xen machines. This would include features such as automatic use of VM live-migration to load-balance across a cluster, and the ability to 'evacuate' VMs from a node before shutting it down for maintenance etc.
- Better copy-on-write filesystem support. Although Linux's LVM snapshot capability can be used to provide CoW filesystem support it doesn't scale well. A custom approach should do rather better.
- Graphical control interface support. We need to develop a GUI for viewing and controlling resources across a cluster, either extending the existing web-based interface or developing a new GTK applicaiton.
The Xen 2.1 Roadmap
- Boot code restructuring. The next version of Xen will be even 'thinner', leaving more of the platform initialisation (PCI,IOAPIC,ACPI) to the domain 0 OS. This will enable us to benefit directly from improvements in the Linux initialisation code without having to track them in the Xen source.
- CPU load balancing. We need to add support to xend to periodically move VMs between CPUs on a node to re-balance load, taking hyper-threading capabilities into account.
- Improved Xserver hardware support. Some of the Xserver drivers normally supported under Linux don't currently work with Xen because they require vm86 (VESA) or agpgart (i815) support. This will be added in the next release.
- Improved cluster transparency. We wish to extend xend to make it more 'cluster aware' and hence provide better transparency of access to block devices and consoles when migrating guest OSes across a cluster.
The Xen 2.0 release
Annoncé le 05 Décembre 2004
Lien vers l'annonce
The Xen 1.0 release
Annoncé le 09 Septembre 2003
Lien vers l'annonce