cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: making VM startup more fine-grained
Date Fri, 27 Jul 2012 01:13:53 GMT

On 7/25/12 10:52 PM, "Ishimoto, Ryu" <> wrote:

>On Mon, Jun 4, 2012 at 3:02 PM, Chiradeep Vittal <
>> wrote:
>> Also note that in order to support hotplug and hot-detach of nics, we
>> commands like CreateNic and AttachNic.
>This is a great point.  I feel that the right approach is to consider NIC
>to exist only within the VM lifetime, and thus the API that the cloud
>orchestrator needs to expose are:
>- PlugNIC
>- UnplugNIC

If you consider the Elastic Network Interface feature in AWS, the NIC
could exist independent of a VM.
There are several interesting applications that this enables.

>Where the hypervisor resources must implement these methods in the
>hypervisor-specific way.  Depending on the hypervisor, this may include
>creating a VIF, hot-attaching it to the VM, and plugging it into the
>appropriate network.  These are only necessary when CloudStack needs to
>support hot-attach and hot-detaching VIFs.

+1. There are some issues to consider like if it is possible to have a VM
without a NIC and how to issue an IP after hot-attach.

>On a related but a different topic, during the VM launch, VIF plugging has
>to also occur, and it has to be designed in a way that both Xen and
>Libvirt/KVM can agree on.

And vSphere and OVM...

>This VIF attachment logic should be done in a driver model in which
>vendors can supply their own logic, and I think this is essential for SDN
>integration.  Each hypervisor should have its own VIF driver interface, so
>there should be LibvirtVifDriver and XenVifDriver interfaces.  They both
>define 'plug' and 'unplug' methods but perhaps differ in signatures.

This seems similar to what Murali proposed during the NVP integration
The NVP component wished to add specific meta-data to the hypervisor db.

>For Xen, you'd only need to make xapi calls but this VIF
>driver gives the vendors a place to customize parameters sent to
>call, such as setting 'other-configs' values.

Yes, absolutely.

>Any feedback would be greatly appreciated.  I've only recently started
>looking at the CloudStack architecture so please correct me if I said
>something off-base.

I would welcome a patch with this kind of functionality.


View raw message