[Lxc-users] LXC and OVF

[Walter Stanish]

> Is anybody using OVF (open virtualization format) with LXC for
> containers? Please let me know. Or any plans of making lxc-start/stop
> understand OVF format apart from the config file infe?

I am just a lurker dabbling in LXC (one of the lxc-gentoo authors),
and not an LXC kernel developer, but I found this quite interesting.
Thanks for the post.

(For others, there is some more concise info here:
 http://en.wikipedia.org/wiki/Open_Virtualization_Format )

On the face of it, OVF seems a more portable method
of achieving some of the same goals of libvirt
(See: http://libvirt.org/drvlxc.html )

Here are some notes from some time staring at OVF...

IMHO guest generation (lxc-* scripts) is a mess and
could benefit from adopting a standard that allows for the
specification of options such as guest network connectivity
in a non distribution-specific way.  OVF could be one
mechanism to achieve this.

However, there are some concerns with trying to use OVF:
 - XML based (IMHO this usually signals design overkill /
design-by-committee, but is not an immediate disqualifier for
implementation, more of a warning sign...)
    - Specifically, this will likely make parsing configuration with
the present bash-format lxc-* scripts an annoyance
 - Tailored toward hypervisor-based virtualisation ("Includes kernel,
so hypervisor-specific hardware drivers and virtual network
infrastructure and hardware resource requirements are the issues at
deployment time") rather than container based virtualisation ("No
kernel used, so virtual network infrastructure and hardware resource
requirements specification are the main issues at deployment time. On
the other hand, host kernel features must be compatible with the image
and there is no prebuilt means for this within OVF.") at present.
        - Quote: "Ideally, the appliance vendor will create a virtual
machine that has device drivers for the virtual hardware of all of the
vendors desired target virtualization platforms."
    - On the plus side, with some effort OVF should be flexible enough
to support both paradigms.
 - Externalises and thus duplicates some of the virtual-system's
configuration information that may or may not exist, and may or may
not be in sync with what's actually inside the virtual machine (eg:
hostname, IP, subnet, gateway, dns servers, etc.)
    - Unclear if this is a requirement or not, which direction config
tends to move, where OVFs come from
 - Unclear whether IPv6 is supported
    - No IPv6 in examples
 - Lots of data duplication in the provided examples, eg:
"<Info>Virtual Hardware Requirements: 256MB, 1 CPU, 1 disk, 1
NIC</Info>" is followed by the same thing with more specificity over
30 lines. If the provided examples ("the best they can make it look")
suck, then it makes you wonder what a particularly bad OVF example
might look like...
 - Lots of critical areas of complex virtualised systems deployment do
not yet appear to have been tackled.
    - inter-machine (startup, runtime) dependencies
    - virtual network bandwidth requirements
    - disk IO (throughput) requirements
    - internet sychronisation requirements
    - processor architecture requirements
    - ...etc.
 - Lack of realistic high-availability / cluster management
considerations. The documentation seems to assume static
infrastructure deployment.

Nice features of OVF:
 - binary resources such as disk/filesystem images can be referenced
within the XML via HTTP within the specification, making it easy to
distribute small, text-only machine specifiers that are still good for
deployment (assuming network connectivity)
 - supports any disk format (future proof)
 - built-in multilingual string support (i18n)
 - capacity to smooth the migration path from legacy container-based
virtualisation systems to lxc

Implementation requirements:
Roughly speaking, in order to support deploying (not creating) an OVF,
new lxc-related software would need to perform the following steps:
   1. Validate the OVF's integrity
   2a. Some OVF's require that you ask the user to verify/customise
hardware resource allocation, possibly within a fixed range (eg: MB's
of memory)
   2b. Check OVF compatibility against available local hardware and
software resources
        - CPU architecture
        - network connectivity paradigms
        - potential binary filesystem/disk image format conversion/decompression
   3. Request user to confirm deployment, possibly showing license information
   4. Allow the user to match OVF-requested networks against existing
virtual and physical networks
   5. Allow the user to provide other information such as networking
information, hostname, etc. that the OVF requests.  It is unclear how
this information, with the exception of virtualisation system
inflicted guest configuration (such as hostname, IP, etc.), may be
passed to the resulting container.
   6. Create a new container
   7. Assign OVF's required resources to the container

Personal feeling (may be wrong):
Probably lxc is not quite at the point where a clear
integration could be made.  This is because there were
(last time I checked, couple of months back) still a
number of issues around more basic network configuration
(eg: ability to push routes to a container from lxc) that
prohibited the full externalisation of even basic config.
Because distributions tend to have their own manner of
configuring static networking information, this seems to
have led to a temporary workaround practice whereby
people either manually configure nodes or deploy using
DHCP.  However, OVF itself appears to assume the
capacity for the virtualisation system to inflict a desired
configuration on the virtual environment.  (Perhaps a
specific, guest-readable, host-writable file made
available to the container could be used to provide
this configuration to the guest at boot time?  Via /proc?)

- Walter