> 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 ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users