Volumes can outlive VMs but nics cannot. I like your idea in the other email. Break the StartCommand into two commands, a ConstructCommand and a StartCommand. That makes sense to me and would resolve this problem.
I think createVif and addVif support will depend on the hypervisor capabilities. Something we should develop for each hypervisor. --Alex > -----Original Message----- > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > Sent: Sunday, June 03, 2012 11:05 PM > To: CloudStack DeveloperList > Subject: Re: making VM startup more fine-grained > > This could work as well. > If volumes are prepared as part of CreateVm, is there a reason why nics > cannot be as well? Is it because the volumes are prepared before the > destination host is chosen? > > On 6/1/12 5:38 AM, "Murali Reddy" <murali.re...@citrix.com> wrote: > > >On 01/06/12 10:46 AM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> > >wrote: > > > >>A third way is to split the agent api into 2 commands: CreateVm and > >>StartVm. > > > >CloudStack already has two separate agent api commands for > >creating(CreateCommand) and starting (StartCommand) VM operations. > Not > >sure if any optimization influenced this but, unfortunately VM creation > >operations are spread across both CreateCommand and StartCommand > >implementations. So volumes for the VM are prepared as part of the > >CreateCommand and actual VM creation on Hypervisor, nic's for the VM, > >and ISO etc are created as part of the StartCommand. Also there is no > >state transition for VM from Created/Creating to Starting. If we have > >it, a pluggable service can register for state change and act on it. > >
