Open Stack

I did have a problem in vlan trunking on the switch. I fixed it. Now, I am able to ping and ssh the instance that is launched on the compute node from the controller. However, when I look into euca-get-console-output of that instance on compute node, I still see that it is not able to connect to 169.254.169.254 (metadata service). But, I see a private ip address getting leased correctly. Because of this I am able to ping and ssh successfully from CONTROLLER ONLY (not from compute node).
I am not sure if this is the correct behavior. But, in case of flatDHCP this metadata connection should be successful. Otherwise, instances cannot be pinged/sshed in flatDHCP mode.
 
Can VLAN be run in multi-host mode like it is done in flatDHCP mode as suggested by Sergio Ariel below? (with multi_host set to true and running nova-network running)
 
 
euca-get-console-output log
 
Sending discover...
Sending select for 192.168.4.5...
Lease of 192.168.4.5 obtained, lease time 120
starting DHCP forEthernet interface eth0  [  OK  ]
cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id
wget: can't connect to remote host (169.254.169.254): Connection timed out
cloud-setup: failed 1/30: up 9.84. request failed


Thanks,
-vj


________________________________
From: Sergio Ariel de la Campa Saiz <sacampa at gmv.com>
To: Vishvananda Ishaya <vishvananda at gmail.com>; Vijay <vijayrg at yahoo.com> 
Cc: "openstack at lists.launchpad.net" <openstack at lists.launchpad.net> 
Sent: Friday, June 1, 2012 5:12 AM
Subject: RE: [Openstack] dhcp is not leasing an ip address in vlan mode

Hi:
 
I had a similar problem as Vijay:
 
"Network controller assigns a private ip address to the vm launched on compute node. However, I still cannot ping this ip address from the network(controller node). I am running nova-network service only on the controller."
 
"can't connect to remote host (169.254.169.254): Network is unreachable"

I "solved" it when I installed nova-network in all my compute nodes. 
I don´t use NAT but only routing, so each node is the default gateway to instances that are running on it.
 
I don´t know if this workaround is good for you, but it is the best I got.
 
Regards....
Sergio Ariel 
de la Campa Saiz
GMV-SES Infraestructura / 
GMV-SES Infrastructure  
 
  GMV 
Isaac Newton, 11
P.T.M. Tres Cantos
E-28760 Madrid
Tel. 
+34 91 807 21 00
Fax 
+34 91 807 21 99
 www.gmv.com   

  
  
 
 

________________________________
De: openstack-bounces+sacampa=gmv.com at lists.launchpad.net [openstack-bounces+sacampa=gmv.com at lists.launchpad.net] En nombre de Vishvananda Ishaya [vishvananda at gmail.com]
Enviado el: viernes, 01 de junio de 2012 8:35
Para: Vijay
CC: openstack at lists.launchpad.net
Asunto: Re: [Openstack] dhcp is not leasing an ip address in vlan mode

do you see sent and received packets on the vlan?  I would suspect that you actually don't have the vlans trunked on the ports so the packets aren't making it across the switch. 
Vish
On May 31, 2012, at 9:53 AM, Vijay wrote:
Thanks for the reply. Network controller assigns a private ip address to the vm launched on compute node. However, I still cannot ping this ip address from the network(controller node). I am running nova-network service only on the controller.
>
>
>Thanks,-vj
>
>________________________________
>From: Narayan Desai <narayan.desai at gmail.com>
>To: Vijay <vijayrg at yahoo.com> 
>Cc: "openstack at lists.launchpad.net" <openstack at lists.launchpad.net> 
>Sent: Wednesday, May 30, 2012 5:28 PM
>Subject: Re: [Openstack] dhcp is not leasing an ip address in vlan mode
>This sounds like it might be working properly. In VLAN mode, allinstances are connected to one of the project vlans. The .1 address(gateway, dhcp, etc) exists on an interface on the nova-network node(or one of them, in the case that you are running multiple. Thisinterface is bridged to a tagged interface on the appropriate vlantag. On the nova-compute nodes, a vnet interface for the instance isbridged to the vlan tagged interface. On the compute node, there isn'tan IP interface on this network, so the private IP for instances isn'treachable, even if the instance is running on the same node.The canonical test for correct network function is if an instance isreachable via ping from the nova-network server that is currentlyserving the instance's project network.hth-nldOn Wed, May 30, 2012 at 5:42 PM, Vijay <vijayrg at yahoo.com> wrote:> Hello,> I am trying install Essex in VLAN mode on multiple compute nodes.>> I am able to lauch instances on controller
 (which also runs nova-compute)> and ping/ssh those instances.> I am able to launch instances on compute only node. However, I cannot ping> the VM launched  on compute only node.> When i did the euca-get-console-output on that instance, I see that it is> not getting an IP leased from DHCP .. Because of that it is not able to> reach metadata server.> Any help is appreciated.>> Console output is> udhcpc (v1.17.2) started> Sending discover...> Sending discover...> Sending discover...> No lease, forking to background> starting DHCP forEthernet interface eth0  [  OK  ]> cloud-setup: checking> http://169.254.169.254/2009-04-04/meta-data/instance-id> wget: can't connect to remote host (169.254.169.254): Network is unreachable> cloud-setup: failed 1/30: up 17.71. request failed> nova.conf:> --dhcpbridge_flagfile=/etc/nova/nova.conf> --dhcpbridge=/usr/local/bin/nova-dhcpbridge> --logdir=/var/log/nova> --state_path=/var/lib/nova> --lock_path=/var/lock/nova>
 --force_dhcp_release=True> --use_deprecated_auth> --iscsi_helper=tgtadm> --verbose> --vncserver_listen=0.0.0.0> --sql_connection=mysql://novadbadmin:novasecret@192.168.198.85/nova> --daemonize> --s3_host=192.168.198.85> --rabbit_host=192.168.198.85> --cc_host=192.168.198.85> --ospi_host=192.168.198.85> --ec2_host=192.168.198.85> --ec2_url=http://192.168.198.85:8773/services/Cloud> --nova_url=http://192.168.198.85:8774/v1.1/>> # VLAN mode> --flat_interface=eth1> --flat_injected=False> --flat_network_bridge=br100> --flat_network_dhcp_start=192.168.4.2>> --network_manager=nova.network.manager.VlanManager> --vlan_interface=eth1> --public_interface=vlan100> --allow_same_net_traffic=True> --fixed_range=192.168.4.0/24> --network_size=256> --FAKE_subdomain=ec2> --routing_source_ip=192.168.198.85> --glance_api_servers=192.168.198.85:9292> --image_service=nova.image.glance.GlanceImageService> --iscsi_ip_prefix=192.168.> --connection_type=libvirt>
 --libvirt_type=qemu>> # Keystone> --auth_strategy=keystone> --api_paste_config=/etc/nova/api-paste.ini> --keystone_ec2_url=http://192.168.198.85:5000/v2.0/ec2tokens>>>>> Thanks,> -vj>> _______________________________________________> Mailing list: https://launchpad.net/~openstack> Post to     : openstack at lists.launchpad.net> Unsubscribe : https://launchpad.net/~openstack> More help   : https://help.launchpad.net/ListHelp>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack at lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp
>

________________________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener información clasificada por su emisor como confidencial en el marco de su Sistema de Gestión de Seguridad de la Información siendo para uso exclusivo del destinatario, quedando prohibida su divulgación copia o distribución a terceros sin la autorización expresa del remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboración. 
________________________________
Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informação confidencial, de acordo com nosso Sistema de Gestão de Segurança da Informação, sendo para uso exclusivo do destinatário e estando proibida a sua divulgação, cópia ou distribuição a terceiros sem autorização expressa do remetente da mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o remetente e apague-a. Obrigado pela sua colaboração. 

________________________________


________________________________
This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120601/fbe597da/attachment.html>