Fedora18(Beta)同梱のOpenStackを使って「Quantum+OVS Plugin」が動いたので、その際のメモです。netns(Network Namespace）関連でWork aroundが必要でしたが、まだBetaなので、きちんとした手順はGA版が出たら改めてまとめます。
GREトンネリングは未対応
Fedora18(Beta)同梱のOpen vSwitchは、GREに未対応の様でした。テナント間の分離にはVLAN（tenant_network_type = vlan）を使用します。
ipコマンドの困った仕様への対応
ip netns execすると、/sysを再マウントしてくれます。その結果、既存の/sys/fs/cgroupなどが無効になって、systemctlが使えなくなるなどの弊害が発生します。Quantumから使う分には、/sysの再マウント不要なはずなので、/sysの再マウント処理を外したipコマンドを再ビルドして使います。
# diff -uNr iproute2-3.6.0/ip/ipnetns.c.orig iproute2-3.6.0/ip/ipnetns.c.new --- iproute2-3.6.0/ip/ipnetns.c.orig 2012-11-29 18:05:19.304832997 +0900 +++ iproute2-3.6.0/ip/ipnetns.c.new 2012-12-01 11:48:33.224793150 +0900 @@ -153,6 +153,7 @@ return -1; } /* Mount a version of /sys that describes the network namespace */ +/* if (umount2("/sys", MNT_DETACH) < 0) { fprintf(stderr, "umount of /sys failed: %s\n", strerror(errno)); return -1; @@ -161,6 +162,7 @@ fprintf(stderr, "mount of /sys failed: %s\n",strerror(errno)); return -1; } +*/ /* Setup bind mounts for config files in /etc */ bind_etc(name);
（参考）Bug 882047 - "ip netns exec" destroys the /sys mounting and causes systemd problem
PrivateTmpの罠
Quantum関連のデーモンは、systemdの以下の設定ファイルから起動します。
/usr/lib/systemd/system/quantum-dhcp-agent.service /usr/lib/systemd/system/quantum-l3-agent.service /usr/lib/systemd/system/quantum-openvswitch-agent.service /usr/lib/systemd/system/quantum-server.service
この中の「PrivateTmp=true」をすべて「PrivateTmp=false」に変更します。
PrivateTmpは該当プロセス専用の/tmpを用意するオプションですが、これを使うとなぜか、/var/run/netns/以下のbind mountファイルも他のプロセスから適切に参照できなくなり、Agentを再起動してプロセス空間が変わると、ip netns execできなくなります。
（参考）Bug 881741 - Restarting l3_agent causes Stderr: 'RTNETLINK answers: Invalid argument\n'
既知の問題
下記の修正を行います。Upstreamでは直っているのになぁ。。。。
/usr/lib/python2.7/site-packages/quantum/agent/linux/iptables_manager.py
272 # s = [('/sbin/iptables', self.ipv4)]
273 s = [('iptables', self.ipv4)]（参考）Bug 877337 - sudo error in l3-agent.log caused by iptables_manager.py
もうひとつ、quantum-node-setupが、nova.confのLIBVIRT_VIF_DRIVERを設定しない問題の修正も必要。
（参考）Bug 885932 - quantum-node-setup fails to set libvirt_vif_driver with "--plugin openvswitch"
手順のポイント
手順のポイント部分をメモしておきます。全般的な手順は「QuickStart with RHOS(Red Hat OpenStack) Folsom Preview」を参照ください。以下の部分がOVS固有の差分になります。
・quantum-server-setupには、「openvswitch」を指定
# quantum-server-setup --plugin openvswitch
・openvswitchサービスの起動が必要
# systemctl enable openvswitch # systemctl start openvswitch
・事前に作成が必要なブリッジ
# ovs-vsctl add-br br-int # ovs-vsctl add-br br-ex # ovs-vsctl add-port br-ex em1 # ovs-vsctl add-br br-em2 # ovs-vsctl add-port br-em2 em2
「br-int」は、全てのノードで必須の「Integration Bridge」です。（その他のブリッジが全部ここに繋がる。）ブリッジ名は固定です。
「br-ex」は、パブリックネットワーク接続用のブリッジで、Network Node上に必要です。パブリックネットワークに接続した物理NIC（この例ではem1）をポートに追加しておきます。ブリッジ名は固定です。
「br-em2」は、プラベートネットワーク接続用のブリッジで、全ノードに必要です。プラベートネットワークに接続した物理NIC（この例ではem2）をポートに追加しておきます。ブリッジ名は任意です。
そして、plugin.iniに下記のような指定を行います。
[OVS] tenant_network_type = vlan network_vlan_ranges = physnet1,physnet2:100:199 bridge_mappings = physnet1:br-ex,physnet2:br-em2
これで、パブリックネットワーク用ブリッジと「physnet1」、プラベートネットワーク用ブリッジと「physnet2」がそれぞれひも付きます。
その他
私のネットワーク構成に固有かも知れませんが、cinder.confにiscsi_ip_addressの直指定が必要でした。（/etc/hostsで解決するホスト名の指定はなぜかNG）
iscsi_ip_address = 192.168.1.101
あ。これは、Quontumと関係なかったですね。
おまけ
Quantumでは、netns（Network Namespace）対応のおかげで、下図のように、IPアドレスの重複するサブネットを作ることができます。
[Public Network]
|
| 10.64.201.0/24
---------------------------------------------------------
| [public01] |
|10.64.201.1 |10.64.201.3
[router01] [router02]
|192.168.101.1 |192.168.101.1
| |
| 192.168.101.0/24 | 192.168.101.0/24
--------------------------- ----------------------------
| [net01_subnet01] | | [net02_subnet01] |
| | | |
| 192.168.101.2 |192.168.101.3 | 192.168.101.2 |192.168.101.3
[dnsmasq] [vm01] [dnsmasq] [vm02]ネットワークnet01とネットワークnet02は、同じサブネット（192.168.101.0/24）を持っており、それぞれにぶら下がった仮想マシンvm01とvm02は、同じPrivate IP（192.168.101.3）を持っています。しかしながら、外部ネットワークに出ていく時は、それぞれのルータ（router01, router02）がSNAT(Masquerade）をするので大丈夫です。外部ネットワークから接続する際は、それぞれに異なるFloating IPを割り当てます。Floating IPとPrivate IPの変換もそれぞれのルータが個別に行います。
簡単な手順は次の通りです。まず、quantum.confの[DEFAULT]セクションに、「allow_overlapping_ips = True」を指定します。
続いて、外部ネットワークを定義します。
# tenant=$(keystone tenant-list | awk '/service/ {print $2}')
# quantum net-create --tenant-id $tenant public01 --provider:network_type flat --provider:physical_network physnet1 --router:external=True
# quantum subnet-create --tenant-id $tenant --name public01_subnet01 --gateway 10.64.201.254 public01 10.64.201.0/24 --enable_dhcp Falserouter01とその下にぶら下がるnet01を作成します。
# tenant=$(keystone tenant-list|awk '/redhat/ {print $2}')
# quantum router-create --tenant-id $tenant router01
# quantum router-gateway-set router01 public01
# quantum net-create --tenant-id $tenant net01 --provider:network_type vlan --provider:physical_network physnet2 --provider:segmentation_id 101
# quantum subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24
# quantum router-interface-add router01 net01_subnet01router02とその下にぶら下がるnet02を作成します。
# tenant=$(keystone tenant-list|awk '/redhat/ {print $2}')
# quantum router-create --tenant-id $tenant router02
# quantum router-gateway-set router02 public01
# quantum net-create --tenant-id $tenant net02 --provider:network_type vlan --provider:physical_network physnet2 --provider:segmentation_id 102
# quantum subnet-create --tenant-id $tenant --name net02_subnet01 net02 192.168.101.0/24
# quantum router-interface-add router02 net02_subnet01この例では、net01とnet02を同じテナント（redhat）で作成していますが、異なるテナントに割り当てて、テナントごとに使用可能なプライベートネットワークを制限することもできます。
なお、quantum.confのコメントに『「allow_overlapping_ips = True」にした場合は、Novaのセキュリティグループが使えない』との記述があります。これは、Novaのセキュリティグループは、Compute Node上のiptablesを使用しているため、IPアドレスが被ると、どちらのネットワークに対するフィルタリングか分からなくなるためです。すべてのネットワークで共通のセキュリティグループを使用する分には、問題ないと思われます。
