cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <>
Subject RE: making VM startup more fine-grained
Date Fri, 01 Jun 2012 06:07:04 GMT
> 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.


> -----Original Message-----
> From: Chiradeep Vittal []
> 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

View raw message