cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomoe Sugihara <to...@midokura.com>
Subject Re: making VM startup more fine-grained
Date Tue, 31 Jul 2012 01:35:50 GMT
On Fri, Jul 27, 2012 at 10:13 AM, Chiradeep Vittal
<Chiradeep.Vittal@citrix.com> wrote:
>
>
> On 7/25/12 10:52 PM, "Ishimoto, Ryu" <ryu@midokura.com> wrote:
>
>>On Mon, Jun 4, 2012 at 3:02 PM, Chiradeep Vittal <
>>Chiradeep.Vittal@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.
>
>>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.

I'll submit patches for this shortly.
Thanks for the comments.

Tomoe

Mime
View raw message