Hi Glenn,
this is pretty interesting stuff - I have couple of generic
thoughts/comments which are perhaps more related to the long
term solution.
I might have misunderstood some points, please feel free to
correct me, if my thoughts went astray too much :-)
Thank you,
Jan
Glenn Lagasse wrote:
> Preliminary design outline for generating pre-constructed virtual
> machine disk images via Distro Constructor.
>
> Purpose:
>
> To be able to construct a virtual machine disk image via the Distro
> Constructor in a 'hands-off' manner given an arbitrary set of packages
> for the purpose of distributing the disk image as a pre-installed
> OpenSolaris environment.
>
> While we're primarily targeting VirtualBox for the constructed disk
> image we should be able to support other hypervisors that support the
> Open Virtual Machine Format[1] which is what we'll use for the
> constructed images.
I have just taken a quick look at OVF spec and it seems it is pretty
generic and sophisticated container for virtual appliance serving for
"packaging and distribution of (collections of) virtual machines."
If I understood correctly, the standard itself doesn't introduce
new open format of virtual disk image. However, it allows to encapsulate
within OVF any existing or future format of virtual disks (vmdk, vdi,
qcow2, ...). Might it be correct ? If this is the case, are we
going to support only those recognized by VirtualBox or more formats
will be taken into account, as the goal is to produce OVF which
could be deployed on other hypervisors ?
If the goal is to deploy OVF on other hypervisors (xen, vmware, ...),
it seems that there might be a need to teach DC to understand and
manipulate OVF (e.g. by consuming some standard API) in order to
be able to define and specify in OVF what hypervisors are to be
supported along with set of supported hardware and OVF portability level:
1 - Only runs on a particular virtualization product and/or CPU
architecture and/or virtual hardware selection.
2 - Runs on a specific family of virtual hardware. This would
typically be due to lack of driver support by the installed
guest software.
3 - Runs on multiple families of virtual hardware. For example,
the appliance could be runnable on Xen, KVM, Microsoft, and
VMware hypervisors.
What is the final goal as far as OVF portability level is concerned ?
It seems it might be interesting (but not easy to accomplish) to support
creating OVF level 3 images.
>
> Premise:
>
> We can use Distro Constructor to perform an automated, hands-off
> installation of OpenSolaris inside VirtualBox controlled from a Host
> system running Distro Constructor.
>
> To support this premise, we will need to create a new output image type
> for Distro Constructor which we'll call the Portable Virtual Machine
> Construction Appliance. This new image type will be a slimmed down
> version of the OpenSolaris liveCD which contains just enough operating
> system to boot, run Distro Constructor with a supplied xml manifest and
> successfully generate an installation inside a virtual machine on a
> virtual hard disk in a 'hands-off' manner.
I would agree this is good approach for proof of concept, since there
is a set of specific problems which are mitigated by running DC in native
environment, but I am thinking if for long term solution this intermediate
step might be omitted.
Have we identified what issues would arise if we would like to let DC
generate virtual appliance package directly on host system without running
Virtual Box ? I remember there were couple of them mentioned during meeting
yesterday.
[1] running DC in native environment addresses the problem with differences
between host and guest HW.
With respect to this point, what particular problems we are going to
encounter if the image is build directly on host system ?
I am asking, since it seems we already crossed the bridge, when we use
DC for building LiveCD and AI images - for instance Sparc image built
on Ultra45 is supposed to work on all sun4v and sun4u machines with
wanboot support. The similar is expected from x86 AI or LiveCD image.
It seems that Solaris is pretty flexible in this point.
There is known issue with ZFS portability - there is already filed
bug for this and I think we might assume it will be addressed,
since there are other parts affected by this.
Do we happen to know if there have been other problems identified
in this area so far ?
Also, when DC is run within VB, how it would guarantee that the
image might be deployed on other hypervisors ?
[2] Solaris can't mount virtual disks
Solaris can't mount virtual disks directly at this point, but
it seems that there might be ways to go. For instance, XEN
vdiskadm(1M) tool can convert raw disk image into different
types of virtual drives:
http://docs.sun.com/app/docs/doc/819-2240/vdiskadm-1m?a=view
http://opensolaris.org/jive/thread.jspa?threadID=98762&tstart=0
Based on this, DC could install into lofi mounted file or ZVOL
and convert the final raw image into vmdk or vdi using vdiskadm(1M).
I am not sure if there is a limitation that vdiskadm(1M) has
to be run within dom0, but if this is the case, then I think
that it might be enhanced in such a way that when called for
creating/converting the disk, it might not be necessary.
If it would turn out that this approach is not suitable as final
solution, the possibility might be to teach lofi(7D) driver to
understand virtual disk image formats directly.
[3] There might be other issues I have forgotten :-)
>
> This image can include an xml manifest (supplied by the operator) which
> outlines what the installed image should contain (similar in nature to
> the slimcd manifest). Optionally, I'd like to construct this image in
> such a way as to be able to read a manifest from some arbitrary location
> (NFS, HTTP, FTP, USB) during startup if possible. This would increase
> the flexibility of this image in that you wouldn't have to regenerate it
> if you wanted to just change the definition of the installed image.
> This means that the Portable Virtual Machine Construction Appliance iso
> will not contain an installation payload like the liveCD. Instead it
> will pull packages from an IPS repository specified via the new xml
> manifest mentioned below.
>
> We will also need to enhance Distro Constructor to perform an
> 'installation' inside a virtual machine via a new xml manifest which
> outlines what to install (somewhat similar to the process for
> constructing the OpenSolaris liveCD).
>
> HOST machine requirements:
>
> o Running OpenSolaris
> o Up-to-date copy of SUNWdistro-const
> o Up-to-date copy of VirtualBox (or at least the version you want to
> generate an image for) that supports OVF
> o Network access to an IPS repository
> o Sufficient memory to run a VirtualBox guest in addition to the Host OS
> o XML manifest outlining what the constructed virtual machine should
> contain and how it should be configured
>
> Construction Process outline:
>
> 1. Create an xml manifest used by Distro Constructor to install the
> VirtualBox guest
> 2. Generate the Portable Virtual Machine Construction Appliance iso
> 3. Configure a virtual machine in VirtualBox via Distro Constructor
> to be used as the installation target
> a. will need to configure a valid network configuration such that the
> virtual machine can access the IPS repository specified in the
> manifest
> 4. Boot the virtual machine with the Portable Virtual Machine Construction
> Appliance iso
> 5. Distro Constructor performs an installation inside the virtual machine
> according to the supplied xml manifest.
> a. will need to perform some type of validation of the supplied
> manifest (valid IPS repo for instance)
> 5. Export the virtual machine disk image from VirtualBox so it can be
> distributed
>
> -----------------------------------------------------------------------
>
>
