9:18 p.m.
Attached is my first stab at a Spec file for Websockify. One thing I
noticed is that It builds as a x86_64 arch on my machine, and should be
a noarch.
I am building from the git hash 19a9730 but would really like to have a
version number to build with. We could do what Openstack is doing, and
use a date based number. I guess that would make this something like
20120510, But I would rather get a checkpointed release number. I'll
let Martin make the call.
Ideally, the source files would come out of a tarball just named:
websockify as opposed to kKanaka-websockify.zip. but I wanted to use
the ones created by git. It would be cleaner if there were a
websockify-0.1.0.tar.gz on a permanent URL that we could use in the
spec file as well, where the internal directory was named websockify
and not kanaka-websockify, but we can live with it as is. That seems
to be the github default.
The end state is to remove all of the non-noVNC specific files in the
noVNC spec file, and to instead import websockify from here.
II'm thinking right now that the noVNC spec file is then going to
produce two RPMS: python-noVNC-server and noVNC-common.
python-noVNC-server will require noVNC-common and python-websockify. If
we want to deploy noVNC-common as part of an Apache HTTPD related scheme
in the future, or someone wants it for JBoss, they won't have top pull
in any of the Python code.
1:43 a.m.
On 11/05/12 04:18, Adam Young wrote:
Attached is my first stab at a Spec file for Websockify. One thing
I
noticed is that It builds as a x86_64 arch on my machine, and should be
a noarch.
you might want to include
BuildArch: noarch
and should definitely replace /usr/bin and /usr/lib by rpm macros.
You also might append to setup: -n kanaka-websockify-%{version} and
remove the later mv from prep-section.
If you like to get this reviewed, submit websockify for review and give
me a ping.
I am building from the git hash 19a9730 but would really like to have a
version number to build with. We could do what Openstack is doing, and
use a date based number. I guess that would make this something like
20120510, But I would rather get a checkpointed release number. I'll
let Martin make the call.
There has been a thread about github being bad upstream. It included a
scriptlet to do a fresh checkout, tar.gz etc. Really nice. If you're
interested, I'll search for that in my .spec files.
The end state is to remove all of the non-noVNC specific files in the
noVNC spec file, and to instead import websockify from here.
I don't see a problem in dividing into several packages. I'd say, it
depends on upstream. If upstream distributes one source-tarball, I'd
say, it's one package.
Matthias
--
Matthias Runge <mrunge(a)matthias-runge.de>
<mrunge(a)fedoraproject.org>
2:43 a.m.
On 05/11/2012 07:43 AM, Matthias Runge wrote:
There has been a thread about github being bad upstream. It included
a
scriptlet to do a fresh checkout, tar.gz etc. Really nice. If you're
interested, I'll search for that in my .spec files.
http://lists.fedoraproject.org/pipermail/devel/2012-April/thread.html#166143
cheers,
Pádraig.
4:23 a.m.
On 11/05/12 09:43, Pádraig Brady wrote:
On 05/11/2012 07:43 AM, Matthias Runge wrote:
> There has been a thread about github being bad upstream. It included a
> scriptlet to do a fresh checkout, tar.gz etc. Really nice. If you're
> interested, I'll search for that in my .spec files.
http://lists.fedoraproject.org/pipermail/devel/2012-April/thread.html#166143
cheers,
Pádraig.
Yeah, that was it! thank you, Pádraig!
something like this (taken from that thread)
#!/bin/sh
# usage: tcplay-get-snapshot.sh <hash>
git clone git://github.com/bwalex/tc-play
( cd tc-play && \
git archive --format=tar --prefix=tcplay-$1/ $1 \
) | xz - >tcplay-$1.tar.xz
or that (also from that thread):
%global commit bd245c9
Source0:
https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz
%setup -q -n jukka-pcfi-%{commit}
should work for you.
--
Matthias Runge <mrunge(a)matthias-runge.de>
<mrunge(a)fedoraproject.org>
4:48 p.m.
New subject: Problem connecting to the VM with quantum and openvswitch
Hello
I can't ping nor ssh to the VM. By the output of tcpdump, looks like the VM isn't
connected to the vswitch but VM got a dhcp IP address.
Any help is greatly appreciated.
[root@core01 ~]# nova-manage network create --label=public --fixed_range_v4=10.10.0.0/24
--project_id=76c41e7de2d0408489e94f8adb5b28ee
[root@core01 ~]# nova-manage network list
id IPv4 IPv6 start address DNS1
DNS2 VlanID project uuid
13 10.10.0.0/24 None 10.10.0.2 8.8.4.4
None None 76c41e7de2d0408489e94f8adb5b28ee
09656e2d-7f4e-4172-a37a-8cff745044b2
[root@core01 ~]# nova boot --image 2dec19df-b1a0-4091-840f-2c76455d2248 --flavor 1 --nic
net-id=09656e2d-7f4e-4172-a37a-8cff745044b2 test-vm1
[root@core01 ~]# nova list
+--------------------------------------+----------+--------+------------------+
| ID | Name | Status | Networks |
+--------------------------------------+----------+--------+------------------+
| 760f7622-a223-4fff-9cba-84dc144a6448 | test-vm1 | ACTIVE | public=10.10.0.3 |
+--------------------------------------+----------+--------+------------------+
[root@core01 ~]# ovs-vsctl show
1059a32e-7b7f-4b8a-aef1-b526f3c44b67
Bridge br-int
Port "gw-09656e2d-7f"
tag: 1
Interface "gw-09656e2d-7f"
type: internal
Port br-int
Interface br-int
type: internal
Port "tap3421ac3b-94"
tag: 1
Interface "tap3421ac3b-94"
ovs_version: "1.4.0"
[root@core01 ~]#
[root@core01 ~]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 172.20.0.250 0.0.0.0 UG 0 0 0 em1.777
10.10.0.0 0.0.0.0 255.255.255.0 U 0 0 0 gw-09656e2d-7f
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 em1.777
172.20.0.0 0.0.0.0 255.255.255.0 U 0 0 0 em1.777
[root@core01 nova]# tcpdump -i gw-09656e2d-7f
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gw-09656e2d-7f, link-type EN10MB (Ethernet), capture size 65535 bytes
17:22:01.410697 ARP, Request who-has 10.10.0.3 tell core01, length 28
17:22:02.412664 ARP, Request who-has 10.10.0.3 tell core01, length 28
[root@core01 nova]# tcpdump -i tap3421ac3b-94
tcpdump: WARNING: tap3421ac3b-94: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap3421ac3b-94, link-type EN10MB (Ethernet), capture size 65535 bytes
17:25:10.460668 ARP, Request who-has 10.10.0.3 tell core01, length 28
17:25:11.462682 ARP, Request who-has 10.10.0.3 tell core01, length 28
[root@core01 nova]# ifconfig
em1 Link encap:Ethernet HWaddr 00:25:90:1C:1B:0E
inet6 addr: fe80::225:90ff:fe1c:1b0e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16529152 errors:0 dropped:4307 overruns:0 frame:0
TX packets:2913065 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10432691482 (9.7 GiB) TX bytes:1351181843 (1.2 GiB)
Memory:fbd20000-fbd40000
em1.777 Link encap:Ethernet HWaddr 00:25:90:1C:1B:0E
inet addr:172.20.0.51 Bcast:172.20.0.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe1c:1b0e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3742346 errors:0 dropped:15956 overruns:0 frame:0
TX packets:2500077 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:8927367533 (8.3 GiB) TX bytes:1323925155 (1.2 GiB)
gw-09656e2d-7f Link encap:Ethernet HWaddr FA:16:3E:1E:EF:6F
inet addr:10.10.0.1 Bcast:10.10.0.255 Mask:255.255.255.0
inet6 addr: fe80::f816:3eff:fe1e:ef6f/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2520 (2.4 KiB) TX bytes:6096 (5.9 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6445720 errors:0 dropped:0 overruns:0 frame:0
TX packets:6445720 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:43788857525 (40.7 GiB) TX bytes:43788857525 (40.7 GiB)
tap3421ac3b-94 Link encap:Ethernet HWaddr D6:FD:56:FD:76:FD
inet6 addr: fe80::d4fd:56ff:fefd:76fd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:2520 (2.4 KiB) TX bytes:6096 (5.9 KiB)
4:57 p.m.
New subject: Problem connecting to the VM with quantum and openvswitch
On May 15, 2012, at 4:48 PM, Ask Stack wrote:
Hello
I can't ping nor ssh to the VM. By the output of tcpdump, looks like the VM isn't
connected to the vswitch but VM got a dhcp IP address.
Any help is greatly appreciated.
Which libvirt VIF type and driver are you using?
[root@core01 ~]# nova-manage network create --label=public --fixed_range_v4=10.10.0.0/24
--project_id=76c41e7de2d0408489e94f8adb5b28ee
[root@core01 ~]# nova-manage network list
id IPv4 IPv6 start address DNS1
DNS2 VlanID project uuid
13 10.10.0.0/24 None 10.10.0.2 8.8.4.4
None None 76c41e7de2d0408489e94f8adb5b28ee
09656e2d-7f4e-4172-a37a-8cff745044b2
[root@core01 ~]# nova boot --image 2dec19df-b1a0-4091-840f-2c76455d2248 --flavor 1 --nic
net-id=09656e2d-7f4e-4172-a37a-8cff745044b2 test-vm1
[root@core01 ~]# nova list
+--------------------------------------+----------+--------+------------------+
| ID | Name | Status | Networks |
+--------------------------------------+----------+--------+------------------+
| 760f7622-a223-4fff-9cba-84dc144a6448 | test-vm1 | ACTIVE | public=10.10.0.3 |
+--------------------------------------+----------+--------+------------------+
[root@core01 ~]# ovs-vsctl show
1059a32e-7b7f-4b8a-aef1-b526f3c44b67
Bridge br-int
Port "gw-09656e2d-7f"
tag: 1
Interface "gw-09656e2d-7f"
type: internal
Port br-int
Interface br-int
type: internal
Port "tap3421ac3b-94"
tag: 1
Interface "tap3421ac3b-94"
ovs_version: "1.4.0"
[root@core01 ~]#
[root@core01 ~]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 172.20.0.250 0.0.0.0 UG 0 0 0 em1.777
10.10.0.0 0.0.0.0 255.255.255.0 U 0 0 0 gw-09656e2d-7f
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 em1.777
172.20.0.0 0.0.0.0 255.255.255.0 U 0 0 0 em1.777
[root@core01 nova]# tcpdump -i gw-09656e2d-7f
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gw-09656e2d-7f, link-type EN10MB (Ethernet), capture size 65535 bytes
17:22:01.410697 ARP, Request who-has 10.10.0.3 tell core01, length 28
17:22:02.412664 ARP, Request who-has 10.10.0.3 tell core01, length 28
[root@core01 nova]# tcpdump -i tap3421ac3b-94
tcpdump: WARNING: tap3421ac3b-94: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap3421ac3b-94, link-type EN10MB (Ethernet), capture size 65535 bytes
17:25:10.460668 ARP, Request who-has 10.10.0.3 tell core01, length 28
17:25:11.462682 ARP, Request who-has 10.10.0.3 tell core01, length 28
[root@core01 nova]# ifconfig
em1 Link encap:Ethernet HWaddr 00:25:90:1C:1B:0E
inet6 addr: fe80::225:90ff:fe1c:1b0e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16529152 errors:0 dropped:4307 overruns:0 frame:0
TX packets:2913065 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10432691482 (9.7 GiB) TX bytes:1351181843 (1.2 GiB)
Memory:fbd20000-fbd40000
em1.777 Link encap:Ethernet HWaddr 00:25:90:1C:1B:0E
inet addr:172.20.0.51 Bcast:172.20.0.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe1c:1b0e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3742346 errors:0 dropped:15956 overruns:0 frame:0
TX packets:2500077 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:8927367533 (8.3 GiB) TX bytes:1323925155 (1.2 GiB)
gw-09656e2d-7f Link encap:Ethernet HWaddr FA:16:3E:1E:EF:6F
inet addr:10.10.0.1 Bcast:10.10.0.255 Mask:255.255.255.0
inet6 addr: fe80::f816:3eff:fe1e:ef6f/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2520 (2.4 KiB) TX bytes:6096 (5.9 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6445720 errors:0 dropped:0 overruns:0 frame:0
TX packets:6445720 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:43788857525 (40.7 GiB) TX bytes:43788857525 (40.7 GiB)
tap3421ac3b-94 Link encap:Ethernet HWaddr D6:FD:56:FD:76:FD
inet6 addr: fe80::d4fd:56ff:fefd:76fd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:2520 (2.4 KiB) TX bytes:6096 (5.9 KiB)
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
7:53 a.m.
New subject: Problem connecting to the VM with quantum and openvswitch
Kyle
Thanks. Below is my nova.conf
[DEFAULT]
logdir = /var/log/nova
state_path = /var/lib/nova
lock_path = /var/lib/nova/tmp
dhcpbridge = /usr/bin/nova-dhcpbridge
dhcpbridge_flagfile = /etc/nova/nova.conf
force_dhcp_release = True
injected_network_template = /usr/share/nova/interfaces.template
libvirt_xml_template = /usr/share/nova/libvirt.xml.template
libvirt_nonblocking = True
vpn_client_template = /usr/share/nova/client.ovpn.template
credentials_template = /usr/share/nova/novarc.template
network_manager = nova.network.quantum.manager.QuantumManager
#network_manager = nova.network.manager.FlatDHCPManager
iscsi_helper = tgtadm
sql_connection = mysql://nova:nova@localhost/nova
connection_type = libvirt
firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver
rpc_backend = nova.rpc.impl_qpid
root_helper = sudo nova-rootwrap
auth_strategy = keystone
admin_token = a19c602bc5f8c10c47ea
libvirt_vif_type = ethernet
libvirt_vif_driver = nova.virt.libvirt.vif.LibvirtOpenVswitchDriver
linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver
quantum_use_dhcp = True
----- Original Message -----
From: Kyle Mestery (kmestery) <kmestery(a)cisco.com>
To: Ask Stack <askstack(a)yahoo.com>; Fedora Cloud SIG
<cloud(a)lists.fedoraproject.org>
Cc:
Sent: Tuesday, May 15, 2012 5:57 PM
Subject: Re: Problem connecting to the VM with quantum and openvswitch
On May 15, 2012, at 4:48 PM, Ask Stack wrote:
Hello
I can't ping nor ssh to the VM. By the output of tcpdump, looks like the VM isn't
connected to the vswitch but VM got a dhcp IP address.
Any help is greatly appreciated.
Which libvirt VIF type and driver are you using?
[root@core01 ~]# nova-manage network create --label=public --fixed_range_v4=10.10.0.0/24
--project_id=76c41e7de2d0408489e94f8adb5b28ee
[root@core01 ~]# nova-manage network list
id IPv4 IPv6 start address DNS1
DNS2 VlanID project uuid
13 10.10.0.0/24 None 10.10.0.2 8.8.4.4
None None 76c41e7de2d0408489e94f8adb5b28ee
09656e2d-7f4e-4172-a37a-8cff745044b2
[root@core01 ~]# nova boot --image 2dec19df-b1a0-4091-840f-2c76455d2248 --flavor 1 --nic
net-id=09656e2d-7f4e-4172-a37a-8cff745044b2 test-vm1
[root@core01 ~]# nova list
+--------------------------------------+----------+--------+------------------+
| ID | Name | Status | Networks |
+--------------------------------------+----------+--------+------------------+
| 760f7622-a223-4fff-9cba-84dc144a6448 | test-vm1 | ACTIVE | public=10.10.0.3 |
+--------------------------------------+----------+--------+------------------+
[root@core01 ~]# ovs-vsctl show
1059a32e-7b7f-4b8a-aef1-b526f3c44b67
Bridge br-int
Port "gw-09656e2d-7f"
tag: 1
Interface "gw-09656e2d-7f"
type: internal
Port br-int
Interface br-int
type: internal
Port "tap3421ac3b-94"
tag: 1
Interface "tap3421ac3b-94"
ovs_version: "1.4.0"
[root@core01 ~]#
[root@core01 ~]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 172.20.0.250 0.0.0.0 UG 0 0 0 em1.777
10.10.0.0 0.0.0.0 255.255.255.0 U 0 0 0 gw-09656e2d-7f
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 em1.777
172.20.0.0 0.0.0.0 255.255.255.0 U 0 0 0 em1.777
[root@core01 nova]# tcpdump -i gw-09656e2d-7f
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gw-09656e2d-7f, link-type EN10MB (Ethernet), capture size 65535 bytes
17:22:01.410697 ARP, Request who-has 10.10.0.3 tell core01, length 28
17:22:02.412664 ARP, Request who-has 10.10.0.3 tell core01, length 28
[root@core01 nova]# tcpdump -i tap3421ac3b-94
tcpdump: WARNING: tap3421ac3b-94: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap3421ac3b-94, link-type EN10MB (Ethernet), capture size 65535 bytes
17:25:10.460668 ARP, Request who-has 10.10.0.3 tell core01, length 28
17:25:11.462682 ARP, Request who-has 10.10.0.3 tell core01, length 28
[root@core01 nova]# ifconfig
em1 Link encap:Ethernet HWaddr 00:25:90:1C:1B:0E
inet6 addr: fe80::225:90ff:fe1c:1b0e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16529152 errors:0 dropped:4307 overruns:0 frame:0
TX packets:2913065 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10432691482 (9.7 GiB) TX bytes:1351181843 (1.2 GiB)
Memory:fbd20000-fbd40000
em1.777 Link encap:Ethernet HWaddr 00:25:90:1C:1B:0E
inet addr:172.20.0.51 Bcast:172.20.0.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe1c:1b0e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3742346 errors:0 dropped:15956 overruns:0 frame:0
TX packets:2500077 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:8927367533 (8.3 GiB) TX bytes:1323925155 (1.2 GiB)
gw-09656e2d-7f Link encap:Ethernet HWaddr FA:16:3E:1E:EF:6F
inet addr:10.10.0.1 Bcast:10.10.0.255 Mask:255.255.255.0
inet6 addr: fe80::f816:3eff:fe1e:ef6f/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2520 (2.4 KiB) TX bytes:6096 (5.9 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6445720 errors:0 dropped:0 overruns:0 frame:0
TX packets:6445720 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:43788857525 (40.7 GiB) TX bytes:43788857525 (40.7 GiB)
tap3421ac3b-94 Link encap:Ethernet HWaddr D6:FD:56:FD:76:FD
inet6 addr: fe80::d4fd:56ff:fefd:76fd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:2520 (2.4 KiB) TX bytes:6096 (5.9 KiB)
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
8:19 a.m.
New subject: Problem connecting to the VM with quantum and openvswitch
On May 16, 2012, at 7:53 AM, Ask Stack wrote:
Kyle
Thanks. Below is my nova.conf
[DEFAULT]
logdir = /var/log/nova
state_path = /var/lib/nova
lock_path = /var/lib/nova/tmp
dhcpbridge = /usr/bin/nova-dhcpbridge
dhcpbridge_flagfile = /etc/nova/nova.conf
force_dhcp_release = True
injected_network_template = /usr/share/nova/interfaces.template
libvirt_xml_template = /usr/share/nova/libvirt.xml.template
libvirt_nonblocking = True
vpn_client_template = /usr/share/nova/client.ovpn.template
credentials_template = /usr/share/nova/novarc.template
network_manager = nova.network.quantum.manager.QuantumManager
#network_manager = nova.network.manager.FlatDHCPManager
iscsi_helper = tgtadm
sql_connection = mysql://nova:nova@localhost/nova
connection_type = libvirt
firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver
rpc_backend = nova.rpc.impl_qpid
root_helper = sudo nova-rootwrap
auth_strategy = keystone
admin_token = a19c602bc5f8c10c47ea
libvirt_vif_type = ethernet
libvirt_vif_driver = nova.virt.libvirt.vif.LibvirtOpenVswitchDriver
linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver
quantum_use_dhcp = True
OK, so you are using the old style libvirt + OVS driver. This means that Nova will be
creating tap devices during plug operations, and removing them during unplug operations.
In your case, it appears the tap is being added to the OVS bridge. You also have a gateway
device being added to the bridge as well. From your previous output, it looks like both
devices are up even, given your tcpdump output. So it's unclear to me why the ping
isn't working.
What does the output of "ovs-ofctl dump-flows br-int" indicate? It should be
setup to use L2 learning in your case, verify that.
9:01 a.m.
New subject: Problem connecting to the VM with quantum and openvswitch
Kyle
[root@core01 nova]# ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=59187.486s, table=0, n_packets=197, n_bytes=10478,
priority=1 actions=NORMAL
[root@core01 nova]# ovs-ofctl show br-int
OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:00004e4e9e814b4a
n_tables:255, n_buffers:256
features: capabilities:0xc7, actions:0xfff
1(gw-09656e2d-7f): addr:fa:16:3e:1e:ef:6f
config: 0
state: 0
2(tap3421ac3b-94): addr:d6:fd:56:fd:76:fd
config: 0
state: 0
current: 10MB-FD COPPER
LOCAL(br-int): addr:4e:4e:9e:81:4b:4a
config: PORT_DOWN
state: LINK_DOWN
OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
On Wed, 2012-05-16 at 13:19 +0000, Kyle Mestery (kmestery) wrote:
On May 16, 2012, at 7:53 AM, Ask Stack wrote:
> Kyle
>
> Thanks. Below is my nova.conf
>
>
> [DEFAULT]
> logdir = /var/log/nova
> state_path = /var/lib/nova
> lock_path = /var/lib/nova/tmp
> dhcpbridge = /usr/bin/nova-dhcpbridge
> dhcpbridge_flagfile = /etc/nova/nova.conf
> force_dhcp_release = True
> injected_network_template = /usr/share/nova/interfaces.template
> libvirt_xml_template = /usr/share/nova/libvirt.xml.template
> libvirt_nonblocking = True
> vpn_client_template = /usr/share/nova/client.ovpn.template
> credentials_template = /usr/share/nova/novarc.template
> network_manager = nova.network.quantum.manager.QuantumManager
> #network_manager = nova.network.manager.FlatDHCPManager
> iscsi_helper = tgtadm
> sql_connection = mysql://nova:nova@localhost/nova
> connection_type = libvirt
> firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver
> rpc_backend = nova.rpc.impl_qpid
> root_helper = sudo nova-rootwrap
> auth_strategy = keystone
> admin_token = a19c602bc5f8c10c47ea
> libvirt_vif_type = ethernet
> libvirt_vif_driver = nova.virt.libvirt.vif.LibvirtOpenVswitchDriver
> linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver
> quantum_use_dhcp = True
OK, so you are using the old style libvirt + OVS driver. This means that Nova will be
creating tap devices during plug operations, and removing them during unplug operations.
In your case, it appears the tap is being added to the OVS bridge. You also have a gateway
device being added to the bridge as well. From your previous output, it looks like both
devices are up even, given your tcpdump output. So it's unclear to me why the ping
isn't working.
What does the output of "ovs-ofctl dump-flows br-int" indicate? It should be
setup to use L2 learning in your case, verify that.
4362
days inactive
4367
days old
8 comments
5 participants
participants (5)
-
Adam Young -
askstack -
Kyle Mestery (kmestery) -
Matthias Runge -
Pádraig Brady