openstack team mailing list archive
Mailing list archive
Re: Multi-NIC support to Cactus
I wanted to clarify what mult-nic means to us as we're going to implement
Since we use flat networking and we assign the ips to the vms it feels
like it isn't complicated. Someone please correct me if I'm
misunderstanding. We have both public and private networks for the vms.
Since we pick and assign both those addresses out of a range for the
public and private nics we are able to assign a public routable ip to to
the "public" interface and a private RFC1918 address to the "private"
Since we are using XenServer, we do this by putting those addresses in a
json string in xenstore and having an agent read the xenstore and
configure the nics as necessary. Both the public and private nics are on
I know the network service is going to get complicated very quickly but I
wanted to let everyone know for Cactus, our use case is pretty simple.
On 2/2/11 9:04 AM, "masumotok@xxxxxxxxxxxxx" <masumotok@xxxxxxxxxxxxx>
>Thanks for your answer. Now it's clear to me.
>> I assume that the tenant will not be able to configure any rich network
>> topologies until network-service is done.
>Network model topic is big issue and multi-nic issue is also not a small
>issue if we cover "any" network topologies. I'm expecting at first
>1. instances can have more than 2 vifs.
>2. cloud user can decide how many vifs instance have.
>3. different vlan can be assigned to vifs.
>4. different security groups can be assigned to vifs.
>5. "vifs are assigned which physical nics" kind of thought is necessary(?)
>Those are just first shallow thought - things can go step by step.
>I personally feel that not only model-basis discussion but also
>functionality-based discussion may be good to accelerate better network
>From: Ewan Mellor [mailto:Ewan.Mellor@xxxxxxxxxxxxx]
>Sent: Wednesday, February 02, 2011 10:06 PM
>To: RDH 桝本 圭(ＩＴアーキ＆セキュ技術); openstack@xxxxxxxxxxxxxxxxxxx
>Subject: RE: Multi-NIC support to Cactus
>That's a good question. Multi-NIC support could be separated out from
>the rest of the network-service blueprint, but I don't know whether it
>would be useful to do so.
>I assume that the tenant will not be able to configure any rich network
>topologies until network-service is done. If that is true, what else
>would you do with multi-NIC support? And how do you imagine that it
>> -----Original Message-----
>> From: openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx
>> On Behalf Of masumotok@xxxxxxxxxxxxx
>> Sent: 02 February 2011 06:34
>> To: openstack@xxxxxxxxxxxxxxxxxxx
>> Subject: [Openstack] Multi-NIC support to Cactus
>> Regarding to the blueprint to Cactus,
>> I found 2 blueprints that may be related to multi-NIC.
>> ( I expect instances can have multiple vnic. )
>> 1. <https://blueprints.launchpad.net/nova/+spec/multi-nic>
>> 2. <https://blueprints.launchpad.net/nova/+spec/multinic-libvirt>
>> Q1. New network model topic and multi-nic support topic will be
>> discussed as different topics for Cactus.
>> A new netowk model is deferred to Diablo but multi-NIC support may be
>> included in Cactus, am I following to current discussion?
>> Q2. If so, looking back to discussions till now, multi-nic might be
>> supported to Xenserver and KVM to Cactus?
>> I know we are not sure till any blueprint be approved, my team is
>> curious to KVM multi-nic support.
>> Kei Masumoto
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~openstack
>More help : https://help.launchpad.net/ListHelp
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.