DC to CUD Migration

DC to CUD Migration

This is the project page for migrating the Distribution Constructor to the Caiman Unified Design (CUD) architecture. As more information is available, it will be linked off of this page.

VMC Re-design Problem Statement and Proposal

Currently the VM constructor part of DC uses VirtualBox cli to construct VM images. This is all well and good except for the fact that the the vbox cli keeps changing rather frequently which results in breakages such as the following -

13237  Virtual Machine Constructor doesn't support building VM's with VirtualBox 3.1

https://defect.opensolaris.org/bz/show_bug.cgi?id=13237

Thus, it seems prudent to investigate an alternate way of generating VM images, one that doesn't rely on the vbox cli's as much.

Just recently, I did some experiments where I was able to -

a) Create a plain file and export it as an iSCSI target
b) Install OpenSolaris into that iSCSI target
c) After the install was done, take that installed instance encapsulated in a file and convert it into a VDI/VMDK with vdiskadm(1M)
d) Boot a vbox instance off of a text installer media and import the root pool contained in that VDI/VMDK *
e) Boot another vbox instance with the resultant VDI/VMDK

This effectively limits the use of vbox cli's significantly, it's only needed in (d).

 The installed root pool has the iSCSI device id embedded within it. So, when it is booted under virtual box (and it attaches to a different driver --
IDE/SCSI/SATA), the device id changes. This prevents the machine from being booted off of that root pool. The 'zpool import' in (d) is thus necessary to update device id appropriately before the VM can be booted under vbox.

Design Notes

Issues uncovered during development:

• Should DC checkpoints be allowed to call some of the common architecture classes directly?
  • Resolution - Consensus seems to be, yes, but this should be an 'exception' and not a rule. Most checkpoints should just use the Checkpoint interfaces
• Should the execution manifest specify the constructor method for the Checkpoint object being registered?
  • Resolution - yes, it should. The AI/DC execution schema will be re-arranged such that this is possible
• Manifest Parser invocation by DC and pause/resume
  • Resolution - still needs to be resolved.
• In what format will the Manifest Parser store the Manifest information - any generic DataObject types?
  • Resolution - Dermot is working on defining generic DataObject types (along with can_handle and from_xml methods) that can be used by the DC checkpoints

Use of Custom Script

Instructions on using the 'custom-script' checkpoint.