Ask Your Question

joshuamiller01's profile - activity

2016-11-29 08:32:19 -0600 received badge  Nice Question (source)
2015-08-24 11:14:47 -0600 received badge  Famous Question (source)
2015-08-21 11:51:59 -0600 commented answer VM network interface reordering

So, if you nova boot say 10 VMs with multiple NICs, and then nova stop, and nova start them, the interfaces all stay static for all of the VMs?

2015-08-19 15:44:48 -0600 received badge  Notable Question (source)
2015-08-19 13:35:00 -0600 commented answer VM network interface reordering

Yes; the interfaces all work fine (come up, dhcp successfully, can pass traffic, etc). The problem is that the order can be swapped after the first boot, which causes me a bunch of issues. I'm trying to establish how to prevent the order from changing.

2015-08-19 11:37:02 -0600 commented answer VM network interface reordering

Right - this is how I spin up my systems. The problem is that the NIC order can change after initial provisioning, which breaks a bunch of things (as described in the OP).

2015-08-19 04:26:14 -0600 received badge  Popular Question (source)
2015-08-18 17:31:21 -0600 commented answer VM network interface reordering

How does neutron / nova know how many interfaces to set up if it's only specified within the image itself? I'm referring to DHCP entries, bridges, the VM bridge interfaces in the XML definition, etc...

2015-08-18 11:58:33 -0600 asked a question VM network interface reordering

In my environment I have multiple network interfaces on my VMs. I've found that 'nova boot' always honors the order of the NICs, but that oftentimes (roughly 50% out of 100 VM sample) the interfaces are reordered following stop / start / rebuild actions. For the VMs which are affected, I can observe in the xml definitions that the MACs on the PCI buses are swapped. From a networking perspective, everything still works: the interfaces can come up, are mapped to the right VLANs, gets addresses from DHCP, pass traffic, etc. However, I've found that there are a number of things in my environment that expect the interface ordering to stay the same throughout the life of the system.

The most recent problem, and one I haven't been able to think up a solution for, has been the following: routing for the metadata service ( i.e. http://169.254.169.254/latest/meta-da... ) is facilitated by static routes served out by DHCP, but with multiple NICs on the VM, the VM gets multiple static routes for the same destination. It seems the metadata service knows the host by its "first" IP, such that when the routes conflict and the requests go out the second interface, the metadata service fails. I thought I had beat this by modifying the dhcp client config on my VMs to not request static routes from the second interface ("eth1"), which works, but if the interface order isn't dependable, "eth1" doesn't really mean anything. I can cover the stop / start case with udev rules that force the interface names based on MAC address, but in the rebuild case, this isn't an option.

The core problem: how can I force my NICs to stay in the same order as was originally defined by 'nova boot' ?

Some details on my components: juno, kvm, ubuntu Trusty hosts, neutron with VLANs, running ubuntu VMs

2015-08-08 12:34:04 -0600 received badge  Famous Question (source)
2015-07-07 18:07:45 -0600 received badge  Enthusiast
2015-06-29 11:43:55 -0600 received badge  Notable Question (source)
2015-06-26 01:25:46 -0600 received badge  Student (source)
2015-06-26 01:25:37 -0600 received badge  Popular Question (source)
2015-06-25 13:41:31 -0600 asked a question Change metadata_urls in cloud-init

I host my metadata service on a specific IP, not on the default 169.254.169.254. I've changed /etc/cloud/cloud.cfg in my virtual machine image to specify a datasource url:

datasource: Ec2: metadata_urls: [ 'http://10.1.1.123:8775' ]

This eventually works - I can see that cloud-init will reach out to this and work with the metadata service, but there's a clear pause during the initial provisioning, and I can see from a packet capture that the system first tries to communicate with the 169.254.169.254:80 default end-point (thus the stall).

00:26:07.470359 IP 10.1.2.3.36269 > 169.254.169.254.80: Flags [S]

Where (else) do I need to change this to prevent the system from wasting time trying to hit the default metadata url?

2015-04-20 00:35:55 -0600 commented answer How can I extend nova metadata to alter the user data after VM's boot?

Only way I've found to change user-data has been through the DB. I detailed how to do it in mysql for grizzly / havana @ http://www.asmatteringofit.com/blog/2015/4/18/updating-user-data-for-existing-openstack-vms (http://www.asmatteringofit.com/blog/2...)