On 7/25/12 10:52 PM, "Ishimoto, Ryu" <[email protected]> wrote:
>On Mon, Jun 4, 2012 at 3:02 PM, Chiradeep Vittal < >[email protected]> wrote: > >> >> Also note that in order to support hotplug and hot-detach of nics, we >>need >> 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... [snip] >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 effort. 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 >VIF.create >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. -- Chiradeep
