I think it would be very nice if nautilus would recognize xen images, and would have the natural default action for them, which is running a vm with that image.
This is pretty difficult to do. xen images, are either just raw block devices, or plain files mounted loopback to simulate a block device. The xen image itself is also useless without an associated config file. Unfortunately the config files are just a plain text file with key, value pairs, so not easily/reliably identifiable as a xen config file.
Thats a flaw in xen's design, I'd say. It would be much better if xen images would be a) selfcontained b) sniffable The sniffability could be worked around with EAs maybe. And since the config files live in a fixed place and point to their images, you could probably loop over the config files to find the one that belongs to the image in question...
Thinking about it some more, the xen images are actually block device images, rather than just filesystem images. Thus, we could actually probe the raw file image to see if it has a valid partition table in the first 512 sector, and then either try to find a matching config file from /etc/xen, or prompt to run it with a 'generic' VM config (say 500 MB ram, single net device) There are also some newer, but not widely used, disk image formats which are not simply raw devices - Xen can used the QCow format (from QEMU) and VMDK (VMware disk format) directly, so we can definitely find a way to sniff those. For config files we can definitely make sure they have sniffibility in the future - xen 3.0.4 development is about to switch to an XML based config file which should be trivial to detect from nautilus if we ensure upstream creates a sane DTD defined.
How about simply inventing suffixes/filename extensions e.g. "foo.xen-image" and "foo.xen-config" or somesuch
The raw VM image disk files are not a suitable format for use & distribution & nautilus integration because a) they do not contain appropriate corresponding config info b) the file format itself is not well suited - a 20 GB sparse file may only be 1 GB of actual allocation, but most tools do not cope wtih sparse files correctly, so end up copying around the full 20 GB c) for purposes of re-distribution the format should be agnostic wrt to the underlying format. ie I should be able to distribute a generic VM image, and when deployed it should automatically create the appropriate QEMU/KVM/Xen config & a disk image beit qcow, raw, parititon, etc. So, really this all requires a portable virtual appliance format, which is a idea that is being worked on by the ET management group as a project in its own right. Once a virtual appliance format is defined, then support can be added for nautilus & virt-manager integration.