Keith Mitchell wrote:
> Hi Joe,
>
> Almost everything looks good. I have one more comment on the issue
> below, however.
>
>>>
>>> 295-300: We blindly destroy an existing VM? Will first time users
>>> blow away their VMs when they give their VMC build name the same name
>>> as a current VM? Should we be using the --basefolder flag to create
>>> the VM in the DC build area instead of $HOME/.VirtualBox? (Especially
>>> since we're running as root to fire off DC...). If we did this, we
>>> might be able to handle my previous comment by unregistering an
>>> existing VM if it's not located in the DC build area (and of course,
>>> re-registering it when finished).
>>
>> Yes agreed. We investigated using --basefolder but did not have the
>> full success. We wanted to move forward and felt the likelihood of a
>> user being negatively impacted was small. We will use --basefolder in
>> phase II.
>>
>
> How will this behavior be documented? I think it's important to inform
> the user of this behavior and how to restore it. In this specific
> scenario, we could safely just delete the VM, but leave the virtual
> disks intact, which would mean that we're not destroying any data that
> can't be recovered (it's easy enough to recreate a VM and re-register
> the hard disks). Could you modify 'cleanup' to do so (or split it out to
> functions that destroy the VM and destroy the hard disks)?
>
> This would be additionally beneficial, as the cleanup code makes
> assumptions about the VM that are directly tied to how VMC creates the
> VM, not how a user might have set it up - for example, if a user has a
> VM named ${DIST_NAME} with multiple attached hard disks, cleanup will
> fail to destroy the VM (which means VMC will fail).
>
> Thanks,
> Keith
Keith and I have talked this through. Until the VirtualBox --basefolder
flag is used, by default, the VMC manifest "distribution name" will
contain "VMC": e.g. "OpenSolaris_VMC". A comment will be added to the
manifest describing that Virtual Box resources managed outside of the
VMC must not contain this same name.
Thanks Keith!
Joe
