Re: [Openstack] PREROUTING 169.254.169.254 rule shoud not on Compute node.......
For what it's worth, we're running in a configuration similar to the one in the attached diagram using VlanManager. When we moved the nova-network service off of the machine with nova-api, we needed to add an additional prerouting rule on the network server that prevented the traffic from being sent out via NAT (which caused the source address to be lost, resulting in a metadata resolution error). Once the packets arrive at the api service with the correct source address, they need a route back, via the nova-network server in order to get the response packets onto the correct vlan. With a single nova-network server, a static route will do. With multiple nova-network instances on different systems, things get a little more complicated. We ended up setting up route distribution via quagga between the nova-api server, and the nova-network servers. This ensures that nova-api knows which nova-network instance to use to reach any particular project network. -nld On Tue, May 10, 2011 at 9:08 PM, 郭耀謙 tonyt...@gmail.com wrote: Hello , guys There's a problem while separate instance's network and nova-management network. EX. Nova management network : 192.168.1.0/24 eth0 Instance network : 10.0.0.0/12 eth1 bridge to br100 During cloud-setup : Instance try to retrieve metadata from 169.254.169.254. Instances(10.0.0.0/12) request 169.254.169.254 PREROUTING from gateway(nova-network). But If PREROUTING rule is already been set on nova-Compute node, instance request will be redirected on VM host instead of nova-network host. So If your topology is like A diadram from StackOps , Plz Check iptables rule on Compute nodes. -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.2:8773 And del this rule , your instance will get metadata correctly ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] PREROUTING 169.254.169.254 rule shoud not on Compute node.......
We're using quagga for route exchange (via ospf) between the network servers, and the api server. The api server peers with each network server. This is about as simple a quagga setup as you can have. Basically, when nova-network starts up a new project network, quagga begins to advertise that network into ospf. The api server sees that advertisement and can use that to reach the node (for metadata requests). Incidentally, you might want to lock down your POSTROUTING rule to ensure that vms can't hit your management network. IIRC, we were able to use a similar rule, except with a specific host and port as opposed to a blanket rule for the whole network. -nld 2011/5/10 郭耀謙 tonyt...@gmail.com: #iptables -t nat -A nova-network-POSTROUTING -s 10.0.0.0/12 -d 192.168.1.0/24 -j ACCEPT That's what I did on nova-network host . btw , I always isolate nova-network. I'm interesting about quagga in your environment. 2011/5/11 Narayan Desai narayan.de...@gmail.com For what it's worth, we're running in a configuration similar to the one in the attached diagram using VlanManager. When we moved the nova-network service off of the machine with nova-api, we needed to add an additional prerouting rule on the network server that prevented the traffic from being sent out via NAT (which caused the source address to be lost, resulting in a metadata resolution error). Once the packets arrive at the api service with the correct source address, they need a route back, via the nova-network server in order to get the response packets onto the correct vlan. With a single nova-network server, a static route will do. With multiple nova-network instances on different systems, things get a little more complicated. We ended up setting up route distribution via quagga between the nova-api server, and the nova-network servers. This ensures that nova-api knows which nova-network instance to use to reach any particular project network. -nld On Tue, May 10, 2011 at 9:08 PM, 郭耀謙 tonyt...@gmail.com wrote: Hello , guys There's a problem while separate instance's network and nova-management network. EX. Nova management network : 192.168.1.0/24 eth0 Instance network : 10.0.0.0/12 eth1 bridge to br100 During cloud-setup : Instance try to retrieve metadata from 169.254.169.254. Instances(10.0.0.0/12) request 169.254.169.254 PREROUTING from gateway(nova-network). But If PREROUTING rule is already been set on nova-Compute node, instance request will be redirected on VM host instead of nova-network host. So If your topology is like A diadram from StackOps , Plz Check iptables rule on Compute nodes. -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.2:8773 And del this rule , your instance will get metadata correctly ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Real World Nova Deployments
We've got a system comprised of 336 compute nodes, a head node with everything else except for the network and volume pieces, 12 volume servers, and 2 network servers. We're using mysql. We've deployed using VlanManager. We deploy using a custom node imaging system here for base builds and bcfg2 for configuration management. -nld On Mon, May 16, 2011 at 3:43 PM, Chuck Short chuck.sh...@canonical.com wrote: Hi, As interest continues to grow in the openstack project and with nova in particular. I would like to get a better idea of how people are deploying multi machine environemnts and hopefully start a discussion about it: * Are you using mysql or postgresql or sqllite? * Are you using flat networking or something else? * How are you deploying nova? Regards chuck ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] about vlan and switch
We had to preconfigure the vlan tags and set all network ports for nova-compute nodes to trunk them in advance on our switching gear. (BNT and Juniper both, but I've also needed to do it on Cisco gear) I think that is a pretty common requirement for managed switches. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring rabbitmq messages
When we were having rabbitmq problems, we would use rabbitmqctl list_queues to see what the queue depth for each nova service was. While this doesn't show what the throughput is, it does let you know when things start to get backed up. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack + RDMA + Infiniband
I suspect that the original poster was looking for instance access (mediated in some way) to IB gear. When we were trying to figure out how to best use our IB gear inside of openstack, we decided that it was too risky to try exposing IB at the verbs layer to instances directly, since the security model doesn't appear to have a good way to prevent administrative commands from being issued from untrusted instances. We decided to use to IB as fast plumbing for data movement (using IPoIB) and have ended up with pretty nice I/O performance to the volume service, etc. We haven't managed to use it for much more than that at this point. -nld On Mon, Oct 3, 2011 at 11:44 AM, Caitlin Bestler caitlin.best...@nexenta.com wrote: Nick Khamis asked: I was wondering if any effort has been made regarding supporting infiniband devices to support I/O Virtualization, RDMA etc..? If so, can you please direct me to the latest documentation. Adding RDMA support to OpenStack will be a challenge with the current software architecture. What is really needed is adding zero-copy I/O to eventlet socket I/O. Explicit RDMA semantics being visible to OpenStack code would only be possible if *every* device in a cluster supported RDMA, and that would happen so seldom that the code taking explicit advantage of RDMA would Become a maintenance liability. But refactoring the eventlet sockets I/O to use I/O virtualization when available is distinctly possible. It would be major work, but would greatly reduce the memory bandwidth consumption. What you would need to do is convince one of the high speed NIC vendors (10 GbE or InfiniBand) that it was worthwhile to invest in some Python libraries. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack + RDMA + Infiniband
On Mon, Oct 3, 2011 at 4:21 PM, Caitlin Bestler caitlin.best...@nexenta.com wrote: Narayan Desai wrote: I suspect that the original poster was looking for instance access (mediated in some way) to IB gear. When we were trying to figure out how to best use our IB gear inside of openstack, we decided that it was too risky to try exposing IB at the verbs layer to instances directly, since the security model doesn't appear to have a good way to prevent administrative commands from being issued from untrusted instances. We decided to use to IB as fast plumbing for data movement (using IPoIB) and have ended up with pretty nice I/O performance to the volume service, etc. We haven't managed to use it for much more than that at this point. There's no reason to expect use of IPoIB to end up providing better TCP/IP service for large bulk data transfer than you would get from a quality Ethernet NIC. But if you have an existing IB infrastructure it is certainly worth considering. You should experiment to see whether you get better performance under load form IPoIB in connected mode as opposed to trying SDP. I suppose that is true, if your link speeds are the same. We're getting (without much effort) 3 GB/s over IPoIB (connected mode, etc). Either IPoIB or SDP should be accessible via a standard sockets interface,meaning they could be plugged in without modifying the Python code or Python libraries. Yeah, that is exactly what we did. We used addresses on the IPoIB layer 3 network to get all of our I/O traffic going over that instead of ethernet. The response to congestion by an IB network is different than the response from a TCP network, and the response of a TCP network simulated over IPoIB is something else entirely. So you'd want to do your evaluation with realistic traffic patterns. Yeah, in our case, the system was specced like an HPC cluster, so the management network is pretty anemic compared with QDR. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Does Nova works with several netwoks and VLANs ?
This looks more or less right. We have been running a setup like you are describing here for quite a while, and we've found it to be stable (and easier to setup than a lot of the other network options, IMO). When debugging this sort of setup, trunking setup problems on the switch are often the culprit. Here is a list of things to verify after firing up an instance on each project network: on the nova-network server: - is there a vlanX for each project vlan - is the brXX interface configured with the appropriate gateway address for the project network - is the bridging setup properly (ie does vlanXX belong to bridge brXX) - is there a dnsmasq process running for each project network (it will be a pair of processes, iirc) on the nova-compute node: - is there a vlanX interface for each project vlan that has an instance on the local machine? - brXX should have no ip address settings - is vlanXX connected to brXX? - is vnetX connected to brXX? Another thing to check is if the instance is getting an ip address from dhcp or not. If you suspect trunking setup problems, you can add an ip address on the project network to brXX on the nova-compute node, and try pinging the .1 gateway address. If that doesn't work, your trunking setup is broken. Make sure that the vlan is setup tagged on the switch port the compute node is attached to, and that it is also passed upstream properly in your network. You should also check your nova-network logs. Hope this helps. -nld On Sat, Nov 5, 2011 at 7:27 PM, Razique Mahroua razique.mahr...@gmail.com wrote: Hi all, I'm trying to create an advanced architecture with Nova, that uses several projects per user, and multiple networks (one network per project) The networks have their own vlan : id IPv4 IPv6 start address DNS1 DNS2 VlanID project uuid 12 192.168.2.0/24 None 192.168.2.3 None None 100 first_project None 13 192.168.3.0/27 None 192.168.3.3 None None 50 another_project None It looks like while the first project runs wells (creates instances have connectivity and can be reached), while the instances created via the second project are unreacheable. Both have the right SG rules, and both networks create the rights VLANS : # /proc/net/vlan/config VLAN Dev name | VLAN ID Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD vlan100 | 100 | eth0 vlan50 | 50 | eth0 # brctl show br100 8000.02163e137a78 no vlan100 br50 8000.02163e447ed8 no vlan50 # ip route sh 192.168.3.0/27 dev br50 proto kernel scope link src 192.168.3.1 192.168.2.0/24 dev br100 proto kernel scope link src 192.168.2.1 - Can I have several VLANS per physical interface ? - Do I need to create everytime a new project, or can I create all my networks and link them to the same project, but be able to specify which network to use everytime I spawn a new instance ? - Is it possible to allow some communication between the VLANS (for instance, hosts into the VLAN 50 should only be able to contact hosts into VLAN100 on port 443) ? Does the security groups can manage per VLAN rules ? Thanks, i'm a bit desperate here :) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Expectations for tracebacks
Hello all. We've recently upgraded our cactus system to more recent code. In the process of doing this, we've started logging whenever we get tracebacks out of any of the openstack components we are running. Some of these are clearly bugs, while others correspond to normal operational conditions (like the case where all compute resources are occupied). My question is, what is the project position on tracebacks? Should they be considered to be expected, or should we be treating them as bugs and filing tickets/patches for them? thanks. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
Ghe, while you're right that these two workloads are different, deployers need developers to use a representative environment during development, or the code doesn't work when it hits real deployments. We've now been bitten during our initial deployment of cactus, our upgrade to diablo, and our recent tests preparing for the essex upgrade because we can't run our management infrastructure on a single system. During cactus, we had issues when we tried to run multiple nova-network servers distinctly from the api service. IIRC during the diablo release, we had issues with keystone and horizon. This time, we had issues with glance/keystone integration. I'm not saying that things haven't improved, it just seems that each release has a new issue caused by the assumption that all services will be running on the same host. As we get more users with large deployments, these sorts of issues will only become a bigger deal, and will hinder large scale adoption. -nld On Wed, Mar 21, 2012 at 3:26 AM, Ghe Rivero ghe.riv...@stackops.com wrote: Hi, we are facing two differents problems here. We have developers and final users, and both of them with different expectations about what to get from OpenStack. Developers wants an easy way to test untested code, new cool-probably-broken features and be able to change immediately - devstack is the perfect tool for this . On the other hand, final users just want a working easy to deploy system, without care if the latest cool-probably-broken feature is included (I bet they prefer it to not be). But the truth is that OpenStack can't ignore any of them. Nobody will use a program which is hard to install, deploy, test or develop on it. Some consensus will be necessary in the user side (I think we all agree that development is ok with devstack) As Justin pointed before, http://summit.openstack.org/sessions/view/26, can be a good starting point, defining a common set of minimums that every package should comply with (file/dir locations and perms, minimal contents of config files, users created, python external modules requiriments/ minimal versions, ...), so when someone complaint about something, we know that the installation has some minimal standards that it follows (just a quick idea that just came to my mind to help debugging users installations, a simple script, that use paste.openstack.org, and post there the config files, daemons runnings, last lines of some logs, version of pkgs installed...) Ghe Rivero On Wed, Mar 21, 2012 at 5:20 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: Another idea: *http://meego.gitorious.org/meego-developer-tools/spectacle * That python code seems to be able to take a yaml defintion and generate either rpm specfiles or debian pkg files. It might be forked or extended (or both) and used to generate the initial set of package definitions for openstack in a non-pkg specific format... On 3/20/12 11:01 AM, Justin Santa Barbara jus...@fathomdb.com wrote: Hi Thomas, I think devstack has done a lot for the developer's use-case, but I believe we should also have a official / semi-official project that does some sort of packaging to help the production use-case. I've proposed a summit discussion: http://summit.openstack.org/sessions/view/26 The background: I want a semi-production deployment, but as a developer I still want to be able to edit the code (which makes packages inconvenient). devstack is orientated towards e.g. wiping the databases. I'm hoping that all the various OS packagers can work together, or at least tell us what sucks. As a community, we should solve these problems once, and the OpenStack project shouldn't treat them as externalities. I've been doing some initial coding here: https://github.com/justinsb/openstack-simple-config The first use case I'm trying to solve is single node installation of OpenStack that is as easy as possible, but also isn't painting the user into the corner. Think apt-get openstack, then the user finds they like it and grows to a 4 node cluster, all the way up to a 100 node cluster. So it uses KVM, FlatManager, config drive injection, Postgresql, etc. - I'm afraid it is still quite opinionated! I have Keystone, Glance Nova installing. I'm using supervisord to avoid any OS dependencies/flamewars, but I would imagine that any OS packager could move it to their preferred init.d flavor easily. Swift is next on my list - I was facing the problem that the number of replicas isn't changeable, though I have a patch for that now. If you'd like to work together, I'd love to collaborate (and that holds for anyone doing packaging). I'm hanging out in #openstack-packaging Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Ghe
Re: [Openstack] OpenStack and routing configuration
We needed to setup something similar when we split out the nova-network service to a different host than nova-api in cactus, so that instances could get to the metadata service. It was pretty simple to make quagga work, but then we needed to add a rule to bypass NAT. Since this was just for the metadata service, it was a tightly scoped rule, but in your case, you'll probably want something that covers your whole intranet. You'll probably still want NAT for internet bound traffic. -nld 2012/4/19 Jérôme Gallard jeronimo...@gmail.com: Hi everyone, I would like to know if someone has already tried to setup routing configurations with nova-network. From my understanding, nova-network only deals with NAT, but I am thinking about configurations to directly routes my virtual networks on my intranet. I am thinking to develop a new driver for the network manager which can configure a RIP router (Quagga, ...). Any feedbacks ? Thanks. Regards, Jérôme ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Sharing disk: OCFS2 or GFS2?
As far as I know, the current volume service doesn't support connecting the same volume to multiple instances at the same time, so neither of these can work directly through nova apis. -nld On Tue, Apr 24, 2012 at 4:44 AM, Daniel Martinez danie...@gmail.com wrote: Hello everyone. My setup is simple. A volumen shared by iSCSI from our Netapp storage that I would like to use it for the instances running on our nova-compute nodes. Has anyone tried to use OCFS2 or GFS2 as FS via iSCSI mounted on the nova-computes as a sharing disk and running the instances into it? The plan b is to create a volumen by node and to format it as ext3 or ext4. Any recomendations? Thanks! Regards, Daniel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] SAN and Fibrechannel with OpenStack
I'm not sure that it would be particularly easy to make nova-volume support clustered filesystems; the current model only supports attaching a volume to a single instance at a time. Aside from that, it shouldn't be too hard to use fc as the data path instead of iscsi. We're looking at using iSER in a similar capacity. -nld On Wed, May 16, 2012 at 4:05 AM, Wolfgang Hennerbichler wolfgang.hennerbich...@risc-software.at wrote: dear openstack godfathers; I do plan to migrate from crappy vmware and some ibm based cloud stack to openstack and kvm. here's the thing: I am lucky enough to have decent hardware, all the compute nodes are interconnected via fibre channel. so I don't want and don't need iscsi. do you think I can make it with something like clvm? I read through the docs of openstack, but I am not really sure now if I can make clvm fly without hacking around in openstack (and nova-volume) too much, especially when it comes to live migration and so on... I realize OpenStack was not built for SAN and FC, but I would really like to hear your opinions on that. Thanks, Wolfgang -- DI (FH) Wolfgang Hennerbichler Software Development Unit Advanced Computing Technologies RISC Software GmbH A company of the Johannes Kepler University Linz ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] dhcp is not leasing an ip address in vlan mode
This sounds like it might be working properly. In VLAN mode, all instances 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. This interface is bridged to a tagged interface on the appropriate vlan tag. On the nova-compute nodes, a vnet interface for the instance is bridged to the vlan tagged interface. On the compute node, there isn't an IP interface on this network, so the private IP for instances isn't reachable, even if the instance is running on the same node. The canonical test for correct network function is if an instance is reachable via ping from the nova-network server that is currently serving the instance's project network. hth -nld On Wed, May 30, 2012 at 5:42 PM, Vijay vija...@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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] dhcp is not leasing an ip address in vlan mode
Along these lines, it seemed simplest if we just ran nova-api-metadata on each nova-network server. That way we could get rid of the awful ospf setup for metadata and just let the network aggregation do its job. -nld On Fri, Jun 1, 2012 at 1:58 PM, Vishvananda Ishaya vishvana...@gmail.comwrote: yes it can. The best way is to run nova-api-metadata on every host so the request can go locally. Alternatively you can set the metadata_host config option on your compute hosts to the ip of a nova-api server somewhere else. you might have to be careful which interface the ip metadata_host is on. It defaults to my_ip, but i have seen it do odd things if the metadata_host is on a different ethernet device than the vms, so you might have to manually set it to a different ip. Vish On Jun 1, 2012, at 9:11 AM, Vijay wrote: 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 saca...@gmv.com *To:* Vishvananda Ishaya vishvana...@gmail.com; Vijay vija...@yahoo.com *Cc:* openstack@lists.launchpad.net openstack@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 oncompute node. However, I still cannot ping this ip address from the network(controllernode). 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@lists.launchpad.net [ openstack-bounces+sacampa=gmv@lists.launchpad.net] En nombre de Vishvananda Ishaya [vishvana...@gmail.com] *Enviado el:* viernes, 01 de junio de 2012 8:35 *Para:* Vijay *CC:* openstack@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.de...@gmail.com *To:* Vijay vija...@yahoo.com *Cc:* openstack@lists.launchpad.net openstack@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, all**instances 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. This**interface is bridged to a tagged interface on the appropriate vlan**tag. On the nova-compute nodes, a vnet interface for the instance is**bridged to the vlan tagged interface. On the compute node, there isn't**an IP interface on this network, so the private IP for instances isn't**reachable, even if the instance is running on the same
Re: [Openstack] ZFS/ZVol + iscsi for volume
We're definitely interested in this sort of thing. So much so that we've already hacked support into nova-volume to run directly on top of an illumos box with zfs. ;) We've only gotten the basics working, and we haven't done any serious torture testing of it yet. Our real goal is to get things working properly using iSER. We tried it on Stuart Stent's recommendation after the summit and it performs considerably better than stock iscsi over infiniband. Our eventual plan is to get the code ready for upstream merge, but it isn't nearly ready for that yet. Ping me offline and I can send you the code, if you're interested. (this is very much a caveat emptor thing at the moment; we're not done any hardening work yet) -nld On Sun, Jun 10, 2012 at 4:15 AM, Nicolas de BONFILS openst...@nicolas2bonfils.com wrote: Hi Stackers, I got an idea/question about iscsi volume. Actually the workflow is : create an LVM pool create a volume in this pool (with nova command or horizon UI) share it with an iscsi target (the compute/volume node) attach it with an iscsi initiator (the VM) I use zfs for other project, and I'm very interested in using it everywhere (when possible). One functionality zfs bring is zvol : it allows to create a block device from a zfs pool (a zfs property allow to share this device with iscsi). With this, a new workflow will be : create a zfs pool (zpool create name device) create a zvol block device (zfs create -V size poolname/volumename) set the zfs property to share it with iscsi (zfs set shareiscsi=on poolname/volumename) attach it with an iscsi initiator (the VM) From what I read, the Nexenta guys do a lot of work around zfs, but for volume use I only found code to plug a Nexenta san (I do not have the hardware to build a san), but no solution to use zfs drive/pool directly. So my 2 questions are : are some people interested in it ? does it seem possible to do it (maybe some one already try) ? Nova volume driver [github.com] got subclasses for specific cases, maybe a new zfs one. Please discuss, submit ideas ! --- Nicolas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] ZFS/ZVol + iscsi for volume
How integrated is the network target support for zfs on freebsd? One of the most compelling features (IMHO) of ZFS on illumos is the whole comstar stack. On the zfs linux port at least, there are just integration hooks out to the standard linux methods (kernel-nfs, etc) for nfs, iscsi, etc. I'm really interested to hear how this goes on FreeBSD. I've been playing with zfs on linux as well, but the results haven't been so good for me. -nld On Mon, Jun 11, 2012 at 10:05 AM, Alberto Molina Coballes alb.mol...@gmail.com wrote: What about Debian/KFreeBSD for nova-volume? Debian testing (wheezy) with FreeBSD kernel provides support for both OpenStack (nova-volume) and ZFS. We are deploying a little cloud for testing purposes and it will probably be one of the alternatives we will test for storage. Cheers ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] instances loosing IP address while running, due to No DHCPOFFER
I vaguely recall Vish mentioning a bug in dnsmasq that had a somewhat similar problem. (it had to do with lease renewal problems on ip aliases or something like that). This issue was particularly pronounced with windows VMs, apparently. -nld On Thu, Jun 14, 2012 at 6:02 PM, Christian Parpart tra...@gmail.com wrote: Hey, thanks for your reply. Unfortunately there was no process restart in nova-network nor in dnsmasq, both processes seem to have been up for about 2 and 3 days. However, why is the default dhcp_lease_time value equal 120s? Not having this one overridden causes the clients to actually re-acquire a new DHCP lease every 42 seconds (at least on my nodes), which is completely ridiculous. OTOH, I took a look at the sources (linux_net.py) and found out, why the max_lease_time is set to 2048, because that is the size of my network. So why is the max lease time the size of my network? I've written a tiny patch to allow overriding this value in nova.conf, and will submit it to launchpad soon - and hope it'll be accepted and then also applied to essex, since this is a very straight forward few-liner helpful thing. Nevertheless, that does not clarify on why now I had 2 (well, 3 actually) instances getting no DHCP replies/offers after some hours/days anymore. The one host that caused issues today (a few hours ago), I fixed it by hard rebooting the instance, however, just about 40 minutes later, it again forgot its IP, so one might say, that it maybe did not get any reply from the dhcp server (dnsmasq) almost right after it got a lease on instance boot. So long, Christian. On Thu, Jun 14, 2012 at 10:55 PM, Nathanael Burton nathanael.i.bur...@gmail.com wrote: Has nova-network been restarted? There was an issue where nova-network was signalling dnsmasq which would cause dnsmasq to stop responding to requests yet appear to be running fine. You can see if killing dnsmasq, restarting nova-network, and rebooting an instance allows it to get a dhcp address again ... Nate On Jun 14, 2012 4:46 PM, Christian Parpart tra...@gmail.com wrote: Hey all, I feel really sad with saying this, now, that we have quite a few instances in producgtion since about 5 days at least, I now have encountered the second instance loosing its IP address due to No DHCPOFFER (as of syslog in the instance). I checked the logs in the central nova-network and gateway node and found dnsmasq still to reply on requests from all the other instances and it even got the request from the instance in question and even sent an OFFER, as of what I can tell by now (i'm investigating / posting logs asap), but while it seemed that the dnsmasq sends an offer, the instances says it didn't receive one - wtf? Please tell me what I can do to actually *fix* this issue, since this is by far very fatal. One chance I'd see (as a workaround) is, to let created instanced retrieve its IP via dhcp, but then reconfigure /etc/network/instances to continue with static networking setup. However, I'd just like the dhcp thingy to get fixed. I'm very open to any kind of helping comments, :) So long, Christian. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
On Thu, Jun 21, 2012 at 11:16 AM, Rick Jones rick.jon...@hp.com wrote: On 06/20/2012 08:09 PM, Huang Zhiteng wrote: By 'network scaling', do you mean the aggregated throughput (bandwidth, packets/sec) of the entire cloud (or part of it)? I think picking up 'netperf' as micro benchmark is just 1st step, there's more work needs to be done. Indeed. A great deal more. For OpenStack network, there's 'inter-cloud' and 'cloud-to-external-world' throughput. If we care about the performance for end user, then reason numbers (for network scaling) should be captured inside VM instances. For example, spawn 1,000 VM instances across cloud, then pair them to do 'netperf' tests in order to measure 'inter-cloud' network throughput. That would certainly be an interesting test yes. We did a bunch of similar tests to determine the overhead caused by kvm and limitations of the nova network architecture. We found that VMs themselves were able to consistently saturate the network link available to the host system, whether it was 1GE or 10GE, with relatively modern node and network hardware. With the default VLANManager network setup, there isn't much you can do to scale your outbound connectivity beyond the hardware you can reasonably drive with a single node, but using multi-host nova-network, we were able to run a bunch of nodes in parallel, scaling up our outbound bandwidth linearly. We managed to get 10 nodes, with a single VM per node, each running 4 TCP streams, up to 99 gigabits on a dedicated cross country link. There was a bunch of tuning that we needed to do, but it wasn't anything particularly outlandish compared with the tuning needed for doing this with bare metal. We've been meaning to do a full writeup, but haven't had time yet. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
On Thu, Jun 21, 2012 at 4:21 PM, Rick Jones rick.jon...@hp.com wrote: TSO and GRO can cover a multitude of path-length sins :) Along with a 64 MB TCP window ;) That is one of the reasons netperf does more than just bulk transfer :) When I was/am measuring scaling of an SMP node I would use aggregate, burst-mode, single-byte netperf TCP_RR tests to maximize the packets per second while minimizing the actual bandwidth consumed. Yeah, for a completely random workload pps is the limiting factor. We're lucky in that our primary high bandwidth use case is wide area data transfer where we can fill our jumbo packets. (kudos to the nova folks on that count; we were completely able to configure jumbo frames without having to hack anything up) We were actually more thrilled to be able to build relatively fat single streams, due to our workload. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] HA inside VMs (via Corosync/Pacemaker)
On Sat, Jun 30, 2012 at 3:06 AM, Christian Parpart tra...@gmail.com wrote: Hm, Pacemaker/Corosync *inside* the VM will add the Service-IP to the local ethernet interface, and thus, the outside OpenStack components do not know about. Using a dedicated floating IP pool for service IPs might feel like a great solution, but OpenStack is not the one to manage who gets what IP - but Corosync/Pacemaker inside the KVM instances. :-) Anyone an idea how to solve this? It sounds like you want to add explicit support to pacemaker to deal with openstack fixed addresses. Then you could run with rfc1918 floating addresses, and then have pacemaker/corosync reassign the (external) fixed address when consensus changes. Think of the openstack fixed address control plane in a similar way to ifconfig. You should even be able to script it up yourself; you'd need to add your openstack creds to the HA images though. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [HPC] Openstack HPC telecon
On Fri, Jul 6, 2012 at 9:51 AM, John Paul Walters jwalt...@isi.edu wrote: Does something like the first Monday of the month at 4:00pm EDT (UTC-4) work? I'm just throwing out that time as something that seems to broadly work on my end, but I'd welcome any input from others. That generally works fine for me. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [HPC] Openstack HPC telecon
On Fri, Jul 6, 2012 at 11:52 AM, Stefano Maffulli stef...@openstack.org wrote: On 07/06/2012 07:51 AM, John Paul Walters wrote: One of the outputs of the design summit was that folks are interested in participating in a monthly (or so) telecon to express feature requests, best practices, etc. I'd like to get this process started. For those of you who are interested, what's the preferred format? IRC, telephone, something else? I've been using google hangouts for this sort of thing lately, and I think it would be a great solution, provided we don't overrun the maximum group size. (iirc it is 10, but being raised) There are also provisions for recording hangouts. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
I also vote for option 1, but the migration path really needs to be solid and well documented. -nld On Wed, Jul 11, 2012 at 10:52 AM, Andrew Clay Shafer a...@parvuscaptus.com wrote: One vote for option 1. Remove Volumes ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Wed, Jul 11, 2012 at 1:49 PM, Adam Gandelman ad...@canonical.com wrote: On 07/11/2012 09:22 AM, Narayan Desai wrote: I also vote for option 1, but the migration path really needs to be solid and well documented. -nld I feel the same. I think documented and tested migration paths are of utmost importance here. Unlike the Keystone - Keystone Light migration, people are actually using Nova volume in production right now. There were some facilities added in the later Keystone to help with migration, but AFAICS Keystone adoption at the time wasn't to the point where the migration path really mattered--not enough to have any bugs being rasied, at least. Thinking more about this, it seems to me that we need to have pretty detailed doc about this. Particularly since cinder isn't in wide use yet, I think that a lot of people are running weird configurations for volume storage. I suspect that having an automagic upgrade path won't be feasible in these cases, but there needs to be enough doc (and tools) to get old volumes migrated in some fashion. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Thu, Jul 12, 2012 at 2:38 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Agreed, I'm a developer, so I'm clearly biased towards what is easier for developers. It will be a significant effort to have to maintain the nova-volume code, so I want to be sure it is necessary. End users really shouldn't care about this, so the other community members who are impacted are operators. I really would like more feedback on how painful it will be for operators if we force them to migrate. We have one clear response from Chuck, which is very helpful. Is there anyone else out there running nova-volume that would prefer to keep it when they move to folsom? I think that the long term maintenance or removal of nova-volume in its existing form is orthogonal to the actual issue of continuity from one release to the next. At this point, we've now run cactus, diablo and are in testing with essex. Each of these has effectively been a flag day for us; we build the new system, migrate users, images, etc, and let users do a bunch of manual migration of volume data, etc, while running both systems in parallel. This hasn't been as painful as it sounds because our understanding of best practices for running openstack is moving pretty quickly and each system has been quite different from the previous. The lack of an effective process to move from one major release to the next is the major issue here in my mind. It would be fantastic if (some day, ha ha ha) you could apt-get upgrade from folsom to grizzly, but i think that is likely to be more trouble than it is worth. A reasonable compromise would be a well documented process as well as tools to aid in the process. Each real deployment will have a substantial set of local customizations, particularly if they are running at any sort of scale. While it won't be feasible to support any upgrade with these customizations, tools for the process (which may only be used a straw man in complex cases) would go a long way. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Release Upgrades (was [nova] [cinder] Nova-volume vs. Cinder in Folsom)
On Thu, Jul 12, 2012 at 4:36 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Upgrading has been painful and we are striving to improve this process as much as possible. I think that this needs to be a core value of the developer community, if Openstack is going to become pervasive. I would like to take this a bit further. Documentation is a great first step, but I would actually like to have an actual Jenkins test that does the upgrade from essex to Folsom with live resources created. I think this the only way that we can be sure that the upgrade is working properly. I don't want to dampen enthusiasm around this issue at all, but I think this goal is pretty difficult to achieve, just due to the existing complexity in real deployments. I'm also worried that this would take away from a high level upgrade documentation goal. The first version of this doesn't even have to be on a full cluster. I'm thinking something as simple as: * configure devstack to checkout stable/essex from all of the projects * run the system, launch some instances and volumes * terminate the workers * upgrade all of the code to folsom * do any manual upgrade steps (nova-manage db sync, cinder migrate, etc.) * run all the workers * make sure the existing data still works and new api commands run The manual upgrade steps should be contained in a single script so that the distress can use it to help make their package upgrades and deployers can use it for reference when upgrading their clusters. This is something we can start working on today and we can run after each commit. Then we will immediately know if we do something that breaks upgradability, and we will have a testable documented process for upgrading. Having a testable process for upgrading is definitely a start. I guess that I am more or less resigned to upgrades being pretty effort intensive, at least in the near term, so my personal bias is towards getting pretty extreme documentation done first. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Weird nova-network bridging problem with precise/essex
We're running into what looks like a linux bridging bug, which causes both substantial (20-40%) packet loss, and DNS to fail about that same fraction of the time. We're running essex on precise, with dedicated nova-network servers and VLANManager. On either of our nova-network servers, we see the same behavior. When tracking this down, I found the following, when tcpdump'ing along the path between vm instance and n-net gateway. The packets appear to make it to the nova-network server, and are properly pulled out of dot1q tagging: root@m5-p:~# tcpdump -K -p -i vlan200 -v -vv udp port 53 tcpdump: WARNING: vlan200: no IPv4 address assigned tcpdump: listening on vlan200, link-type EN10MB (Ethernet), capture size 65535 bytes 20:34:02.377711 IP (tos 0x0, ttl 64, id 59761, offset 0, flags [none], proto UDP (17), length 60) 10.0.0.3.54937 10.0.0.1.domain: 52874+ A? www.google.com. (32) 20:34:07.377942 IP (tos 0x0, ttl 64, id 59762, offset 0, flags [none], proto UDP (17), length 60)10.0.0.3.54937 10.0.0.1.domain: 52874+ A? www.google.com. (32) 20:34:12.378248 IP (tos 0x0, ttl 64, id 59763, offset 0, flags [none], proto UDP (17), length 60)10.0.0.3.54937 10.0.0.1.domain: 52874+ A? www.google.com. (32) 20:34:12.378428 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 170)10.0.0.1.domain 10.0.0.3.54937: 52874 q: A? www.google.com. 6/0/0 www.google.com. [1d3h55m19s] CNAME www.l.google.com., www.l.google.com. [1m33s] A 74.125.225.209, www.l.google.com. [1m33s] A 74.125.225.208, www.l.google.com. [1m33s] A 74.125.225.212, www.l.google.com. [1m33s] A 74.125.225.211, www.l.google.com. [1m33s] A 74.125.225.210 (142) But some packets don't make it all of the way to the bridged interface: root@m5-p:~# brctl show bridge name bridge id STP enabled interfaces br200 8000.fa163e18927b no vlan200 root@m5-p:~# tcpdump -K -p -i br200 -v -vv udp port 53 tcpdump: listening on br200, link-type EN10MB (Ethernet), capture size 65535 bytes 20:34:12.378264 IP (tos 0x0, ttl 64, id 59763, offset 0, flags [none], proto UDP (17), length 60) 10.0.0.3.54937 10.0.0.1.domain: 52874+ A? www.google.com. (32) 20:34:12.378424 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 170) 10.0.0.1.domain 10.0.0.3.54937: 52874 q: A? www.google.com. 6/0/0 www.google.com. [1d3h55m19s] CNAME www.l.google.com., www.l.google.com. [1m33s] A 74.125.225.209, www.l.google.com. [1m33s] A 74.125.225.208, www.l.google.com. [1m33s] A 74.125.225.212, www.l.google.com. [1m33s] A 74.125.225.211, www.l.google.com. [1m33s] A 74.125.225.210 (142) I can't find any way that ipfilter could be implicated in this; there aren't deny rules that are hitting. Oddly enough, this seems to cause no loss in icmp traffic, even with ping -f. So far, searching hasn't netted very much. I've found this similar sounding ubuntu bug report, but it looks like no one is working on it: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986043 We're at 3.2.0-24, and there is a 3.2.0-25, but it is reported to not fix this issue, and neither are 3.4 kernels. It seems sad to try backrevving to an onieric kernel, but that is on my list for tomorrow. If this is a kernel bug, it will make the precise default kernel unusable for nova-network servers with dot1q (or whatever the appropriate feature interaction is). Does this ring any bells, or is there another course of action I should attempt? thanks in advance for any suggestions. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Solaris Fails as Guest VM
I suspect that you need the right solaris (more likely illumos) bits to get guest side support for virtio. We tried a while ago and the default openindiana at the time didn't work. -nld On Tue, Jul 17, 2012 at 7:43 PM, Joshua j...@root.bz wrote: I have tried with both KVM and qemu. Solaris starts to boot and hits grub then cycles boot. Anyone experienced this? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Solaris Fails as Guest VM
On Wed, Jul 18, 2012 at 7:38 PM, Michael March mma...@gmail.com wrote: I don't follow Solaris that closely but I vaguely remember the Joyent folks ported all of KVM to Solaris, right? Or am I just missing the whole point here? They did, and it is a fairly impressive piece of work. Their focus (as a hosting provider) was running kvm virtual machines in a illumos host. That support is completely separate from the guest drivers to make virtio work for block and network devices. afaict, network device support is complete, but block device support isn't finished yet. This means you can't run illumos/solaris as a guest using kvm with virtio. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] quota question
On Fri, Jul 20, 2012 at 4:38 AM, Eoghan Glynn egl...@redhat.com wrote:
Hi Narayan,
I had the idea previously of applying a weighting function to the
resource usage being allocated from the quota, as opposed to simply
counting raw instances.
The notion I had in mind was more related to image usage in glance,
where the image footprint can vary very widely. However I think it
could be useful for some nova resources also.
Now for some resource types, for example say volumes, usage can be
controlled along multiple axes (i.e. number of volumes and total size),
so that gives more flexibility.
But if I'm hearing you correctly, you'd want to apply a lower weighting
to instances that are scheduled onto one of the higher-memory compute
nodes, and vice versa a higher weighting to instances that happen to
be run on lower-memory nodes.
Does that sum it up, or have I misunderstood?
I think you've got it. I hadn't really asked with a particular
solution in mind, i was mainly looking for ideas.
I think that weighting would help. Effectively we need to discount
memory usage on the bigmem nodes, or something like that.
The harder part is that we need to be able to specify
independent/orthogonal quota constraints on different flavors. It
would be really useful to be able to say basically, you can have 2TB
of memory from this flavor, and 4TB of memory from that flavor. This
would allow saying something like you can have up to 3 1TB instances,
and independently have up to 3TB of small instances as well.
BTW what kind of nova-scheduler config are you using?
We're using the filter scheduler. We've defined a bunch of custom
flavors, in addition to the stock ones, that allow us to fill up all
of our node types. So for each node type, we define flavors for the
complete node (minus a GB of memory for the hypervisor), and 3/4, 1/2,
1/4, and 1/8, 1/16, and 1/32 of the node. We've used a machine type
prefix for each one. The compute nodes are IBM idataplex, so we have
idp.{100,75,50,25,12,6,3}. We've done this for each machine type, so
we have idp.*, mem.*, gpu.*, etc. Each machine type has a unique
hostname prefix (cc for the idp nodes, cm for the bigmem nodes, cg for
gpu nodes, etc), and the filter scheduler is setup to route requests
for these custom flavors only to nodes with the appropriate hostname
prefix. This isn't an ideal solution, but it minimizes risk of
fragmentation. (With the default flavors, we'd see a lot of cases
where there was idle capacity left on the nodes that wasn't usable
because the ratio was wrong for the default flavors)
So far, this scheduling scheme has worked pretty well, aside from
leaving some instances in a weird state when you try to start a bunch
(20-50) at a time. I haven't had time to track that down yet.
-nld
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Weird nova-network bridging problem with precise/essex
Just for the record, we found the issue. There was some filtering being applied in the bridge code which randomly (?) dropped some DNS requests. Setting: net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-ip6tables = 0 completely resolved the problem. I've written up full details here: http://buriedlede.blogspot.com/2012/07/debugging-networking-problems-with.html -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Weird nova-network bridging problem with precise/essex
On Sat, Jul 21, 2012 at 6:47 AM, Xu (Simon) Chen xche...@gmail.com wrote: Narayan, If you do net.bridge.bridge-nf-call-iptables = 0 on the network controller, does floating IP still work? For each tenant/network, a subnet is created, and the nova-network has a .1 gateway configured on the bridge with the vlan interface plugged in. The packets from VMs are actually sent to the bridge for NATting. But if you doesn't allow the bridges to call iptables, it might break public access all together. Don't know, maybe I'm not understanding the sysctl flag correctly... Maybe it only applies to the packet transiting the bridge, not impacting the ones destined to the nova-network? Do you mean floating (private) or fixed (public) IPs? I suspect that you mean fixed. Fixed IPs worked regardless of this setting. The crux of the issue was that packets transiting the bridge (ie being moved from vlan200 to the virtual br200) were hitting filtering rules. It looks to me like the sysctls only apply to traffic moving across the bridge (ie exactly between vlan200 and br200), but don't bypass iptables entirely. I don't think that should effect NAT/SNAT in any case. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] growing fixed-ip network
On Thu, Aug 2, 2012 at 8:42 AM, Christoph Kluenter c...@iphh.net wrote: * Am Thu, Aug 02 2012 at 09:24:55 -0400 , schrieb Ravi Jagannathan: It should hop on to the next subnet block if available ( assuming that in LAN its a private address scheme ) . We only use routable IPs. thats why we have some nets which can't be subnetted. What difference does it make if its private adress space ? The major reason to use private address space is that there is likely a lot more of it than you have in public address space. if you have effectively unlimited fixed_ip space, you can give each project a lot. For example, we give each project a /23. While a user could potentially still run out of address space on our system, it hasn't happened yet with our workload. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Multi-Hypervisor Support
We've managed to get things working by hardwiring the filtering scheduler to route instances to particular hosts that are running nova compute with different virtualization layers. (in our case, kvm and lxc for GPUs) -nld On Wed, Aug 22, 2012 at 12:34 PM, Michael J Fork mjf...@us.ibm.com wrote: Looking at the Hypervisor section of the documentation, http://docs.openstack.org/trunk/openstack-compute/admin/content/selecting-a-hypervisor.html, it states You cannot configure more than one virtualization type on the compute nodes, so the hypervisor selection is for the entire installation. Is this statement still true with the recent filter additions, specifically the ImagePropertiesFilter and ComputeCapabilitiesFilter? Thanks. Michael - Michael Fork Cloud Architect, Emerging Solutions IBM Systems Technology Group ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Migration
On Wed, Aug 29, 2012 at 12:19 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: Perhaps we should also have a CHANGELOG file to explain the major features/changes... Perhaps a 'MIGRATION' file as well that explains how to migrate from version - 1? I think that this would be a great start. In the long term, I would like to be able to do rolling upgrades across a system. It is important in the short term to understand dependencies between components as it pertains to versioning; ie, is it possible to run a folsom keystone with essex nova? Or could an essex nova-compute interact with a folsom nova-api? What are the hard and soft requirements for version mixing? I've had decent success performing rolling upgrades between versions of nova-compute in terms of the ubuntu maintenance releases of essex, but I suspect in general this is way too high of a bar to expect for all components. Even building a decent mental map of interdependencies would help a lot when planning maintenance activities. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] question about multi-host network configuration
Sure, we've been running in that sort of configuration since bexar. The only tricky part is that you need to make sure that you run nova-api-metadata on each nova-network server, and you need to make sure that floating IPs can get to the appropriate fixed addresses (ie if a fixed address is not routed from the nova-network instance where the floating address is served from). That last bit pretty much requires setting up something like ospf for route exchange between your nova-network servers. (fixed networks aren't pegged to one n-net instance or the other, so they can move over time) -nld On Mon, Sep 17, 2012 at 9:38 AM, Xin Zhao xz...@bnl.gov wrote: Hello, Our openstack cluster has 2 racks of physical nodes, I want to set up two openstack network service hosts, each serving one rack. Can I do that? Thanks, Xin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] multi-process-api-service
On Thu, Sep 27, 2012 at 2:20 PM, Nandavar, Divakar Padiyar (STSD) divakar.padiyar-nanda...@hp.com wrote: From the information available in the blueprint for multi-process-api-service I see that implementation has been completed and would be available as part of Folsom release https://blueprints.launchpad.net/nova/+spec/multi-process-api-service I see the advantage in back porting this to ESSEX as well. Any thoughts on this? Were there any discussion earlier on this topic for back porting to ESSEX? I'm not sure this is particularly needed for Essex. We're successfully running a bunch of discrete nova-api process across a few systems with Essex, load balanced using nginx, and it works great. This requires a little more work on the setup side, but it has proven stable for us. (it also allows us to service any of our machines that service nova-api requests without taking a user-visible hit, which is an added plus) -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] High bandwidth networking with openstack
I've finally finished my writeup describing the experiments that we performed using Openstack to drive a wide area 100 gigabit network. I've included all of the details for configuration and tuning, as well as speculation why we're seeing such good numbers. tl;dr: you can push a whole lot of network bandwidth out of an openstack deployment with kvm/virtio; we hit 98 gigabits peak with 10 instances across 50 ms of latency. The post is here: http://buriedlede.blogspot.com/2012/11/driving-100-gigabit-network-with.html I'm happy to discuss this in more detail, if there are additional questions. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How to Solve InfinitBand Adaptor Driver under Ubuntu 12.04?
We're using IB (QDR connectX and connectX2) on our system. It turns out that the drivers included in version 3.2 of the linux kernel are fine. I've built a ppa for updated management tools though; all of those bits are ancient in precise. The ppa is here: http://launchpad.net/~narayan-desai/+archive/infiniband One word of warning; you'll only be able to use IPOIB for connectivity between the hypervisor nodes and the openstack service nodes; getting to VMs requires full ethernet compatibility, which IPOIB doesn't provide. You will be able to use the IPOIB for fast image transfers and really fast volume storage if you have it. Turning on iSER helps a lot with volume bandwidth, but requires a patch to nova compute. -nld On Tue, Dec 25, 2012 at 7:03 AM, changliwe...@gmail.com wrote: Hi, Merry Christmas ! Have you even tried to use infinitband network in OpenStack base on Ubuntu 12.04? In recent two days, I want to use IPoIB in Ubuntu, but the big problem is the driver of IB, The OFED src is special for enterprise distribution only, such as (RHEL and SLES ), even the so called source code archive is a rpmbuild-tree-like structure. Then the question is how to solve the driver problem in ubuntu 12.04. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Structure Hybrid Compute Nodes
We have the same basic problems. We have 4 different types of systems integrated into our system. They all have different ratios of cpu to memory, and we have some specialized hardware on one class of nodes. We ended up setting up a series of chassis specific instance definitions. We then use the filter scheduler to only accept hosts with a particular configuration for the associated instance types. (for example, our large memory nodes will only run instances with the mem. prefix, and won't run generic instance types or ones for other hardware types -- it seemed silly to waste large memory resources on 1GB ram vms) It is pretty simple to write filter rules for the filter scheduler to set this up. You just need instance types and a hostname convention that you can use to matchmake. While this seems a little hacky, it works well. -nld On Tue, Jan 22, 2013 at 6:47 AM, Danilo Perogil dpero...@dualtec.com.br wrote: Hello everybody, Do you know of a way to set to work with OpenStack Computes Nodes containing different hardware? In my case, I did tests with different hardware, example 1 compute node with 24 processors and 128GB memory VS 1 compute node with 8 processors and 16GB of memory. In the test I saw he only makes division number of instances between total compute nodes, but it does a calculation for use by node. It is possible to make it work with some kind of calculation to not overload a node? Sorry my english google translate hahahah ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Openstack-operators] Help with simplest Quantum setup possible...
Make sure that the metadata server has a route back to the VM. Traffic hitting that NAT rule ensures that data is flowing properly in one direction, but you need to make sure bits can flow back to establish a tcp connection. We had this problem running multiple nova-network servers. -nld On Thu, Mar 14, 2013 at 2:28 PM, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: Daneyon, Thanks! But, I'm not using L3, or GRE, or namespaces... I read the http://docs.openstack.org/trunk/openstack-network/admin/content/ch_limitations.html and I don't think my setup (Single Flat, no GRE, no L3) fits that case... From my understandings, I'm not using overlapping IP's, since it is disabled by default... Anyway, after forcing `allow_overlapping_ips to False', nothing happens... From the compute node, I can connect to metadata by running: `telnet 10.32.14.232 8775' and / or `telnet 10.32.14.234 8775', both answer but, doesn't work in the end... I tried with metadata @ 10.32.14.232 (controller) and @ 10.32.14.234 (compute node with `nova-api-metadata') but, same broken result. From within my instance, when I run: `telnet 169.254.169.254 80', I can see the packages passing trough the NAT rule `169.254.169.254 tcp dpt:80 to:10.32.14.232:8775' but, the telnet connection times up. Do I need the package `quantum-plugin-metaplugin' instead `nova-api-metadata'? If yes, where, controller or on each compute node? BTW, if I set `use_namespaces = False' in dhcp_agent.ini, my Instances doesn't boots up anymore. Maybe it is time to go with Grizzly RC1? Anyway, I would like to finish everything I can with Quantum in Folsom, before going to try Grizzly... I really appreciate your help!! Regards, Thiago On 14 March 2013 15:21, Daneyon Hansen (danehans) daneh...@cisco.com wrote: Take a look at the limitations section of the Quantum docs. You will need to set allow overlapping IP's to false and make sure you have bidirectional network connectivity between the metadata ip and the tenant private network(s). The L3 agent.ini also should be configured with the metadata ip. The docs cover these topics in more detail. Regards, Daneyon Hansen On Mar 14, 2013, at 12:11 PM, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: Hi! My Quantum Single Flat is almost working! My Instance get an IPv4 without any problem but, the metadata isn't working... What can I do? My compute node have the `nova-api-metadata' package, nova.conf have `metadata_host = 10.32.14.234', the iptables `169.254.169.254' NAT rule is there too... The Instance log shows: Starting network... udhcpc (v1.20.1) started Sending discover... Sending select for 10.33.14.3... Lease of 10.33.14.3 obtained, lease time 120 deleting routers route: SIOCDELRT: No such process adding dns 8.8.4.4 adding dns 8.8.8.8 cirros-ds 'net' up at 1.84 checking http://169.254.169.254/2009-04-04/instance-id failed 1/20: up 1.87. request failed failed 2/20: up 13.98. request failed failed 3/20: up 26.02. request failed failed 4/20: up 38.06. request failed failed 5/20: up 50.09. request failed failed 6/20: up 62.13. request failed failed 7/20: up 74.16. request failed failed 8/20: up 86.20. request failed failed 9/20: up 98.24. request failed failed 10/20: up 110.27. request failed failed 11/20: up 122.31. request failed failed 12/20: up 134.34. request failed failed 13/20: up 146.38. request failed failed 14/20: up 158.41. request failed failed 15/20: up 170.45. request failed failed 16/20: up 182.49. request failed failed 17/20: up 194.52. request failed failed 18/20: up 206.56. request failed failed 19/20: up 218.59. request failed failed 20/20: up 230.63. request failed failed to read iid from metadata. tried 20 no results found for mode=net. up 242.66. searched: nocloud configdrive ec2 failed to get instance-id of datasource Starting dropbear sshd: generating rsa key... generating dsa key... OK Any clue? Thanks! Thiago On 13 March 2013 10:10, Daneyon Hansen (danehans) daneh...@cisco.com wrote: Regards, Daneyon Hansen On Mar 13, 2013, at 1:04 AM, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: Guys, Here: http://docs.openstack.org/trunk/openstack-network/admin/content/demo_flat_installions.html ...at the step 1. Install the L2 agent. but, what is the name of the Ubuntu package (I'm using Folsom)? ...apt-get install what? quantum-plugin-openvswitch-agent I thought that the Quantum L2 agent was the package `quantum-plugin-linuxbridge' but, this doc uses OpenvSwitch... So, I'm confused now... As you know Quantum uses plugins to realize the network abstractions. Some plugins (such as OVS) use an agent to collect information from the Quantum db to implement the logical data model on the local vswitch. The following packages quantum-server quantum-plugin-openvswitch quantum-plugin-openvswitch-agent quantum-dhcp-agent will be enough for
Re: [Openstack] Non responding instance
And if a nova reboot fails, you can always fall back to issuing virsh commands on the node behind nova's back. -nld On Mon, Apr 8, 2013 at 8:28 PM, Blair Bethwaite blair.bethwa...@gmail.com wrote: Dave, Have you tried rebooting it (via OpenStack dashboard/CLI/API)? Obviously you'll lose memory state, but the VM will boot from the same (current) virtual disks, so if those disks are ok the instance will have all previously saved/altered data. On 8 April 2013 19:09, Dave Pigott dave.pig...@linaro.org wrote: Hi all, I've got an instance that's been running for several months now, and suddenly we can not ping or telnet to it. It shows up in the list as Active and Running, but just isn't responding. We earlier had a disk full problem on that node, but this happened before that occurred, so I don't think that's responsible (but I could be wrong). The instance is used extensively so I'd prefer to fix it rather than have to kill it and spin up another instance. FYI all other instances in the cloud are fine and we can ssh and ping them. Any ideas what I can do to get this instance active again? Thanks Dave Lava Lab Lead Linaro Ltd ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Cheers, ~Blairo ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] What's the package flow in vlan mode when ping the floating ip between vms.
This will depend on whether the VMs are in the same tenant network or not. Assuming they are on the same L2 and L3 network, then the packets will transit either the linux bridge, or openvswitch, depending on how you have things configured. Note that network filtering rules will be processed on this path in some cases. If you are talking about flows between VMs that are on different tenant networks (both ends using RFC1918 addresses), nova-network would setup gateways for each network in the host, and it should be routing, i think. (this is supposition on my part -- we've only done some basic experiments with multi-host) -nld On Tue, Apr 9, 2013 at 7:41 PM, Lei Zhang zhang.lei@gmail.com wrote: Hi JuanFra, I read this article. But It doesn't explain what I concern. What I want to know is that what's the packet flow when ping the floating ip between the VMs which located in the same physical machine? On Tue, Apr 9, 2013 at 9:56 PM, JuanFra Rodriguez Cardoso juanfra.rodriguez.card...@gmail.com wrote: Could this Mirantis' post help you? http://www.mirantis.com/blog/vlanmanager-network-flow-analysis/ --- JuanFra 2013/4/9 Lei Zhang zhang.lei@gmail.com I am using: Folsom, nova-network, vlanManage, multi_host=ture I want to know what's the package flow between the vms which located in the same physical machine. Here is the typology. I want to know want happen if I ping 192.168.3.47 in vm7. When the NAT is applied? |vm: fixed: 10.0.104.5, floating: 192.168.3.56|-|vnet15||br104||vnet14|| vm7: fixed: 10.0.104.6, floating: 192.168.3.57| if the net.bridge.bridge-nf-call-iptables=0, I can not see the NAT properly. [root@openstack-node1 ~]# tcpdump -i vnet14 -l -ne icmp -v tcpdump: WARNING: vnet14: no IPv4 address assigned tcpdump: listening on vnet14, link-type EN10MB (Ethernet), capture size 65535 bytes 17:11:10.275818 fa:16:3e:3e:ab:8f fa:16:3e:72:8f:b4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.0.104.6 192.168.3.56: ICMP echo request, id 31090, seq 1, length 64 17:11:10.277546 fa:16:3e:22:31:09 fa:16:3e:3e:ab:8f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 64703, offset 0, flags [none], proto ICMP (1), length 84) 10.0.104.5 10.0.104.6: ICMP echo reply, id 31090, seq 1, length 64 When net.bridge.bridge-nf-call-iptables=1, I found the NAT properly. But I also found it is said the bridge filter should be disabled in http://docs.openstack.org/trunk/openstack-compute/admin/content/network-troubleshooting.html. Is this true? [root@openstack-node1 ~]# tcpdump -i vnet14 -l -ne icmp -v tcpdump: WARNING: vnet14: no IPv4 address assigned tcpdump: listening on vnet14, link-type EN10MB (Ethernet), capture size 65535 bytes 17:13:40.507577 fa:16:3e:3e:ab:8f fa:16:3e:72:8f:b4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.0.104.6 192.168.3.56: ICMP echo request, id 42098, seq 1, length 64 17:13:40.508034 fa:16:3e:22:31:09 fa:16:3e:3e:ab:8f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 64704, offset 0, flags [none], proto ICMP (1), length 84) 192.168.3.56 10.0.104.6: ICMP echo reply, id 42098, seq 1, length 64 -- Lei Zhang Blog: http://jeffrey4l.github.com twitter/weibo: @jeffrey4l ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Lei Zhang Blog: http://jeffrey4l.github.com twitter/weibo: @jeffrey4l ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Share Glance between cells or regions
+1. We're going to be running a bunch of parallel deployments of openstack for the purpose of experimentation in system design. it would be nice to be able to share glance and keystone between instances. -nld On Wed, May 15, 2013 at 1:46 PM, John Paul Walters jwalt...@isi.edu wrote: Hi, We're looking at setting up a geographically distributed OpenStack installation, and we're considering either cells or regions. We'd like to share a single Glance install between our regions (or cells), so the same images can be spawned anywhere. From here: http://docs.openstack.org/trunk/openstack-ops/content/segregate_cloud.html it's not clear whether that's possible. Can anyone shed some light on this? Is it possible in regions OR cells (or both)? Is there a better solution that I'm not thinking of? thanks, JP ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
