Xen Roadmap/4.1 Feature Requests List

Xen 4.1 Feature Requests List

Here is the active Xen 4.1 Feature Requests

• Christian Tramnitz (christian'at'tramnitz.com) - secondary gfx passthrough support (incl. optionally loading gfx bios from file and optional pBAR-vBAR mapping)
• Xen developers - Resync/merge Xen qemu-dm with upstream Qemu to get all the new features and updates (including boot from SCSI/SAS emulated disks, newer HVM bios, pxe improvements, etc)
• Thomas Goirand [thomas@goirand.fr] - It'd be great to be able to do something like:

'exportpath:/var/mypath/myvps1,/,rw' so that the folder /var/mypath/myvps1 of a dom0 would be somehow exported to a domU as /. Both the domU and dom0 would have read/write access to it.

  NOTE: Work in progress as qemu for "paravirtual file system passthrough" 

• David Markey [ admin@dmarkey.com ] - port SPICE to Xen (http://spice-space.org/)
• Fantu [ fantonifabio@tiscali.it ] - Is possible give more support on windows domU, for example help with gplpv? Is possible include linux domU create tool, for example also only with recent version of more used distro with kernel vanilla already compiled with xen support? The xen api have all the functions are implemented and kept up to date or are semi-abandoned? if complete and updated can be update also manual?
• Jeff Sturm [ jeff.sturm@eprize.com ] - It would be nice if XenFS, or something like it, ever came to fruition. We've gotten by with clustered filesystems on our domU's, but these are a bit heavyweight in comparison.
• Ian Murray [murrayie@yahoo.co.uk] - xm save -c, but leaving the domU paused (e.g. xm save -p). This would allow a snapshot be taken of the storage and then the domU unpaused, for backup purposes.

I know this can be done with an xm save followed by a restore, but to me, it seem unnecessary and a waste of time (especially when time may be of the essence) to reload the domU's memory from storage when the mechanics are there to keep it in memory, i.e. as in a -c.

• T Johnson [tjohnson46@gmail.com] - Block device throttling/scheduling:

I have problems from time to time with guest VMs using up a lot more of my storage network than I would like. More than just priority scheduling, I would like to be able to tune how many read/write operations per second a VM can perform. Right now, without this ability on my storage network, I can end up having a VM that should be lower priority using up a lot of storage IOPS and starving everything else on the storage network.

In an ideal world I could specify that vmX can perform Y writes per second and Z reads per second (since sometimes reads can be less expensive than writes)

• Grant McWilliams [ grantmasterflash@gmail.com ] - These might not be wishes for 4.1 as some may be too big but they're my wishlist anyway. Note they also might not be things that belong to the Hypervisor but rather to tools associated with.
  • Make qcow2 actually work and include backing files.
    • If it can't be made to work then it should be taken out and not mentioned in the docs so we don't waste weeks trying to get it to work.
• Figure out why you can't start a VM with a disk image residing in a ramdisk (bug?)
  • Nesting [This item is being added to Xen 4.1 as patches are being submitted in early April 2010 - Community Manager]
    • As silly as this feature sounds it may be why I leave Xen for KVM. This would be useful for teaching management of VMs. A student could have a Dom0 and start up DomUs inside it without each on needing their own physical machine.
• Install PV DomU from CD without FTP/NFS tricks.
  • I don't care how it's done but it would be nice. The "install from network" shuffle can pose a complexity for people getting started in Xen. I'm aware that HVM does this because of it's use of Qemu but it would be nice everywhere. Maybe as Xen moves to Hybrid VMs instead of PV/HVM this will no longer be an issue.
• Vincent, Pradeep [pradeepv@amazon.com] - Multi-queue functionality in netfront/netbk drivers would be very useful in improving aggregate network throughput. This is complementary to leveraging VMQ functionality via Netchannel2.

For Dom-0 transmit queue logic, a simple mechanism to map physical NIC’s receive queues to Vif’s transmit queues and vice-versa would also be very useful and will help Dom-0 leverage NIC’s hardware based hashing functionality such as RSS and guest kernel’s transmit queue functionality for end-to-end network throughput enhancement.