Hello, My suggestion are based in a mix of what I see and what I know. I am a former RedHat Instructor (from rh9 upto rhel5), plus what I do, and I use at home.
(udev rules) When a fedora or redhat (or his derivates) machine in a *non xen* environment start, in order to have the network cards pinned, it will create the persistent-net file, based on the mac address, this is because you usually ADD more nics in a physical server, so once you have eth0 and eth1, and you add a new nic, to avoid issues, as eth0 and eth1 are pinned, the new ones will become eth2 and so on.. the downside of this, is, when you remove one of the cards, you get holes and you won't be able to use it.. , so you remove the persistent-net file and reboot. (hwaddr in conf file) in a total separate side, on each ifcfg-ethN file, you can have HWADDR= to identify the nics, so you can have always the same nic as eth0, even if you add or remove cards. Think a physical server that have 6 NICs, which one is eth0 when you look from the back? it's prett messy, so you pin them and you are happy. For virtual machines, this is not required, as the virtual pci bus and the card ware the same, so if you add a new card, will be always at the end. (network manager) not all the linux machines are created the same, say you install a redhat 6 with minimal packages, the network manager is not used.. but if later you install group desktop, that will install network manager.. and network manager is more fridnly when you use the machine as desktop and ypou log ove tthe gui, but having a machine that is head less or you use more over the network, NetworkManager can cause more troubles.. one thing I have noticied is sometimes you edit the ifcfg-ethN file, and network manager sense it and try to reset the network and lock you down.. (have happened twice on remove computers I have at home), so best is leave the nics out of network manager. so, at some point, you need to chose, do all properly, or go for the simple path, and remove what cause troubles. Hope this helps, Alvaro On Fri, Feb 28, 2014 at 5:56 AM, blong <brianbl...@gmail.com> wrote: > Hi all, I believe I've resolved the issue that I was having (similar to > this thread) and was hoping to get some feedback from someone. This thread > seemed to resolve my problem, but I wanted to try and really pinpoint the > error I saw. It seems pretty clear that a properly configured network is > essential to creating a reliable .box file (e.g. this wiki > page<https://github.com/mitchellh/vagrant/wiki/%60vagrant-up%60-hangs-at-%22Waiting-for-VM-to-boot.-This-can-take-a-few-minutes%22>). > > > Here's what I experienced: > > VBoxManage version: 4.3.6r91406 > Vagrant version: 1.4.3 > CentOS version: 6.4 (Final) > > When I run 'vagrant up', I get this output: > > [default] -- 22 => 2222 (adapter 1) > [default] Booting VM... > [default] Waiting for machine to boot. This may take a few minutes... > > Timed out while waiting for the machine to boot. This means that > Vagrant was unable to communicate with the guest machine within > the configured ("config.vm.boot_timeout" value) time period. This can > mean a number of things. > > If you're using a custom box, make sure that networking is properly > working and you're able to connect to the machine. It is a common > problem that networking isn't setup properly in these boxes. > Verify that authentication configurations are also setup properly, > as well. > > If the box appears to be booting properly, you may want to increase > the timeout ("config.vm.boot_timeout") value. > > > At this point, 'vagrant ssh' does not work, however, I can login to the VM > with the UI. When I login, I can see that eth0 and eth1 come up with the > same IP address (192.168.50.102), although different MAC addresses (eth0 > has 08:00:27:60:FC:47 and eth1 08:00:27:67:F8:71) . Next, I took a look at > /etc/sysconfig/network-scripts/ . > > Contents of ifcfg-eth0 > > DEVICE="eth0" > BOOTPROTO="dhcp" > IPV6INIT="yes" > NM_CONTROLLED="yes" > ONBOOT="yes" > TYPE="Ethernet" > UUID="56f45b3e-..." > > > Contents of ifcfg-eth1 > > #VAGRANT-BEGIN > # The contents below are automatically generated by Vagrant. Do not modify. > NM_CONTROLLED=no > BOOTPROTO=none > ONBOOT=yes > IPADDR=192.168.50.102 > NETMASK=255.255.255.0 > DEVICE=eth1 > PEERDNS=no > #VAGRANT=END > > > I can resolve this one of 2 ways: > > 1) Simply running "sudo service network restart" from the UI. This > properly configures the network and from then on I'm able to run 'vagrant > halt', 'vagrant ssh', etc. > -or- > 2) By fixing the network configuration re-packaging (so that anyone using > my .box file can run without issues). To achieve that, I basically > followed Alvaro's earlier > email<https://groups.google.com/d/msg/vagrant-up/GGtZSzHMLUQ/6B43VRZeYw0J>on > this thread, however I did a few things differently (in error). In any > case, I published a box file that I believe is configured properly by doing > the following : > > > 1. > > As root or with sudo : > 1. > > rm /etc/udev/rules.d/70-persistent-net.rules > 2. > > chkconfig NetworkManager off > 3. > > edit /etc/sysconfig/network-scripts/ > 1. > > Edit ifcfg-eth0 > 1. > > Remove UUID // per Alvaro, but now I'm thinking this wasn't > necessary > 2. > > Set NM_CONTROLLED="no" > 2. > > Edit ifcfg-eth1 > 1. > > Set NM_CONTROLLED="no" // Used the form with double quotes. > Does this matter? > 2. > > Then, shutdown the VM cleanly and run "vagrant package" to create the > .box file. > > > In Alvaro's email, the instructions say to just remove the eth1 config > file and let Vagrant create it. Is that the correct solution, I didn't > follow that as I was concerned Vagrant would not create the ifcfg-eth1 file > with NM_CONTROLLED="no". However, one would think that running "sudo > chkconfig NetworkManager off" would mean NM_CONTROLLED is ignored, right? > > > I appreciate any feedback and thanks in advance! > > > On Friday, February 14, 2014 5:26:14 AM UTC-5, Peter Halliday wrote: >> >> and then restarted the firewall and it still works - even after reboot >> >> I did notice that before I restarted the firewall, iptables -L did not >> list ssh and actually listed mdns or something >> It's fixed now and iptables -L lists: >> >> ACCEPT tcp -- anywhere anywhere state NEW >> tcp dpt:ssh >> >> I restored from the snapshot i took before i started messing with stuff >> and iptables -L in the broken configuration lists >> >> ACCEPT udp -- anywhere 224.0.0.251 state NEW >> udp dpt:mdns >> >> I then just ran >> >> system-config-firewall >> >> and performed the following sequence to fix the iptables config >> >> disable >> apply >> enable >> apply >> >> I'm going to leave it at that and rebuild my base box :) >> >> >> On Friday, 14 February 2014 11:16:40 UTC+1, Peter Halliday wrote: >>> >>> correction i just got it to work by disabling the firewall :s >>> >>> On Friday, 14 February 2014 10:53:06 UTC+1, Peter Halliday wrote: >>>> >>>> fedora 17 - I have also tried >>>> >>>> systemctl disable NetworkManager.service >>>> >>>> instead of chkconfig >>>> >>>> but it doesn't make a difference. >>>> >>>> This doesn't seem to be a vagrant problem - I noticed that the >>>> original VM won't accept connections either. >>>> >>>> I manually added a a forwarded port from 2222 to 22 and then tried >>>> >>>> ssh localhost -p 2222 >>>> >>>> but it just hangs >>>> >>>> I verified that sshd is running and can connect from inside the VM to >>>> itself with ssh >>>> I also checked the firewall which is on but allowing ssh on port 22 (I >>>> also tried disabling the firewall just to be sure) >>>> >>>> Also whereas earlier i did get it to respond after messing with the >>>> network settings in virtual box, I can no longer reproduce that either :s >>>> >>>> On Friday, 14 February 2014 02:09:57 UTC+1, Alvaro Miranda Aguilera >>>> wrote: >>>>> >>>>> >>>>> On Fri, Feb 14, 2014 at 12:03 PM, Peter Halliday >>>>> <pghal...@gmail.com>wrote: >>>>> >>>>>> p2p1 >>>>> >>>>> >>>>> >>>>> hey, that could be the reason.. >>>>> >>>>> what version of fedora are you using? >>>>> >>>>> >>>>> >>>>> >>>>> -- > You received this message because you are subscribed to the Google Groups > "Vagrant" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to vagrant-up+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Vagrant" group. To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
