Hi All,
As promised here is a diagram of the overall VM construction process
that I outlined in my design notes. I apologize for it's
text centered-ness, but after having OO Draw core on me a few times I
gave up with the fancy and went with the functional.
I'd be more than happy to discuss this at our tuesday meeting, over the
phone, email, whatever works for people. If there's something(s) that
aren't clear, please don't hesitate to bring them up and I'll do my best
to clarify. Hopefully this helps in understanding my design.
Thanks!
--
Glenn
-------------- next part --------------
Definitions:
DC - Distribution Constructor
Host - refers to the machine that is running VirtualBox
Guest - refers to the OS *virtual* machine running in VirtualBox
PVMC - Portable Virtual Machine Construction ISO, this refers to
the new ISO type that we're creating to perform hands-off
installations inside a running Guest.
Appliance - refers to the resulting installation inside VirtualBox
OVF - refers to Open Virtualization Format, which is the format of the
Guest's Virtual Disk that we'll be supplying to users.
Stage 1: (HOST)
DC (running on the HOST) creates a PVMC ISO based on a standard manifest
(similar to slim_cd but with a much smaller package/feature set, ie no windowing
system, gnome, etc. Just enough OS to boot, launch DC via SMF and produce an
installation inside the Guest). This manifest will include the addition of the
distro constructor packages as well as a reference to a separate 'installation
manifest' which the DC running inside the Guest will use to perform the
installation inside VirtualBox. This 'installation manifest' will in some ways
be similar to the slim_cd manifest. Most importantly it will allow the operator
creating the PVMC ISO to specify a custom package list tailored to whatever
requirements are needed for the resulting appliance.
Stage 2: (HOST)
DC configures a Guest VM inside VirtualBox via the VirtualBox CLI, setting
things such as memory and networking and disk size. It will also configure the
Guest to boot using the PVMC ISO created in Stage 1.
Stage 3: (HOST)
DC starts the Guest (again via the VirtualBox CLI) and then begins 'polling' the
Guest's status in order to determine when the Guest has shutdown after it's
installation has completed.
Stage 4: (GUEST)
The Guest boots up off of the PVMC ISO and sets up networking and other standard
things just like any other boot process. At the end of the boot process (just
before console login) an SMF method will execute that starts DC inside the
Guest.
Stage 5: (GUEST)
DC (running inside the Guest) configures a root pool using the Guest's
virtual disk (which it will need to figure out what the disk is called). It
then proceeds to populate and configure that root pool based on the installation
manifest which was included during construction of the PVMC ISO. The process in
some ways will be similar to how the slim_cd is constructed (minus the iso and
usb creation steps). Packages will be downloaded from a repository (specified
in the manifest) to the root pool. Additional configuration to make the root
pool bootable as well as turning it into a proper installation will also be
performed.
When installation/configuration of the appliance is completed, DC will shutdown
the guest (init 5).
Stage 6: (HOST)
Having detected that the Guest is now shutdown (via the aforementioned polling),
DC will now prepare the Guest's Virtual Disk to be exported so that it can be
distributed as a portable appliance to users. This is done via VirtualBox's
VBoxManage CLI (as most of the interfacing between the HOST and VirtualBox is
done) to export the Disk as an OVF file.
Once complete, DC stops and the run from start to finish is complete. We should
now have an OVF file that we can distribute to users running VirtualBox which
they can import and boot into and not have to perform any sort of installation
in order to be up and running. We also have the PVMC ISO which is kept that can
be used to replicate the installation in VirtualBox in case hands-on diagnosis
of the construction process is required.
In theory, the PVMC ISO could also be distributed to anyone who wanted to have
the capability to repeat the appliance installation either on some other
Hypervisor (xVM, Microsoft's Hyper-V, VMWare) or even some other piece of real
hardware. Although, since we're exporting our appliance via OVF any Hypervisor
that supports OVF should (in theory) be able to just import our OVF file (though
OVF doesn't guarantee that type of support in the spec).
Longer term, I'd like to enhance this entire concept to make the PVMC ISO a
generic auto-installation ISO. Such that we can distribute the ISO and users
can supply their own 'installation manifest' when they boot the ISO (instead of
the manifest being included on the ISO itself). For instance, having a manifest
on a HTTP server that DC could pull and use. This concept would be very similar
to what Anaconda's KickStart mechanism allows. This is not a goal for the
initial design however.
