Ask Your Question
0

windows metadata broken in grizzly

asked 2013-05-23 18:56:45 -0500

Layout: Network node (nova-api, nova-network) --> compute node --> windows guest instance All openstack components are running Ubuntu 12.04

Description: Windows instance cannot pull metadata from 169.254.169.254 but works fine when going direct to network node api port ( http://10.160.3.7:8775 ). Ubuntu cloud images work fine. The windows image was built with the device flags that kvm in grizzly uses. This same fashion was used for essex and folsom. The problem manifests itself from the guest instance as a connection timeout. Nova network is running in flat dhcp mode. I am running the latest windows virtio driver: virtio-win-0.1-59.iso

Network node IPs: eth0: 10.160.3.7 br100: 10.160.20.12

Network node DNAT rule: Chain nova-network-PREROUTING (1 references) target prot opt source destination
DNAT tcp -- anywhere 169.254.169.254 tcp dpt:http to:10.160.3.7:8775

listening port for api on Network node: tcp 0 0 0.0.0.0:8775 0.0.0.0:* LISTEN 9604/python

The following is the tcpdump from the network node followed by the compute host. network port on the compute host is the physical interface facing the instances ( eth1.360 ) and the interface on the compute host is the vnet facing the instance:

Network node:

11:35:20.456204 IP (tos 0x0, ttl 128, id 354, offset 0, flags [DF], proto TCP (6), length 52) 10.160.20.13.49257 > 169.254.169.254.http: Flags [S], cksum 0x0d8b (correct), seq 3362866702, win 8192, options [mss 1372,nop,wscale 2,nop,nop,sackOK], length 0 11:35:20.456263 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 169.254.169.254.http > 10.160.20.13.49257: Flags [S.], cksum 0x72d0 (incorrect -> 0xe2ff), seq 1526576664, ack 3362866703, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 11:35:21.652626 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 169.254.169.254.http > 10.160.20.13.49257: Flags [S.], cksum 0x72d0 (incorrect -> 0xe2ff), seq 1526576664, ack 3362866703, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 11:35:23.652652 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 169.254.169.254.http > 10.160.20.13.49257: Flags [S.], cksum 0x72d0 (incorrect -> 0xe2ff), seq 1526576664, ack 3362866703, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 11:35:27.852638 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 169.254.169.254.http > 10.160.20.13.49257: Flags [S.], cksum 0x72d0 (incorrect -> 0xe2ff), seq 1526576664, ack 3362866703, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 11:35:35.852605 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 169.254.169.254.http ... (more)

edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted
0

answered 2013-05-24 20:29:44 -0500

Well, problem solved by injecting static route for 169.254.169.254 to the gateway via dhcp option 121.

edit flag offensive delete link more
0

answered 2013-05-24 21:53:30 -0500

On a side note. This is unnecessary if you are running multihost = True with nova-api also on the compute host.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-05-23 18:56:45 -0500

Seen: 17 times

Last updated: May 24 '13