Even in this plan, the resource is required to have knowledge of someone wanting the know about the vif. I think Chiradeep's proposal is trying to avoid having the Resource itself changed.
To the original proposal, I think to break it down to that level makes it very difficult to manage. We can't dictate the apis on the hypervisors and to what level they actually support a api by api construction of a virtual machine. It works out well for XenServer but if a certain hypervisor supports only a XML based virtual machine description, then it won't work. Therefore, it's best to send down a machine description and let the resource do the translation. For the original problem, I don't think there's any way to get around the changing either the Resource or the hypervisor itself to implement that feature. I think XenServer team actually mentioned that they're willing to put in script callouts around vif being brought up and down and that might be one approach but we'll have to investigate what version it has been put into. --Alex > -----Original Message----- > From: Kelven Yang [mailto:kelven.y...@citrix.com] > Sent: Thursday, May 31, 2012 11:30 PM > To: cloudstack-dev@incubator.apache.org > Subject: RE: making VM startup more fine-grained > > Another way to state my point - don't let CloudStack orchestrators do micro- > management. It is impossible to handle every case cleanly if we do micro- > management at one level. Let these orchestrators behave like people > managers, > > Hey, this is the user's configuration (network config, CPU, memory, > disk etc), > This is what I have with my available facilities (physical > infrastructure), > We need to realize an execution plan (orchestration flow) > Chiradeep, I need you to work on the network (resource realization) > Kelven, I need you to work on storage (resource realization) > Do whatever you need to, you have access to the lab (service > callbacks) > but please fulfill the plan (try to keep high-level orchestration flow > intact) > > Kelven > > > > -----Original Message----- > > From: Kelven Yang [mailto:kelven.y...@citrix.com] > > Sent: Thursday, May 31, 2012 11:07 PM > > To: cloudstack-dev@incubator.apache.org > > Subject: RE: making VM startup more fine-grained > > > > > Another way is to modify the specific hypervisor resource to do > > something > > > just after creating the vifs but prior to starting the vm. > > > > I would go with this way. I'm proposing bi-directional communication > > between resource agent and the CloudStack kernel. Let CloudStack > > kernel only manage meta database for network configuration, > > virtual-to-physical mapping configuration etc, information that is > > generic, stable and independent of underlying resource realization > > technologies, Let resource provisioning orchestrators manage and > > orchestrate the process at flow- level, but leave the resource > > realization details to down-level components. If a down-level > > component needs to access the configuration data related with the > > operation, it calls back into the service API provided by CloudStack kernel. > > > > In this SDN example, the overall orchestration flow should not be > > affected by its implementation details, changes can be scoped at > > resource level if it has the access to the information it needs from > > common service API provided by CloudStack kernel. > > > > Kelven > > > > > > > > > > > > > -----Original Message----- > > > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > > > Sent: Thursday, May 31, 2012 10:17 PM > > > To: CloudStack DeveloperList > > > Subject: making VM startup more fine-grained > > > > > > I was helping someone with their integration of an SDN controller > > > with CloudStack. The requirement was that the SDN controller needed > > > the uuid of the virtual interface (vif) of the virtual machine so > > > that it could > > plug > > > it into the right softswitch, manage the vif etc. This vif uuid is > > > generated by the XenServer. > > > > > > My recommendation was to write a plugin (implement NetworkElement) > > > that would get the vif uuid after the vm started by making a XAPI > > > call (via the agent manager) and then call the SDN controller API > > > with this value. > > > The response: > > > "Unfortunately, the mechanism you describe wouldn't be sufficient > > > as > > we > > > would require the the VIF uuid before the VM boots, otherwise there > > might > > > be a race condition where sometimes VMs will boot up and lack > > > network connectivity and therefore might not even receive their DHCP > > > addresses and such. > > > " > > > Currently, when CloudStack starts a VM, all information regarding > > > the > > VM > > > (including nics and storage) is passed down in a single StartCommand > > > to the hypervisor resource. The hypervisor resource (e.g., > > > CitrixResourceBase or LibVirtComputingResource) takes appropriate > > > actions to create vifs > > and > > > plug them into the vm and start the vm. > > > > > > One way to solve the integration problem would be to split the > > > StartCommand into multiple commands: for e.g., CreateVif, > > > CreateVolume, CreateVm, StartVm. This changes the agent API and > > > affects all > > hypervisor > > > resources. > > > Another way is to modify the specific hypervisor resource to do > > something > > > just after creating the vifs but prior to starting the vm. > > > A third way is to split the agent api into 2 commands: CreateVm and > > > StartVm. > > > > > > Thoughts? > > > -- > > > Chiradeep
