I'm submitting this case for John Levon. The timer is set for September
22nd, 2008. In addition to the spec included below, a draft
virt-convert(1) man page is in the materials directory.
???1. Introduction
This case introduces a new command-line utility, virt-convert(1).
A patch binding is requested.
2. Discussion
A number of virtualization solutions exist today where some form of
mobility is possible: that is, the guest VM can be moved between
different v12n platforms. This usually requires at least one conversion
step, as there is not yet a widely-accepted standard defining the state
and configuration of guest VMs.
To date, administrators have been forced to do this by hand, often
involving writing configuration files by hand based upon the existing
config file in the old format. This is obviously less than ideal, as it
creates significant scope for administrative errors and non-recommended
configurations.
virt-convert(1) fills part of this gap. Its usage is as follows:
usage: virt-convert [options] inputdir|input.vmx [outputdir|output.xml]
options:
-h, --help show this help message and exit
-q, --quiet Don't be verbose
-a ARCH, --arch=ARCH Machine Architecture Type (i686/x86_64/ppc)
-d, --debug Print debugging information
-i INPUT_FORMAT, --input-format=INPUT_FORMAT
Input format, e.g. 'vmx'
-o OUTPUT_FORMAT, --output-format=OUTPUT_FORMAT
Output format, e.g. 'virt-image'
-D DISK_FORMAT, --disk-format=DISK_FORMAT
Output disk format
-v, --hvm This guest should be a fully virtualized guest
-p, --paravirt This guest should be a paravirtualized guest
--os-type=OS_TYPE The OS type for fully virtualized guests, e.g.
'linux', 'unix', 'windows'
--os-variant=OS_VARIANT
The OS variant for fully virtualized guests, e.g.
'fedora6', 'rhel5', 'solaris10', 'win2k', 'vista'
--noapic Disables APIC for fully virtualized guest
(overrides value in os-type/os-variant db)
--noacpi Disables ACPI for fully virtualized guest
(overrides value in os-type/os-variant db)
(see also the man page in the materials directory).
This utility was based on a prototype utility from the upstream
virt-install project and follows that project, with some additions as
noted below.
Typical usage involves passing in the configuration file of the input VM
instance, and asking for output in a format understandable by virsh(1).
3. Input/output formats
Currently, virt-convert only supports .vmx format input files, as used
by the VMWare suite of v12n products. Furthermore, support is limited in
that the format is very poorly defined, and not all configurations will
understood correctly.
The upstream project only supports one output format known as
"virt-image". This is a well-defined XML format:
http://hg.et.redhat.com/virt/applications/virtinst--devel?f=c875e58baae9;file=doc/image.rng;style=raw
This is not yet consumed by anything supported in Solaris xVM, however.
As a result, our version of virt-convert also supports the file format
supported directly by virt-install(1m), known as 'virt-instance':
http://libvirt.org/libvirt.rng
Since this format is seen as legacy by the upstream project for such
circumstances as described here, upstream will not support this format.
A future case expects to introduce virt-image(1) which will use the
first format.
Currently, only raw and VMDK format disks are directly supported, though
this is expected to change later. Where necessary, disk conversion is
performed. In particular the assumption is that the target format is
going to be using vdisk (see references) for handling the disk images.
4. VMWare Appliances
Appliances are typically composed of a zip file, which when unzipped
consists of a bunch of disks and a .vmx config file. To easily support
conversion of such appliances, virt-convert accepts a directory path as
input. In such a case, the dir is searched for a config file and a
converted output file is placed in the same directory. Where possible,
the disk storage for the VM is not copied, but left in place.
Usually such configuration files use relative paths to the disk storage,
which are left in place during conversion. There is thus a dependency on
virsh(1)s --relative-path option (see references).
5. Limitations
Aside from the limited number of formats currently supported, as
described above, there are a number of other limitations. The primary is
that virt-convert automatically assumes that the output should be using
IDE disks. Often input guest VMs are expecting SCSI disks. Whilst this
is not directly related to virt-convert itself, it does imply that many
guest VMs won't boot without further administration: in particular
Windows, Solaris, and older Linux implementations all suffer from this
inflexibility.
This failure manifests itself as a failure to boot when the converted VM
is started.
6. Interface table
Note that all of these interfaces are imported from the community
upstream; their classification represents our best guess as to their
community status and our intentions to track them.
virt-convert command line Uncommitted
virt-convert output Not-an-interface
virt-instance output format Uncommitted
VMX input format Volatile
7. References
6715640 would like a vmware appliance conversion utility
PSARC 2006/260 Solaris on Xen
PSARC 2008/XXX vdiskadm
PSARC 2008/577 Libvirt APIs for relative paths
