Hi Glenn, See comments inline:
Glenn Lagasse wrote: > Hi Rudolf, > > * Rudolf Kutina (Rudolf.Kutina at Sun.COM) wrote: > >>> The VMC project will need to define a 'base' if you will in terms of >>> installed packages for the virtual machine being created that can then >>> be built upon. I expect it's going to be pretty minimal (no X or >>> desktop for instance). I intend to look more into your JeOS work to get >>> a starting point for that base. >>> >> Well. We define then JeOS is OS building block for creating of >> Virtual Appliances and VM Templates. >> Preview of OpenSolaris 200906 JeOS will be available soon. >> >> What about some non-formal presentation of what we done as part of >> 200811/200906 JeOS creation process ? >> > > Sure, that'd be great. > > >>>> Reducing OpenSolaris (Part1: Approaches and Strategies) >>>> http://blogs.sun.com/VirtualGuru/entry/reducing_opensolaris_part1_approaches_and >>>> >>>> AI Live-CD environment must be created to allow perform common user >>>> tasks, so what will users do with VMC related Live-CD media when >>>> when they will "Drop to Shell" ? >>>> >>> I'm not sure I understand what you mean by when a user with VMC related >>> Live-CD media 'drops to shell'. The AI image that the VMC project is >>> going to use to create virtual machines is essentially going to be an >>> implementation detail to the user (for the most part). In the basic use >>> case, a user creating a virtual machine image will modify a DC manifest >>> and specify what packages they want installed, some install related >>> parameters and possibly a few virtual machine specific parameters (disk >>> size, networking settings, stuff like that) and then start the build >>> which will first generate an AI image and then create a VM and boot it >>> using the AI image so it can be installed and then export the VM. The >>> installation into VirtualBox will be an entirely hands off process >>> requiring zero interaction from the user creating a virtual machine >>> image (it has to be). So in the process of creating a virtual machine >>> image, there won't be any 'dropping to a shell'. >>> >> VMC Live-CD media is where all "install and customization" are >> performed, "Drop-to-Shell" on Live-CD can be simple just don't >> reboot after "all is done". But more valuable concept can be if >> "install" can work debug mode in similar way as today DC works. >> All install and post configuration parts executed in context of >> Live-CD can be represented as "steps", I can break in any of steps >> by "pause-continue" or restart execution from some "step" same way >> as we do now do it in NEW DC. This can very speed up creation of >> final fully unattended (automated) procedures. Many users of new DC >> see a concept of resumable "steps" most useful part of DC design. >> > > The approach we're taking for the VMC project is that the 'install' will > be handled by the AI client code. The AI media will be enhanced such > that it is bootable and start the AI client once booted automatically. > The AI client will then perform the installation inside the virtual > machine and once finished shutdown the VM. At which point the DC (which > has been monitoring the installation) will export the VM and stop. So > there won't be any 'drop to shell' or stepping. The entire process from > start to finish *must* be 'hands off'. A user will modify a DC xml > This is a target "The entire process from start to finish *must* be 'hands off'." and it must somehow achieved as part of development. We can automate, after we know what all steps need to be done to make a good Redistributable Virtual Appliance - not just simple installed VM , they are just fist step. There are more steps needed to make a good VM Creation then just pkg Install and Postconfig, for example step "reducing size of distributed image", which is very important in ZFS based installations, reducing can save 50% of occupied disk space and 70% of compressed size. Another can be distribution as ZFS stream (in FLASH images style) so users can install it at any disk size and/or virtual platform, while origin developer platform can still be VirtualBox. I try to make in VA Live-CD internal prototype this steps as sample modules (sample recipes) in context of 7 step VM building process, you can already look on some of them in (Internal Link for Prototype): OpenSolaris 200906 Virtualization Assistant Live-CD Prototype https://jsc-wiki.czech.sun.com/jsc-qa/wiki/TestingUnderVirtualization/BuildingAdvancedVirtualizationLab/OSOL0906JeOSVirtuaizationAssistantLiveCD I personally think then VMC project/product will not be successfully, if it will not allow to implement some sort "modules/plugins" which can user/developers share. "Modularity" - and resulted simple extendability is a main positive Lesson Learned from most successful internal community driven OS install framework in SUN "JET". R. > manifest describing what he wants to install in the VM (within the > constraints of the AI engine, currently) and then run the DC using that > manifest. > > Cheers, >
