Hi, I have the following openvz setup: 2.6.8-022stab064-up on Debian Sarge. HN and VPS (101, 102, 103, 104) on subnet 192.168.0.0 I decided to add Samba to VPS 104. Reading the forums, I learned that a VPS cannot send and receive broadcast signals, needed by Samba. Since I had 2 nic cards, I did: Quote: vzctl set 104 --netdev_add eth1 --save Logged into VPS 104, I put the following in /etc/network/interfaces.template: Quote: auto eth1 iface eth1 inet static address 192.168.0.104 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 gateway 192.168.0.254 Logged into the HN, I removed any config for eth1. 2 Problems: 1. Logged into VPS 104, I cannot ping the HN or the other, regular VPSs. Logged into the HN, I likewise cannot ping VPS 104. How do I enable communication between VPS 104 and the HN/other VPSs. 2. Logged into VPS 104, if I do ifconfig -a, I see that both eth1 and venet0 are up. Is this right? Shouldn't venet0 be turned off when running VPS 104 from eth1. If this is true how do I prevent venet0 from getting configured when restarting VPS 104. Thank you.
To get rid of venet device look at these thread http://forum.openvz.org/index.php?t=tree&th=270&mid= 1489&&rev=&reveal= However the presense of venet device should not break network connectivity. Quote: Logged into VPS 104, I cannot ping the HN or the other, regular VPSs. Logged into the HN, I likewise cannot ping VPS 104. Can you ping anyone else in network? Please, do ifconfig -a and route -nv in VE and on HN and post the results here. Thanks!
Hello Vass, Thank you for your response. To answer your requests: Quote: Can you ping anyone else in network? Quote: Please, do ifconfig -a and route -nv in VE and on HN and post the results here. Please note that I have encounter new problems since rebooting the HN, which I will detail first before answering your requests: Problem 1: The booting sequence proceeded normally until booting VE 104. At this point, I received the following message. Quote: martian source 192.168.0.255 from 192.168.0.104, on dev eth0 || header: ff:ff:ff:ff:ff:ff:00:50:fc:72.56.44.08:00 Shortly after the HN system became unresponsive and required a cold reboot. Upon rebooting a second time, the "martian source" message did not reappear, and the HN remained responsive. Problem 2: I could neither ssh nor ping VE 104. To remedy this, I did: Quote: $ cd /vz/private/104/etc/network $ mv interfaces.template interfaces.template.off I then rebooted VE 104 and was able to log in successfully. Here are the details of ifconfig -a and route -nv: ifconfig -a Quote: eth1 Link encap:Ethernet HWaddr 00:50:FC:72:56:44 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:61 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:10248 (10.0 KiB) Interrupt:11 Base address:0xd400 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:86 errors:0 dropped:0 overruns:0 frame:0 TX packets:86 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11060 (10.8 KiB) TX bytes:11060 (10.8 KiB) venet0 Link encap:UNSPEC HWaddr 00-00-FF-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:127.0.0.1 P-t-P:127.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:187 errors:0 dropped:0 overruns:0 frame:0 TX packets:112 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16380 (15.9 KiB) TX bytes:14481 (14.1 KiB) venet0:0 Link encap:UNSPEC HWaddr 00-00-FF-FF-FF-FF-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.0.104 P-t-P:192.168.0.104 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 route -nv Quote: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 191.255.255.1 0.0.0.0 255.255.255.255 UH 0 0 0 venet0 0.0.0.0 191.255.255.1 0.0.0.0 UG 0 0 0 venet0 Obviously, eth1 is not functioning in the present configuration. To make it functional, I will log into VE 104 and make the eth1 boot configuration file active again. Here are the details of that file: /etc/network/interfaces.template Quote: auto eth1 iface eth1 inet static address 192.168.0.104 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 gateway 192.168.0.254 Now I will reboot VE 104 from the HN. Details are: vzctl restart 104 Quote: Restarting VPS Stopping VPS ... VPS was stopped VPS is not mounted Starting VPS ... vzquota : (warning) Quota is running for id 104 already VPS is mounted Deleting IP address(es): 192.168.0.104 SIOCSIFFLAGS: Cannot assign requested address Adding IP address(es): 192.168.0.104 Setting CPU units: 1000 Set hostname: vz4.lan.rmt File resolv.conf was modified VPS start in progress... Note that I can no longer ping nor ssh into VE 104, which means I cannot reproduce the situation I was in when I started this thread. Meanwhile, I have noticed 2 clues which may point to a solution to this problem. They are: The martian source message I received before the HN became unresponsive and SIOCSIFFLAGS: Cannot assign requested address Here are a few details regarding my attempted network setup: HN - 192.168.0.7 - eth0 VE 1 - 192.168.0.101 - eth0 VE 2 - 192.168.0.102 - eth0 VE 3 - 192.168.0.103 - eth0 ======================= VE 4 - 192.168.0.104 - eth1
Looks like eth1 and venet0 are both trying to grab the same ip address, .104. That would be a problem. Try changing eth1 to .204 and see if that helps. That may not be the final solution you are looking for, it's just a testing step to help narrow down the problem.
Thanks for your response, John. Your suggestion sounds like a good one. I have not yet had the chance to verify it, but would like to add the following about the VE 104 set up: VE 104 was initially set up to use 192.168.0.4 on the venet0 interface. Later, I decided to add add eth1 to VE 104 using the Quote: vzctl set 104 --netdev_add eth1 --save command. If I log in to VE 104 and do ifconfig -a I can see the eth1 interface, although it is not functioning. Problems occur once I set eth1 within VE 104 to 192.168.0.4. Vass posted the following: Quote: However the presense of venet device should not break network connectivity. This is true, perhaps, if venet0 has not been previously set to an ipaddress. In my case, I had already set the VE 104 ipaddress from the HN, as in: Quote: vzctl set 104 --ipadd 192.168.0.104 --save Although I haven't yet determined if this is the solution ,I look forward to hearing what Vass has to say about this. Ferp2
I did Quote: vzctl set 104 --ipdel 192.168.0.104 --save and that seemed to solve some of the problems, however, there's still a conflict between the eth1 configuration and venet0, as I couldn't contact any hosts outside of the immediate subnet. The solution was to log in to VE 104 and do Quote: ifconfig venet0 down How do I configure the VE 104 so that I don't have to manually shutdown venet0 each time I restart the server? Thanks
Why don't you remove venet using http://forum.openvz.org/index.php?t=tree&goto=1516&# msg_1516, how I offered in my previous answer? HTH, vass.
Hello, In response to your recommendation: Quote: You need to comment out network setup in /etc/init.d/vz: sed -i 's/\(.*setup_net\)$/#\1/' /etc/init.d/vz /etc/init.d/vz restart If you don't want restart service vz, then: stop your VPSs, ifconfig down venet0, rmmod vznetdev Correct me if I'm wrong, but it looks like the above solution removes the venet0 interface for all VEs, whereas I only want to remove venet0 from VE 4 (now using the eth1 interface), but leave the venet0 interface functioning on VEs 1, 2 and 3. Thank you.
ferp2 wrote on Tue, 17 October 2006 09:04 I only want to remove venet0 from VE 4 (now using the eth1 interface), but leave the venet0 interface functioning on VEs 1, 2 and 3. You can make your own custom VE scripts. In /etc/vz/conf, make a new [xxx].conf file, edit it, and set OSTEMPLATE=mydist, where [mydist] is some arbitrary name you like. Then, in /etc/vz/dists, copy one of the .conf files (whichever one suits your needs) and call it mydist.conf. Edit it, and set ADD_IP=mydist-add_ip.sh and DEL_IP=mydist-del_ip.sh. Then in etc/vz/dists/scripts, choose a set of -add_ip.sh and -del_ip.sh scripts, and copy them to mydist-add_ip.sh and mydist-del_ip.sh, respectively. Then start hacking the new scripts. This may require more effort than you had in mind, but once you learn how the scripts work, you can do most anything you want. I don't know an easier way, maybe someone else does.
Sounds like the right way to go. I'll give it a try. Thanks