I know that what I am requesting should merely require “apt-get install xcp-xapi” to accomplish. But let’s face it: Installing xapi on Ubuntu isn’t, and probably never will be, so simple. So how about offering a pre-built iso version for us?

And yes, I know that such a build probably wouldn’t meet the stability requirements of many current XCP users. So I’m not suggesting this as a replacement of the current XCP, but rather a “recurring beta” build useful for those who want to test the lasted version of xapi combined with the latest xen on the latest Ubuntu.

Of course, if you want to build a stable version based on the latest Ubuntu LTS, that would be great too. But for me, a recurring beta release, always based on the latest xen and the latest Ubuntu, would be preferred.

Currently, storage Xenmotion allows either a shut-down VM and its storage to be copied to a new location or live storage Xenmotion takes a running VM + storage and relocates it to a new server/pool/storage location and runs it there and stops the source. Why not also allow the source VM to continue running or the shut down VM to stay shut down and instead of migrating, allow a total copy operation and leave the target VM/storage shut down so as to create a perfect backup snapshot? For disaster recovery or keeping a perfect clone handy of a VM+storage, this would be ideal and involve very little code change to what already exists to accomplish.

Among other approaches, I’ve been using Virtual Machine Manager (Virt-Manager) to control VMs running under the vanilla Xen hypervisor, and that approach seems to work well with the XM toolstack. However, presumably because of some bugs with libvirt and/or libxl, I am not able to use Virt-Manager with the new XL toolstack. And judging from the libvirt forums, compatibility with the XL toolstack isn’t a high priority.

The above leads me to think that vanilla Xen needs its own GUI that can be used for controlling VMs using the new XL toolstack.

I’ll note know that Xen Orchestra has begun work to create a GUI for controlling VMs using the XAPI toolstack. However, at present, Xen Orchestra doesn’t seem to be developing a version for use with the XL toolstack. https://xenorchestra.uservoice.com/forums/187091-general/suggestions/3787827-xen-orchestra-xl-a-version-of-xo-that-interacts-d

One of the most frustrating thins in Xen in identifying what UUID matches what specific object, be it an SR, a PIF, VDI, etc. They are completely (almost) random. A number of bytes are really not used for any defined purpose (see, e.g. http://en.wikipedia.org/wiki/Universally_unique_identifier) and so the thought would be to use a prefix of sorts to identify the UUID role, such as A0, A1, A1, or A0, B0, C0, etc. You could further even put in a more identifiable date stamp so that you could sort UUIDS by date, e.g. 2013-July-27 14h 32m => 1307271432 = 4dfaa348. There are lots of interesting possibilities and this could of course be utilized in the UUID completion mechanism to everyone's advantage.

Even if PCI passthrough in XCP isn’t quite ready for primetime, please add to XenCenter (or some other gui based application) an intuitive mechanism for configuring PCI passthrough at least as an “experimental” feature for the the early adopters.

In may situation, although most of my VMs are non-graphical servers, I hope to add at least one VM that includes a full graphical desktop and has access to selected local hardware, including PCI slots, USB controllers, etc. So a more more intuitive approach for configuring PCI passthrough would be a huge help.

Yes, I now know (after spending lots of time searching) that PCI passthrough can be configured in XCP via the xe command line. But that approach is far from intuitive and is not very well-known.

I’ll just add that posts requesting how to configure PCI passthough in XCP are becoming increasingly prevalent: For example, see:

http://permalink.gmane.org/gmane.comp.emulators.xen.user/55047

http://www.gossamer-threads.com/lists/xen/api/262029 do=post_view_threaded