dchp active on private network with ip option #312
Comments
|
ok... this seems to be at least somehow related to the concrete fedora box i am using... |
|
Really strange:
|
|
Here is the decisive extract of the debug output of initially booting fedora21: This sounds very similar to what has been reported and discussed in vagrant a long |
|
More info: Strangely, if I ifdown eth1, systemctl restart NetworkManager and then ifup eth1, the dhclient disappears and the network interface is configured as desired. When I vagrant halt ; vagrant up, then the eth1 interface is not started. I have to manually ifup eth1 in the vm for it to get an IP address. |
|
A few issues: You need to specify which versions of things you're using:
and as we discussed offline, if you've been able to reproduce the issues using a stock https://github.com/purpleidea/oh-my-vagrant configuration. |
|
As written in the initial comment:
I tested with omv, but then I realizied why I did not test it before: Just like your omv does, I tried to disable dhcp in the Vagrantfile for the private network by setting So I don't even get to the point where the machine is started. I also think that running with a completely minimal Vagrantfile is the better test According to my analyis above, vagrant-libvirt tries to do the |
|
This might be related to the bug I'm seeing in: https://bugzilla.redhat.com/show_bug.cgi?id=1221006 |
|
Having a similar problem, except I don't see any evidence that Vagrant is even trying to configure my network from the Vagrantfile. No matter how I specify network setting, when I 'vagrant up' they all seem to be ignored, and DHCP is used to configure a single eth0 interface. I've tried this with public and private networks. My Vagrantfile: |
|
@Momus Small unrelated note: You have HTH maybe you can figure out our networking issues :) |
|
@purpleidea Thanks for catching that. Unfortunately, that wound up being placed there when I was trying to clean up the file for Pastebin, and fixing it had no effect (I just checked) OTOH, 'vagrant up' with libvirt is really fast when it doesn't have anything to hang it. |
|
I experienced the same issue using:
After extensive testing I realized that the weird behaviour (double IP addresses when DHCP is on) exists only immediately after first It is not ideal, but it may be acceptable as a workaround.
|
|
AFAIK there were some changes in vagrant 1.8.1 that affect the config snippets that Vagrant uses to configure interfaces in guests. Unfortunately there is no fully working Vagrantfile here (could not find that opscode freebsd 10.1 libvirt box anywhere) If this issue still persists, please retest under vagrant 1.8.1 and vagrant-libvirt 0.0.33 and if it still persists please post:
|
|
As requested in the previous post, I re-produced the issue on the following system:
The RPMs above are from default Fedora 23 repository. To re-iterate, the problem is that running See below:
Problematic
|
|
These inputs and results are identical to the previous post above with the only difference: vagrant-libvirt is version 0.0.33 (not 0.0.32). Setting required IP address in guest VM still fails. The tests were done on identical host machine (some output paths, IPs, MACs, and any other hosts-specific values may be different) - again, see in the previous post above. In order to install
|
UltimatelyThere is no known way to have specific fixed IP address assigned by Vagrant on private network. This is true and consistently reproducible at least with CentOS 7.1 with the software versions used in the tests above. NOTE: For example, if you switch box from CentOS 7.1 ( UPDATE: As it turns out below, the "known way" is to use lowercase MAC addresses. There will just be one issue left to be fixed - refresh of network state by Vagrant based on newly added MAC=>IP mapping. |
|
I think I have a clue to solve the problem. CauseI re-tested the example above on recent F24 x86_64 and the issue persists. For example, this is the difference of (L) initial XML output and (R) XML output after modifications (see below in this post) - the WorkaroundTo workaround this issue (automated in our continuous integration) this script can be used: SolutionI guess the |
|
So for the @uvsmtid is describing, the bug is not in vagrant-libvirt but in Vagrant: In vagrants # Read interface MAC addresses for later matching
mac_addresses = Array.new(interface_names.length)
interface_names.each_with_index do |ifname, index|
machine.communicate.sudo("cat /sys/class/net/#{ifname}/address") do |_, result|
mac_addresses[index] = result.strip
end
endThis is reading a lowercase mac address, e.g. # as what interfaces we're actually configuring since we use that later.
interfaces = Set.new
networks.each do |network|
interface = nil
if network[:mac_address]
found_idx = mac_addresses.find_index(network[:mac_address]) # <--- right here
# Ignore network if requested MAC address could not be found
next if found_idx.nil?
interface = interface_names[found_idx]
else
ifname_by_slot = interface_names_by_slot[network[:interface]-1]
# Don't overwrite if interface was already matched via MAC address
next if interfaces.include?(ifname_by_slot)
interface = ifname_by_slot
endSo @uvsmtid that bug should be reported to Vagrant, not vagrant-libvirt. I will update the documentation that the mac address should be specified in lowercase, but it's really a workaround for this problem in Vagrant itself. The initial issue mentioned above appears to be a box issue where the box starts a dhcp client by default on any interface, and then when Vagrant (and not vagrant-libvirt) reconfigures the interface, it doesn't stop the already started dhcpi client. That too is not a vagrant-libvirt specific issue. I am therefore closing this as invalid, but feel free to reopen them if there's a concrete issue that vagrant-libvirt has and can be reproduced. |
|
Cross-reference to newly created Vagrant issue: hashicorp/vagrant#7566 Forcing MAC-to-IP mapping into
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
this has been discussed before (e.g. issue #103). But this is quite some time
ago and the issues have been closed. I am facing this issue with latest varant
and latest vagrant-libvirt using purpleidea's fedora21 base box:
I have a libvirt network interface internal1 which has a network 172.20.10.0/24.
DHCP is enable on that network for the upper half of the range. In my Vagrantfile
I specify a private network like this:
config.vm.define 'hostname' do |node|
...
node.vm.network :private_network, :ip => 172.20.10.10
...
end
When I initially create the vm with 'vagrant up', it finds the
network internal1 and associates the address. It even drops
a file /etc/sysconfig/network-scripts/ifcfg-eth1 with the following
content:
But nevertheless dhclient is also active on the interface
and I hence get two ips, which is not what I want.
So the first question is how to disable dhcp on the private
network with a configured IP.
Now things get even more strange:
When I vagrant halt and then vagrant up the box, then
the interfaces is not brought up at all, at least there are
no IPs at all associated to it. And doing ifup in the vm
does not help either.
The vagrant-libvirt management interface works fine.
Vagrant-libvirt created it for me attached to bridge virbr5.
This is using dhcp as desired, and I can vagrant ssh into
the machine.
Any help would be appreciated!!!
Cheers - Michael
The text was updated successfully, but these errors were encountered: