Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I just noticed something I overlooked ealier in the compute logs:

2013-12-12 19:40:26.013 25394 INFO nova.virt.libvirt.driver [req-de8dd5e4-04e7-4166-ba0c-5169cd79f966 a8b5af7cb2ab401f90d5b4903c091216 2575481bef7f4fde956202e3070fe688] [instance: d736cd1c-c446-43da-b70b-d7140697aa5b] Injecting key into image bb128ee0-5055-4a43-b474-663b26a88634 ... 2013-12-12 19:40:55.082 25394 WARNING nova.virt.disk.api [req-de8dd5e4-04e7-4166-ba0c-5169cd79f966 a8b5af7cb2ab401f90d5b4903c091216 2575481bef7f4fde956202e3070fe688] Ignoring error injecting key into image (aug_get: no matching node)

I just noticed something I overlooked ealier in the compute logs:

2013-12-12 19:40:26.013 25394 INFO nova.virt.libvirt.driver [req-de8dd5e4-04e7-4166-ba0c-5169cd79f966 a8b5af7cb2ab401f90d5b4903c091216 2575481bef7f4fde956202e3070fe688] [instance: d736cd1c-c446-43da-b70b-d7140697aa5b] Injecting key into image bb128ee0-5055-4a43-b474-663b26a88634 ... 2013-12-12 19:40:55.082 25394 WARNING nova.virt.disk.api [req-de8dd5e4-04e7-4166-ba0c-5169cd79f966 a8b5af7cb2ab401f90d5b4903c091216 2575481bef7f4fde956202e3070fe688] Ignoring error injecting key into image (aug_get: no matching node)

I just noticed something I overlooked ealier in the compute logs:

2013-12-12 19:40:26.013 25394 INFO nova.virt.libvirt.driver [req-de8dd5e4-04e7-4166-ba0c-5169cd79f966 a8b5af7cb2ab401f90d5b4903c091216 2575481bef7f4fde956202e3070fe688] [instance: d736cd1c-c446-43da-b70b-d7140697aa5b] Injecting key into image bb128ee0-5055-4a43-b474-663b26a88634
...
2013-12-12 19:40:55.082 25394 WARNING nova.virt.disk.api [req-de8dd5e4-04e7-4166-ba0c-5169cd79f966 a8b5af7cb2ab401f90d5b4903c091216 2575481bef7f4fde956202e3070fe688] Ignoring error injecting key into image (aug_get: no matching node)

node)

I just noticed something I overlooked ealier in the compute logs: still need help here :( No metadata, not key injection => not usable :(

2013-12-12 19:40:26.013 25394 INFO nova.virt.libvirt.driver [req-de8dd5e4-04e7-4166-ba0c-5169cd79f966 a8b5af7cb2ab401f90d5b4903c091216 2575481bef7f4fde956202e3070fe688] [instance: d736cd1c-c446-43da-b70b-d7140697aa5b] Injecting key into image bb128ee0-5055-4a43-b474-663b26a88634
...
2013-12-12 19:40:55.082 25394 WARNING nova.virt.disk.api [req-de8dd5e4-04e7-4166-ba0c-5169cd79f966 a8b5af7cb2ab401f90d5b4903c091216 2575481bef7f4fde956202e3070fe688] Ignoring error injecting key into image (aug_get: no matching node)

I still need Hi, I could gather some more information: According to the guide according to which I was installing OpenStack with KVM on Ubuntu 12.04, the controller node was supposed to get an IP address in the 10.0.0.0/24 network together with the instances and the compute node. Sniffing on the controller node's eth0 interface (192.168.0.10) I could see incoming requests from 10.0.0.2 (my instance IP) to 192.168.0.10:8775, BUT: not responses. I figured that the existence of eth1 (10.0.0.10/24) on the controller seemed to confuse the system somehow. Shutting this interface down, I could suddenly see requests and responses from and to my instance:

root@controller:~# tcpdump -n -i eth0 net 10.0.0.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:24:08.325058 IP 10.0.0.2.53182 > 192.168.0.10.8775: Flags [S], seq 1901335267, win 14600, options [mss 1460,sackOK,TS val 60356 ecr 0,nop,wscale 3], length 0
17:24:08.325143 IP 192.168.0.10.8775 > 10.0.0.2.53182: Flags [S.], seq 1763350780, ack 1901335268, win 14480, options [mss 1460,sackOK,TS val 1318617 ecr 60356,nop,wscale 7], length 0
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
root@controller:~#

Now the response goes to 10.0.0.2 out interface eth0. But my instance cannot see the response and keeps sending requests. Does that help here :( No metadata, not key injection => not usable :(anyone to help me? :D

compute node: /etc/nova/nova.conf [DEFAULT] state_path=/var/lib/nova lock_path=/var/lock/nova root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf verbose=True debug=False my_ip=192.168.0.11

# API
ec2_private_dns_show_ip=True
api_paste_config=/etc/nova/api-paste.ini
enabled_apis=ec2,osapi_compute,metadata

# LOGGING
logdir=/var/log/nova

# NETWORKING
dhcpbridge_flagfile=/etc/nova/nova.conf
dhcpbridge=/usr/bin/nova-dhcpbridge
libvirt_use_virtio_for_bridges=True
network_manager=nova.network.manager.FlatDHCPManager
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver
force_dhcp_release=True
flat_network_bridge=br100
flat_interface=eth1
public_interface=eth0
multi_host=True
dhcp_domain=vxlt.invalid
flat_network_dns=8.8.8.8
gateway=10.0.0.1
network_size=256
allow_same_net_traffic=False
send_arp_for_ha=True


# QUEUE
rabbit_host = controller
rabbit_port = 5672
rabbit_use_ssl = false
rabbit_userid = guest
rabbit_password = guest
rabbit_virtual_host = /

#AUTH
auth_strategy=keystone

# HYPERVISOR
compute_driver=libvirt.LibvirtDriver

# VNC
vnc_enabled=True
vncserver_listen=192.168.0.11
vncserver_proxyclient_address=192.168.0.10
novncproxy_base_url=http://controller:6080/vnc_auto.html

# GLANCE
glance_host=controller

# METADATA
metadata_host=192.168.0.10
metadata_port=8775
metadata_listen=0.0.0.0
metadata_listen_port=8775

# DATABASE
[database]
connection = mysql://nova:nova@controller/nova

# KEYSTONE
[keystone_authtoken]
auth_host = controller
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_user = nova
admin_password = vXLT1234!

Hi, I could gather some more information: According to the guide according to which I was installing OpenStack with KVM on Ubuntu 12.04, the controller node was supposed to get an IP address in the 10.0.0.0/24 network together with the instances and the compute node. Sniffing on the controller node's eth0 interface (192.168.0.10) I could see incoming requests from 10.0.0.2 (my instance IP) to 192.168.0.10:8775, BUT: not responses. I figured that the existence of eth1 (10.0.0.10/24) on the controller seemed to confuse the system somehow. Shutting this interface down, I could suddenly see requests and responses from and to my instance:

root@controller:~# tcpdump -n -i eth0 net 10.0.0.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:24:08.325058 IP 10.0.0.2.53182 > 192.168.0.10.8775: Flags [S], seq 1901335267, win 14600, options [mss 1460,sackOK,TS val 60356 ecr 0,nop,wscale 3], length 0
17:24:08.325143 IP 192.168.0.10.8775 > 10.0.0.2.53182: Flags [S.], seq 1763350780, ack 1901335268, win 14480, options [mss 1460,sackOK,TS val 1318617 ecr 60356,nop,wscale 7], length 0
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
root@controller:~#

Now the response goes to 10.0.0.2 out interface eth0. But my instance cannot see the response and keeps sending requests. Does that help anyone to help me? :D

compute node: /etc/nova/nova.conf

[DEFAULT]
 state_path=/var/lib/nova
 lock_path=/var/lock/nova
 root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf
 verbose=True
 debug=False
    my_ip=192.168.0.11

my_ip=192.168.0.11

# API
ec2_private_dns_show_ip=True
api_paste_config=/etc/nova/api-paste.ini
enabled_apis=ec2,osapi_compute,metadata

# LOGGING
logdir=/var/log/nova

# NETWORKING
dhcpbridge_flagfile=/etc/nova/nova.conf
dhcpbridge=/usr/bin/nova-dhcpbridge
libvirt_use_virtio_for_bridges=True
network_manager=nova.network.manager.FlatDHCPManager
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver
force_dhcp_release=True
flat_network_bridge=br100
flat_interface=eth1
public_interface=eth0
multi_host=True
dhcp_domain=vxlt.invalid
flat_network_dns=8.8.8.8
gateway=10.0.0.1
network_size=256
allow_same_net_traffic=False
send_arp_for_ha=True


# QUEUE
rabbit_host = controller
rabbit_port = 5672
rabbit_use_ssl = false
rabbit_userid = guest
rabbit_password = guest
rabbit_virtual_host = /

#AUTH
auth_strategy=keystone

# HYPERVISOR
compute_driver=libvirt.LibvirtDriver

# VNC
vnc_enabled=True
vncserver_listen=192.168.0.11
vncserver_proxyclient_address=192.168.0.10
novncproxy_base_url=http://controller:6080/vnc_auto.html

# GLANCE
glance_host=controller

# METADATA
metadata_host=192.168.0.10
metadata_port=8775
metadata_listen=0.0.0.0
metadata_listen_port=8775

# DATABASE
[database]
connection = mysql://nova:nova@controller/nova

# KEYSTONE
[keystone_authtoken]
auth_host = controller
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_user = nova
admin_password = vXLT1234!

Hi, I could gather some more information: According to the guide according to which I was installing OpenStack with KVM on Ubuntu 12.04, the controller node was supposed to get an IP address in the 10.0.0.0/24 network together with the instances and the compute node. Sniffing on the controller node's eth0 interface (192.168.0.10) I could see incoming requests from 10.0.0.2 (my instance IP) to 192.168.0.10:8775, BUT: not responses. I figured that the existence of eth1 (10.0.0.10/24) on the controller seemed to confuse the system somehow. Shutting this interface down, I could suddenly see requests and responses from and to my instance:

root@controller:~# tcpdump -n -i eth0 net 10.0.0.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:24:08.325058 IP 10.0.0.2.53182 > 192.168.0.10.8775: Flags [S], seq 1901335267, win 14600, options [mss 1460,sackOK,TS val 60356 ecr 0,nop,wscale 3], length 0
17:24:08.325143 IP 192.168.0.10.8775 > 10.0.0.2.53182: Flags [S.], seq 1763350780, ack 1901335268, win 14480, options [mss 1460,sackOK,TS val 1318617 ecr 60356,nop,wscale 7], length 0
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
root@controller:~#

Now the response goes to 10.0.0.2 out interface eth0. But my instance cannot see the response and keeps sending requests. Does that help anyone to help me? :D

compute node: /etc/nova/nova.conf

[DEFAULT]
state_path=/var/lib/nova
lock_path=/var/lock/nova
root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf
verbose=True
debug=False
my_ip=192.168.0.11

# API
ec2_private_dns_show_ip=True
api_paste_config=/etc/nova/api-paste.ini
enabled_apis=ec2,osapi_compute,metadata

# LOGGING
logdir=/var/log/nova

# NETWORKING
dhcpbridge_flagfile=/etc/nova/nova.conf
dhcpbridge=/usr/bin/nova-dhcpbridge
libvirt_use_virtio_for_bridges=True
network_manager=nova.network.manager.FlatDHCPManager
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver
force_dhcp_release=True
flat_network_bridge=br100
flat_interface=eth1
public_interface=eth0
multi_host=True
dhcp_domain=vxlt.invalid
flat_network_dns=8.8.8.8
gateway=10.0.0.1
network_size=256
allow_same_net_traffic=False
send_arp_for_ha=True


# QUEUE
rabbit_host = controller
rabbit_port = 5672
rabbit_use_ssl = false
rabbit_userid = guest
rabbit_password = guest
rabbit_virtual_host = /

#AUTH
auth_strategy=keystone

# HYPERVISOR
compute_driver=libvirt.LibvirtDriver

# VNC
vnc_enabled=True
vncserver_listen=192.168.0.11
vncserver_proxyclient_address=192.168.0.10
novncproxy_base_url=http://controller:6080/vnc_auto.html

# GLANCE
glance_host=controller

# METADATA
metadata_host=192.168.0.10
metadata_port=8775
metadata_listen=0.0.0.0
metadata_listen_port=8775

# DATABASE
[database]
connection = mysql://nova:nova@controller/nova

# KEYSTONE
[keystone_authtoken]
auth_host = controller
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_user = nova
admin_password = vXLT1234!

EDIT: I can see that my instance can ping 192.168.0.1 and any IP on the internet easily. From this I know that NAT must be working. But the fact that when I ping 192.168.0.10 it responds to 10.0.0.2 tells me NAT is not working for that destination IP.

Hi, I could gather some more information: According to the guide according to which I was installing OpenStack with KVM on Ubuntu 12.04, the controller node was supposed to get an IP address in the 10.0.0.0/24 network together with the instances and the compute node. Sniffing on the controller node's eth0 interface (192.168.0.10) I could see incoming requests from 10.0.0.2 (my instance IP) to 192.168.0.10:8775, BUT: not responses. I figured that the existence of eth1 (10.0.0.10/24) on the controller seemed to confuse the system somehow. Shutting this interface down, I could suddenly see requests and responses from and to my instance:

root@controller:~# tcpdump -n -i eth0 net 10.0.0.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:24:08.325058 IP 10.0.0.2.53182 > 192.168.0.10.8775: Flags [S], seq 1901335267, win 14600, options [mss 1460,sackOK,TS val 60356 ecr 0,nop,wscale 3], length 0
17:24:08.325143 IP 192.168.0.10.8775 > 10.0.0.2.53182: Flags [S.], seq 1763350780, ack 1901335268, win 14480, options [mss 1460,sackOK,TS val 1318617 ecr 60356,nop,wscale 7], length 0
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
root@controller:~#

Now the response goes to 10.0.0.2 out interface eth0. But my instance cannot see the response and keeps sending requests. Does that help anyone to help me? :D

compute node: /etc/nova/nova.conf

[DEFAULT]
state_path=/var/lib/nova
lock_path=/var/lock/nova
root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf
verbose=True
debug=False
my_ip=192.168.0.11

# API
ec2_private_dns_show_ip=True
api_paste_config=/etc/nova/api-paste.ini
enabled_apis=ec2,osapi_compute,metadata

# LOGGING
logdir=/var/log/nova

# NETWORKING
dhcpbridge_flagfile=/etc/nova/nova.conf
dhcpbridge=/usr/bin/nova-dhcpbridge
libvirt_use_virtio_for_bridges=True
network_manager=nova.network.manager.FlatDHCPManager
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver
force_dhcp_release=True
flat_network_bridge=br100
flat_interface=eth1
public_interface=eth0
multi_host=True
dhcp_domain=vxlt.invalid
flat_network_dns=8.8.8.8
gateway=10.0.0.1
network_size=256
allow_same_net_traffic=False
send_arp_for_ha=True


# QUEUE
rabbit_host = controller
rabbit_port = 5672
rabbit_use_ssl = false
rabbit_userid = guest
rabbit_password = guest
rabbit_virtual_host = /

#AUTH
auth_strategy=keystone

# HYPERVISOR
compute_driver=libvirt.LibvirtDriver

# VNC
vnc_enabled=True
vncserver_listen=192.168.0.11
vncserver_proxyclient_address=192.168.0.10
novncproxy_base_url=http://controller:6080/vnc_auto.html

# GLANCE
glance_host=controller

# METADATA
metadata_host=192.168.0.10
metadata_port=8775
metadata_listen=0.0.0.0
metadata_listen_port=8775

# DATABASE
[database]
connection = mysql://nova:nova@controller/nova

# KEYSTONE
[keystone_authtoken]
auth_host = controller
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_user = nova
admin_password = vXLT1234!

EDIT: I can see that my instance can ping 192.168.0.1 and any IP on the internet easily. From this I know that NAT must be working. But the fact that when I ping 192.168.0.10 it responds to 10.0.0.2 tells me NAT is not working for that destination IP.IP. You can also see that from this network dump on the nova-compute/nova-network node:

root@compute1:~# tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:55:15.769454 IP 10.0.0.2 > 192.168.0.10: ICMP echo request, id 32001, seq 607, length 64
10:55:15.770005 IP 192.168.0.10 > 10.0.0.2: ICMP echo reply, id 32001, seq 607, length 64
10:55:16.769830 IP 10.0.0.2 > 192.168.0.10: ICMP echo request, id 32001, seq 608, length 64
10:55:16.770434 IP 192.168.0.10 > 10.0.0.2: ICMP echo reply, id 32001, seq 608, length 64
10:55:17.770299 IP 10.0.0.2 > 192.168.0.10: ICMP echo request, id 32001, seq 609, length 64
10:55:17.770742 IP 192.168.0.10 > 10.0.0.2: ICMP echo reply, id 32001, seq 609, length 64
10:55:18.770837 IP 10.0.0.2 > 192.168.0.10: ICMP echo request, id 32001, seq 610, length 64
10:55:18.771364 IP 192.168.0.10 > 10.0.0.2: ICMP echo reply, id 32001, seq 610, length 64
10:55:19.771349 IP 10.0.0.2 > 192.168.0.10: ICMP echo request, id 32001, seq 611, length 64
10:55:19.771705 IP 192.168.0.10 > 10.0.0.2: ICMP echo reply, id 32001, seq 611, length 64
10:55:27.930764 IP 192.168.0.11 > 192.168.0.1: ICMP echo request, id 46593, seq 0, length 64
10:55:27.930980 IP 192.168.0.1 > 192.168.0.11: ICMP echo reply, id 46593, seq 0, length 64
10:55:28.931312 IP 192.168.0.11 > 192.168.0.1: ICMP echo request, id 46593, seq 1, length 64
10:55:28.931560 IP 192.168.0.1 > 192.168.0.11: ICMP echo reply, id 46593, seq 1, length 64
10:55:29.932084 IP 192.168.0.11 > 192.168.0.1: ICMP echo request, id 46593, seq 2, length 64
10:55:29.932416 IP 192.168.0.1 > 192.168.0.11: ICMP echo reply, id 46593, seq 2, length 64
^C
16 packets captured
18 packets received by filter
0 packets dropped by kernel
root@compute1:~#

Pinging 192.168.0.10 the reponse goes to 10.0.0.2. Pinging 192.168.0.1 it goes back to 192.168.0.11 instead!

Hi, I could gather some more information: According to the guide according to which I was installing OpenStack with KVM on Ubuntu 12.04, the controller node was supposed to get an IP address in the 10.0.0.0/24 network together with the instances and the compute node. Sniffing on the controller node's eth0 interface (192.168.0.10) I could see incoming requests from 10.0.0.2 (my instance IP) to 192.168.0.10:8775, BUT: not responses. I figured that the existence of eth1 (10.0.0.10/24) on the controller seemed to confuse the system somehow. Shutting this interface down, I could suddenly see requests and responses from and to my instance:

root@controller:~# tcpdump -n -i eth0 net 10.0.0.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:24:08.325058 IP 10.0.0.2.53182 > 192.168.0.10.8775: Flags [S], seq 1901335267, win 14600, options [mss 1460,sackOK,TS val 60356 ecr 0,nop,wscale 3], length 0
17:24:08.325143 IP 192.168.0.10.8775 > 10.0.0.2.53182: Flags [S.], seq 1763350780, ack 1901335268, win 14480, options [mss 1460,sackOK,TS val 1318617 ecr 60356,nop,wscale 7], length 0
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
root@controller:~#

Now the response goes to 10.0.0.2 out interface eth0. But my instance cannot see the response and keeps sending requests. Does that help anyone to help me? :D

compute node: /etc/nova/nova.conf

[DEFAULT]
state_path=/var/lib/nova
lock_path=/var/lock/nova
root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf
verbose=True
debug=False
my_ip=192.168.0.11

# API
ec2_private_dns_show_ip=True
api_paste_config=/etc/nova/api-paste.ini
enabled_apis=ec2,osapi_compute,metadata

# LOGGING
logdir=/var/log/nova

# NETWORKING
dhcpbridge_flagfile=/etc/nova/nova.conf
dhcpbridge=/usr/bin/nova-dhcpbridge
libvirt_use_virtio_for_bridges=True
network_manager=nova.network.manager.FlatDHCPManager
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver
force_dhcp_release=True
flat_network_bridge=br100
flat_interface=eth1
public_interface=eth0
multi_host=True
dhcp_domain=vxlt.invalid
flat_network_dns=8.8.8.8
gateway=10.0.0.1
network_size=256
allow_same_net_traffic=False
send_arp_for_ha=True


# QUEUE
rabbit_host = controller
rabbit_port = 5672
rabbit_use_ssl = false
rabbit_userid = guest
rabbit_password = guest
rabbit_virtual_host = /

#AUTH
auth_strategy=keystone

# HYPERVISOR
compute_driver=libvirt.LibvirtDriver

# VNC
vnc_enabled=True
vncserver_listen=192.168.0.11
vncserver_proxyclient_address=192.168.0.10
novncproxy_base_url=http://controller:6080/vnc_auto.html

# GLANCE
glance_host=controller

# METADATA
metadata_host=192.168.0.10
metadata_port=8775
metadata_listen=0.0.0.0
metadata_listen_port=8775

# DATABASE
[database]
connection = mysql://nova:nova@controller/nova

# KEYSTONE
[keystone_authtoken]
auth_host = controller
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_user = nova
admin_password = vXLT1234!

EDIT: I can see that my instance can ping 192.168.0.1 and any IP on the internet easily. From this I know that NAT must be working. But the fact that when I ping 192.168.0.10 it responds to 10.0.0.2 tells me NAT is not working for that destination IP. You can also see that from this network dump on the nova-compute/nova-network node:

root@compute1:~# tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:55:15.769454 IP 10.0.0.2 > 192.168.0.10: ICMP echo request, id 32001, seq 607, length 64
10:55:15.770005 IP 192.168.0.10 > 10.0.0.2: ICMP echo reply, id 32001, seq 607, length 64
10:55:16.769830 IP 10.0.0.2 > 192.168.0.10: ICMP echo request, id 32001, seq 608, length 64
10:55:16.770434 IP 192.168.0.10 > 10.0.0.2: ICMP echo reply, id 32001, seq 608, length 64
10:55:17.770299 IP 10.0.0.2 > 192.168.0.10: ICMP echo request, id 32001, seq 609, length 64
10:55:17.770742 IP 192.168.0.10 > 10.0.0.2: ICMP echo reply, id 32001, seq 609, length 64
10:55:18.770837 IP 10.0.0.2 > 192.168.0.10: ICMP echo request, id 32001, seq 610, length 64
10:55:18.771364 IP 192.168.0.10 > 10.0.0.2: ICMP echo reply, id 32001, seq 610, length 64
10:55:19.771349 IP 10.0.0.2 > 192.168.0.10: ICMP echo request, id 32001, seq 611, length 64
10:55:19.771705 IP 192.168.0.10 > 10.0.0.2: ICMP echo reply, id 32001, seq 611, length 64
10:55:27.930764 IP 192.168.0.11 > 192.168.0.1: ICMP echo request, id 46593, seq 0, length 64
10:55:27.930980 IP 192.168.0.1 > 192.168.0.11: ICMP echo reply, id 46593, seq 0, length 64
10:55:28.931312 IP 192.168.0.11 > 192.168.0.1: ICMP echo request, id 46593, seq 1, length 64
10:55:28.931560 IP 192.168.0.1 > 192.168.0.11: ICMP echo reply, id 46593, seq 1, length 64
10:55:29.932084 IP 192.168.0.11 > 192.168.0.1: ICMP echo request, id 46593, seq 2, length 64
10:55:29.932416 IP 192.168.0.1 > 192.168.0.11: ICMP echo reply, id 46593, seq 2, length 64
^C
16 packets captured
18 packets received by filter
0 packets dropped by kernel
root@compute1:~#

Pinging 192.168.0.10 the reponse goes to 10.0.0.2. Pinging 192.168.0.1 it goes back to 192.168.0.11 instead!

Looking at iptables on the controller, I would say the traffic should be DNATed and SNATed:

root@compute1:~# iptables -t nat -L -n | grep 192.168.0.10
ACCEPT     all  --  10.0.100.0/24        192.168.0.10        
DNAT       tcp  --  0.0.0.0/0            169.254.169.254      tcp dpt:80 to:192.168.0.10:8775
root@compute1:~# iptables -t nat -L -n | grep SNAT
SNAT       all  --  10.0.100.0/24        0.0.0.0/0            to:192.168.0.11
root@compute1:~#