Bug 211592 - xen nautilus integration
xen nautilus integration
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: virt-manager (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Berrange
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-20 08:44 EDT by Matthias Clasen
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-27 12:16:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthias Clasen 2006-10-20 08:44:39 EDT
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.
Comment 1 Daniel Berrange 2006-10-27 11:27:58 EDT
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.
Comment 2 Matthias Clasen 2006-10-29 09:13:55 EST
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...
Comment 3 Daniel Berrange 2006-10-29 12:23:03 EST
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.
Comment 4 Dave Malcolm 2006-11-09 10:25:14 EST
How about simply inventing suffixes/filename extensions e.g. "foo.xen-image" and
"foo.xen-config" or somesuch
Comment 5 Daniel Berrange 2007-03-27 12:16:24 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.