Red Hat Bugzilla – Bug 211592
xen nautilus integration
Last modified: 2007-11-30 17:07:35 EST
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
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
Once a virtual appliance format is defined, then support can be added for
nautilus & virt-manager integration.