> 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?
It depends on whether or not nics are first or secondary class objects in the hypervisor, being first class object means that it can be created and managed in its own life cycle. In certain hypervisors, nics may only be created along with the VM. Kelven > -----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. > >
