On Mon, Aug 6, 2012 at 6:18 PM, Tomoe Sugihara <to...@midokura.com> wrote: > On Fri, Jul 27, 2012 at 10:13 AM, Chiradeep Vittal > <chiradeep.vit...@citrix.com> wrote: >> >> >> On 7/25/12 10:52 PM, "Ishimoto, Ryu" <r...@midokura.com> wrote: >> >>>On Mon, Jun 4, 2012 at 3:02 PM, Chiradeep Vittal < >>>chiradeep.vit...@citrix.com> 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. > > Hi Chiradeep, > > Regarding Xen, I just took a look at the TODO section here: > https://cwiki.apache.org/CLOUDSTACK/feature-nicira-nvp-integration.html. > > I'm thinking to move the following method: > > 761: protected VIF createVif(Connection conn, String vmName, VM > vm, NicTO nic) throws XmlRpcException, XenAPIException { > > > to vif driver's responsibility(same idea as handler in the wiki) and > make the default implementation have > more generic other-config values like "cs-iface-id" and "cs-vm-id". > That way, vendors can put whatever information they want to > other-config and/or even make other xen-api calls in their vif > drivers.
I have looked at the code more in detail and found a bit tricky thing. Inside the createVif() method, it calls getNetwork(conn, nic) to set vifr.network record. And inside getNetwork(), it differentiates by BroadcastDomainType. Now I'm wondering if the method getNetwork() to be inside to-be-created default vif driver's implementation, or out side of the vif driver. So, I'd like to ask for comments or suggestions from the community. Thanks in Advance, Tomoe > > Any comments? > > Thanks, > Tomoe
