A lot of people. Let me check in our environment and see if I have the same issue.
On Jan 27, 2012, at 10:59 AM, David Kranz wrote:
> Actually that did not seem to have any effect. How many people are using
> multi_host? I would change the title of this ticket but don't know how.
>
> --
> You received this bug notification because you are subscribed to
> OpenStack Compute (nova).
> https://bugs.launchpad.net/bugs/920493
>
> Title:
> Sometimes vms on same fixed network cannot ping others if floating
> address present
>
> Status in OpenStack Compute (Nova):
> New
>
> Bug description:
> It is my understanding, and observation, that vms allocated from the
> same --fixed_range network can ping the fixed addresses of other such
> vms. Also, vms can be pinged by fixed address from the compute node on
> which they are running. A user reported that when a floating ip was
> assigned to a vm, she could not access that vm by fixed address, but
> could by the floating address. I was able to reproduce this problem
> but not in a consistent way. It seemed more likely to happen when the
> floating ip address was assigned before the vm finished booting but I
> could not create a reliable pattern to show this. When the vm's fixed
> address was not accessible to other vms, it was still OK from the
> compute node hosting the vm. This system is based on diablo-stable and
> this nova.conf:
>
> --use_deprecated_auth
> --dhcpbridge_flagfile=/etc/nova/nova.conf
> --dhcpbridge=/usr/bin/nova-dhcpbridge
> --sql_connection=mysql://nova:notnova@172.18.0.131/nova
> --s3_host=172.18.0.131
> --rabbit_host=172.18.0.131
> --glance_api_servers=172.18.0.131:9292
> --logdir=/var/log/nova
> --state_path=/var/lib/nova
> --lock_path=/var/lock/nova
> --verbose
> --ec2_url=http://172.18.0.131:8773/services/Cloud
> --dmz_cidr=172.18.0.131/32
> --fixed_range=10.0.0.0/24
> --network_size=256
> --image_service=nova.image.glance.GlanceImageService
> --bridge_interface=eth1
> --flat_network_bridge=br100
> --flat_interface=eth1
> --network_manager=nova.network.manager.FlatDHCPManager
> --force_dhcp_release
> --public_interface=eth0
> --multi_host=1
> --osapi_host=172.18.0.131
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nova/+bug/920493/+subscriptions
A lot of people. Let me check in our environment and see if I have the same issue.
On Jan 27, 2012, at 10:59 AM, David Kranz wrote:
> Actually that did not seem to have any effect. How many people are using /bugs.launchpad .net/bugs/ 920493 d_auth flagfile= /etc/nova/ nova.conf /usr/bin/ nova-dhcpbridge n=mysql: //nova: notnova@ 172.18. 0.131/nova 172.18. 0.131 host=172. 18.0.131 api_servers= 172.18. 0.131:9292 /var/log/ nova path=/var/ lib/nova path=/var/ lock/nova 172.18. 0.131:8773/ services/ Cloud 172.18. 0.131/32 range=10. 0.0.0/24 service= nova.image. glance. GlanceImageServ ice interface= eth1 network_ bridge= br100 interface= eth1 manager= nova.network. manager. FlatDHCPManager dhcp_release interface= eth0 host=172. 18.0.131 /bugs.launchpad .net/nova/ +bug/920493/ +subscriptions
> multi_host? I would change the title of this ticket but don't know how.
>
> --
> You received this bug notification because you are subscribed to
> OpenStack Compute (nova).
> https:/
>
> Title:
> Sometimes vms on same fixed network cannot ping others if floating
> address present
>
> Status in OpenStack Compute (Nova):
> New
>
> Bug description:
> It is my understanding, and observation, that vms allocated from the
> same --fixed_range network can ping the fixed addresses of other such
> vms. Also, vms can be pinged by fixed address from the compute node on
> which they are running. A user reported that when a floating ip was
> assigned to a vm, she could not access that vm by fixed address, but
> could by the floating address. I was able to reproduce this problem
> but not in a consistent way. It seemed more likely to happen when the
> floating ip address was assigned before the vm finished booting but I
> could not create a reliable pattern to show this. When the vm's fixed
> address was not accessible to other vms, it was still OK from the
> compute node hosting the vm. This system is based on diablo-stable and
> this nova.conf:
>
> --use_deprecate
> --dhcpbridge_
> --dhcpbridge=
> --sql_connectio
> --s3_host=
> --rabbit_
> --glance_
> --logdir=
> --state_
> --lock_
> --verbose
> --ec2_url=http://
> --dmz_cidr=
> --fixed_
> --network_size=256
> --image_
> --bridge_
> --flat_
> --flat_
> --network_
> --force_
> --public_
> --multi_host=1
> --osapi_
>
> To manage notifications about this bug go to:
> https:/