[Openstack] ESXi in production with Neutron

[CARVER, PAUL]

Is anyone using ESXi in production with Neutron networking?

We currently run a production OpenStack cloud with KVM only using OvS+GRE 
networking. We're in the process of evaluating a number of commercial SDN 
vendors but we're being asked to support ESXi in the really near timeframe 
before we've had sufficient time to complete an objective evaluation of all the 
available vendors who would like to sell us an SDN solution.

If anyone is running an OpenStack cloud that includes ESXi hypervisors but does 
not rely on a commercial SDN vendor to make it work I'd love to hear about it. 
I'm not eager to bypass the vendor evaluation process and randomly pick a 
vendor without an objective and fair evaluation, but I'm finding it hard to 
locate any documentation that indicates that ESXi is compatible with OpenStack 
(and specifically Neutron networking) unless you also select one of the 
commercial SDN vendors to bridge the gaps.

If we could add ESXi nodes to our current OpenStack zones, even if there were 
some known functional shortcomings, it would give us some breathing room on 
evaluating SDN vendors in a diligent manner.

--
Paul Carver
VO: 732-545-7377
Cell: 908-803-1656
E: pcar...@att.com
Q Instant Message

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] ESXi in production with Neutron

[CARVER, PAUL]

Dan Wendlandt wrote:

>In my experience working with customers, people typically either dip their toe 
>in to start by just running ESXi/vSphere with
>nova-network, or they have decided on NSX from the get-go and start with 
>Neutron.   If you're just looking for nova-network,
>VOVA makes it really easy to do a basic nova-network setup: 
>https://communities.vmware.com/docs/DOC-24626

We’re running Quantum (in Grizzly) with OvS+GRE overlay networking with KVM 
only. NSX and VMWare/Nicira are among the SDN vendors who claim to be able to 
integrate ESXi with KVM in a multi-hypervisor OpenStack cloud, but they’re not 
the only one. There are a number of other vendors who claim they can also 
integrate ESXi with KVM in a common virtual network.

We’re not ready to just decide to go with VMWare/Nicira without first 
evaluating all the options.

However, we’re getting some pressure to support ESXi in a timeframe that 
doesn’t allow for completing the SDN evaluation. I’m trying to figure out if we 
can integrate ESXi into our KVM based OvS+GRE/Neutron (post-upgrade from 
Grizzly) cloud in the interim, or if we need to push back and say that we 
simply can’t support ESXi in the requested timeframe.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Complex Decision Arround The Most Well-Known CMPs

[CARVER, PAUL]

hossein zabolzadeh wrote:
>I want to fully virtualize my datacenter. I don't want cloud. I don't want to 
>deliver
>public cloud. I have several legacy appliacation that I want to run all of 
>them on
>virtualized environment. I want to leverage the virtualization technology to 
>improve
>my datacenter consolidation, ease of meintenace, ease of management with
>increase in capacity.


If you don’t want cloud and don’t need cloud then don’t look at CloudStack or 
OpenStack. There’s no need to be buzzword compliant. Just use ESXi (with or 
without vCenter), or use KVM or Xen directly. After you’ve virtualized your 
infrastructure either one of two things will happen:

1) You’ll realize that you really did want cloud, but now you’ll understand why 
and you won’t just be doing it for buzzword’s sake

or

2) You’ll be perfectly happy because you were actually right that all you 
wanted was to virtualize a few servers. You’re done and you didn’t make 
yourself miserable by implementing something you really didn’t want or need

Not everybody needs a cloud platform. Certainly not everybody needs to build 
their own cloud platform internal to their company. If you’re IT needs are big 
enough and rapidly changing enough to actually need cloud then you wouldn’t be 
posting to an OpenStack mailing list that “I don’t want cloud” unless of course 
you don’t actually know your IT needs well enough. And if you don’t know your 
IT needs well enough to understand on a technical basis why you need OpenStack 
(or CloudStack or vCloud or etc) then you need to go back and figure out your 
own IT needs before proceeding further.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Question about VXLAN support

[CARVER, PAUL]

I haven’t done this on a VXLAN deployment but I did a packet capture on a 
Grizzly GRE environment to see exactly what it looks like on the wire and the 
results are below (although the color coding will probably be lost.) What we 
have with GRE is 802.1q inside the encapsulated payload so if the 4096 limit is 
a concern then this doesn’t alleviate it.

What I’m not sure of is whether the VLAN ID inside of the GRE payload is 
globally unique or whether different compute nodes can reuse the same VLAN ID 
for different Neutron networks.

If somebody has a VXLAN environment up and running I would love to see a packet 
capture similar to the one below (hint, hint :-))

Frame 1: 136 bytes on wire (1088 bits), 136 bytes captured (1088 bits)
Ethernet II, Src: e8:9a:8f:23:41:8f (e8:9a:8f:23:41:8f), Dst: e8:9a:8f:23:42:8d 
(e8:9a:8f:23:42:8d)
Internet Protocol Version 4, Src: 192.168.160.13 (192.168.160.13), Dst: 
192.168.160.21 (192.168.160.21)
Generic Routing Encapsulation (Transparent Ethernet bridging)
Ethernet II, Src: fa:16:3e:69:42:0d (fa:16:3e:69:42:0d), Dst: fa:16:3e:0c:bc:fa 
(fa:16:3e:0c:bc:fa)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 1
Internet Protocol Version 4, Src: 192.168.20.3 (192.168.20.3), Dst: 
12.129.192.149 (12.129.192.149)
User Datagram Protocol, Src Port: 123 (123), Dst Port: 123 (123)
Network Time Protocol (NTP Version 4, client)

Frame 2: 88 bytes on wire (704 bits), 88 bytes captured (704 bits)
Ethernet II, Src: e8:9a:8f:23:41:8f (e8:9a:8f:23:41:8f), Dst: e8:9a:8f:23:41:f1 
(e8:9a:8f:23:41:f1)
Internet Protocol Version 4, Src: 192.168.160.13 (192.168.160.13), Dst: 
192.168.160.14 (192.168.160.14)
Generic Routing Encapsulation (Transparent Ethernet bridging)
Ethernet II, Src: fa:16:3e:35:e3:4f (fa:16:3e:35:e3:4f), Dst: Broadcast 
(ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 1
Address Resolution Protocol (request)

Frame 3: 88 bytes on wire (704 bits), 88 bytes captured (704 bits)
Ethernet II, Src: e8:9a:8f:23:41:8f (e8:9a:8f:23:41:8f), Dst: e8:9a:8f:23:42:8d 
(e8:9a:8f:23:42:8d)
Internet Protocol Version 4, Src: 192.168.160.13 (192.168.160.13), Dst: 
192.168.160.21 (192.168.160.21)
Generic Routing Encapsulation (Transparent Ethernet bridging)
Ethernet II, Src: fa:16:3e:35:e3:4f (fa:16:3e:35:e3:4f), Dst: Broadcast 
(ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 1
Address Resolution Protocol (request)

Frame 4: 88 bytes on wire (704 bits), 88 bytes captured (704 bits)
Ethernet II, Src: e8:9a:8f:23:42:8d (e8:9a:8f:23:42:8d), Dst: e8:9a:8f:23:41:8f 
(e8:9a:8f:23:41:8f)
Internet Protocol Version 4, Src: 192.168.160.21 (192.168.160.21), Dst: 
192.168.160.13 (192.168.160.13)
Generic Routing Encapsulation (Transparent Ethernet bridging)
Ethernet II, Src: fa:16:3e:b5:19:db (fa:16:3e:b5:19:db), Dst: fa:16:3e:35:e3:4f 
(fa:16:3e:35:e3:4f)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 5
Address Resolution Protocol (reply)

Frame 5: 388 bytes on wire (3104 bits), 388 bytes captured (3104 bits)
Ethernet II, Src: e8:9a:8f:23:41:8f (e8:9a:8f:23:41:8f), Dst: e8:9a:8f:23:42:8d 
(e8:9a:8f:23:42:8d)
Internet Protocol Version 4, Src: 192.168.160.13 (192.168.160.13), Dst: 
192.168.160.21 (192.168.160.21)
Generic Routing Encapsulation (Transparent Ethernet bridging)
Ethernet II, Src: fa:16:3e:35:e3:4f (fa:16:3e:35:e3:4f), Dst: fa:16:3e:b5:19:db 
(fa:16:3e:b5:19:db)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 1
Internet Protocol Version 4, Src: 192.168.20.10 (192.168.20.10), Dst: 
192.168.20.2 (192.168.20.2)
User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
Bootstrap Protocol (Request)



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Networking documentation

[CARVER, PAUL]

If anyone knows where this page 
http://docs.openstack.org/havana/config-reference/content/under_the_hood_openvswitch.html
went in the Juno documentation please let me know.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] password in clear text

[CARVER, PAUL]

Jagga Soorma wrote:

>Currently when using the openstack api I have to save my password in clear 
>text in
>the OS_PASSWORD environment variable.  Is there a more secure way to use the
>openstack api without having to either store this password in clear text or 
>enter the
>password manually every time I run a openstack command?  Is there some way that
>I can use a token id?  I have tried but can't seem to get it to work and not 
>sure what
>else is possible. 

If the token will allow you to use services and you store the token in clear 
text then
you’ve only managed to rename your password to token without adding any 
security.

What you need to think about is what are you willing to type and when are you 
willing
to type it. I don’t know if anyone has a polished “official” implementation, 
but a couple
of options:

1) Configure one of your login scripts to prompt for your OpenStack password and
export it rather than putting it directly in a login script.

2) Encrypt your home directory and store your "clear text" password in a file 
in your
 encrypted home directory

3) Put your password in a file on a USB flash drive (in an encrypted file if 
you want
 a double layer of security) and create a wrapper script that reads you 
password
 from a fixed location on USB drive when you run a command. (keep the USB 
drive
 in a physical safe when not in use)


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] cisco trunk interface in err-disabled

[CARVER, PAUL]

Satish Patel [mailto:satish@gmail.com] wrote:

>How do I stop that loop at ovs? Any guideline if I am having issue then 
>someone else must having same issue. 

Neutron uses several bridges in OvS and programs them with flows. In addition 
there are several ways to configure how your compute node connects to the 
physical network. A loop can occur when bridges are connected together in 
multiple places. You may find EasyOVS (https://github.com/yeasy/easyOVS) 
helpful in investigating how your OvS is configured.

You've probably got a misconfiguration where you have something connected where 
it shouldn't be. If you can delete all VMs (to minimize the number of things 
connected to OvS) then just use EasyOVS or the standard OvS commands (e.g. 
ovs-vsctl show) to gather information on bridges and ports. Then just draw it 
out on paper. Look at how the bridges are connected together and how your 
physical NICs (do you have more than one NIC connected to your 2960?) are 
connected to the bridge(s) and you will likely see a loop somewhere.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Neutron Service Chains with Linux Bridge?

[CARVER, PAUL]

Michael Gale [mailto:gale.mich...@gmail.com] wrote:

>Does anyone know if the work for Neutron Service Chains supports environments 
>built with Linux Bridge as the Neutron ML2 driver?


I don’t think it’s possible. I’m not aware of any document that says Linux 
Bridge doesn’t support modifications to its forwarding tables, but I think 
that’s for the same reason that it’s unlikely that a car’s owner’s manual is 
unlikely to mention that you can’t seal the doors and use it for deep sea 
exploration. It’s not at all a use case the designers expected.

Service chaining is all about manipulating the forwarding tables in order to 
override the normal “forward via most direct path to destination” behavior. It 
relies on the dataplane having a standard, documented and designed/intended 
mechanism for manipulating the forwarding tables in arbitrary (or at least 
fairly flexible) ways. I don’t believe Linux Bridge was designed with any 
intention to allow external software to manipulate its forwarding behavior on a 
per packet/per destination basis.

OvS and several other dataplanes are explicitly designed with the expectation 
and interface for an external controller to manipulate the forwarding in rich 
and flexible ways.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack