We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

Proxmox 1.5 tips, including bridged networking


DigitalDaz
04-02-2010, 20:33
Myatu, when I say the VM's IP I am refering to the container or KVM virtual machine, not the main server IP so for example the container is

IP 1.2.3.4
Mask 255.255.255.255
GW 1.2.3.4

Myatu
31-01-2010, 10:00
@brgroup: Thanks for the kudos, and I'm glad this worked for you

@DigitalDaz: I've been looking in this server IP vs. server Gateway thing. It apparently depends on how it resolves for the gateway (ie., it resolves to rbx-16.routers.ovh.net and not someone else's machine). But also, you need to keep in mind that using the server IP makes your VMs rely on its availability. As I have found out the hard way, this is not something you'd want (main IP down, all VMs down) - bridging with the appropriate IP will allow for the main IP to become unroutable, whilst the VM's remain accessible. This is what I've been struggling with for the last week actually, since my static IP dies at a certain point at night (some sneaky process... OVH is looking into it).

DigitalDaz
30-01-2010, 21:16
I use my VM's IP as the gateway and this goes for both containers and KVM. This is also the same set up I use when using proxy ARP too.

brgroup
30-01-2010, 20:29
Thanks Myatu for all your work and great posts...literally saving my behind right now..in fact I can see now why you like ProxMox so much, as over the last few days i have found too how deep and extensible the interface is. I am deploying at least one server to ProxMox and maybe converting the other..

I literally have been hanging on everyday for tech support my virtual mac issues, and while waiting, and waiting (going on 12 days so far) I dug into Myatu's ProxMox + Shorewall setup and was able to at least route my failover IP's through my host and out to the world..as simple as setting an ACCEPT flag in the firewall for my failover IPs..they connected immediately.

So my take is, if you're having problems with your virtual mac setup and getting your failover IPs connected to the world, be sure to try out Myatu's Setup or FRIDU's Firewall for OpenVZ. Just follow step by step..

Again good job Myatu..your knowledge is inspired!!

Myatu
25-01-2010, 14:43
Quote Originally Posted by kenzacm
Please not using the default gateway of your server will NOT work please use the STATIC IP of your physical server
I really wish OVH's support folks could comment on this. For a few users, like you kenzacm and IianK (see http://forum.ovh.co.uk/showpost.php?p=26487&postcount=2) you have to use the main server's IP address as the gateway. For others (like me and according to OVH's guide), you need to use same gateway as the main server's gateway address. So, which is it -- or better yet, how do you determine which one to use?

Anyway, glad it worked

kenzacm
25-01-2010, 13:34
What gateway to use - UPDATE

Please not using the default gateway of your server will NOT work please use the STATIC IP of your physical server

derchris
25-01-2010, 12:32
Quote Originally Posted by yatesco
I am glad - without his, and others (like dedicatedpro) help, I would be in an absolute mess!

Seriously, thanks for everybody's help!

(And sorry for diluting this thread with pithy little posts like this )
That is what a Forum is for.
Helping others out, and share what you have tested already.

yatesco
25-01-2010, 11:53
Quote Originally Posted by derchris
You like Proxmox, don't you?
I am glad - without his, and others (like dedicatedpro) help, I would be in an absolute mess!

Seriously, thanks for everybody's help!

(And sorry for diluting this thread with pithy little posts like this )

Myatu
25-01-2010, 10:07
Does it show?

derchris
25-01-2010, 09:42
You like Proxmox, don't you?

Myatu
25-01-2010, 04:54
Since you asked

MAC - IP association

First make sure you have a MAC associated with your Failover IP address. You can do this from the OVH Manager -> Dedicated Server -> Services -> MAC for VPS (select an OVH generated MAC address).

Prepare (or edit) the KVM in which Windows will be running as following:

For the network interface, use either r8191 or e1000 and link it to vmbr0 (not vmbr1). Remove the MAC generated by Proxmox and enter the MAC generated by OVH instead (02:00:...).

If you are editing an existing KVM, make sure to reboot it at this point.

Windows

Most of this is described here: http://help.ovh.co.uk/BridgeClient

Go to the Network Management (ie: Start -> Control Panel -> Network Connections -> Local Area Connections, or Start -> Control Panel -> Network and Sharing Center -> Manage Network Connections).

Select the interface, RIGHT-click and select Properties. Under the Networking tab, select Internet Protocol (TCP/IP) (or Internet Protocol Version 4 (TCP/IPv4)) and click the Properties button.

On the General tab, select Use the following IP address at which point you can enter the required information.

As the IP address you enter the failover IP address associated to the MAC address. As the Subnet mask you use 255.255.255.255. And as the Default Gateway you use the host node / main server's gateway.

In the section below it, select Use the following DNS server addresses. As the DNS you can add your preferred DNS server. For example, for OVH's DNS server, use 213.186.33.99.

After you apply these settings, I recommend restarting Windows to eliminate any potential issues.

What gateway to use

On Proxmox, the gateway address can be found from the Web Administration -> Configuration -> System -> Network tab under interface vmbr0.

Alternatively, you can find it by typing the following from the SSH command line:

Code:
ip route show dev vmbr0 | grep default
It will output what your gateway is, usually in the form of XX.XX.XX.254 (ending with .254).

Note: Other users have mentioned that instead of this gateway IP, you need to use the server's main IP address as the gateway! So your mileage may vary...

Note (24/04/2010): According to OVH: WARNING: Under no circumstances use the primary IP of your server as the gateway! ... or you could cut your IP from the virtual server.

Subnet Mask Issues

Also note that on some Window systems the Subnet mask 255.255.255.255 is invalid. In this case you use 255.255.0.0 as a temporary solution.

Next start Regedit with Start -> Run -> type "Regedit" -> OK and select Edit -> Find from its menu.

Now enter your failover IP in the provided field and make sure the Values box is ticked. Once it has found it, highlight and double click the SubnetMask field in the right-side panel, where you enter 255.255.255.255 as the Value Data.

Click OK and exit Regedit.

Checking Connectivity

Click Start -> Run -> type "cmd" -> OK (Alternatively, Start -> All Programs -> Accessoiries -> Command Prompt).

Now type "ping www.google.com" in the command line (without the double quotes) and hit Enter/Return. If everything is working properly, you should see this response:

Code:
Pinging www-tmmdi.l.google.com [66.102.9.105] with 32 bytes of data:
Reply from 66.102.9.105: bytes=32 time=23ms TTL=51
Reply from 66.102.9.105: bytes=32 time=20ms TTL=51
Reply from 66.102.9.105: bytes=32 time=17ms TTL=51
Reply from 66.102.9.105: bytes=32 time=13ms TTL=51

Ping statistics for 66.102.9.105:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 13ms, Maximum = 23ms, Average = 18ms
If so, then you're done and you have a working network connection. Congrats!

If instead you're seeing this:

Code:
Ping request could not find host www.google.com. Please check the name and try again.
Then the DNS settings you entered were incorrect or the DNS server is unreachable. To check, type "nslookup www.google.com 208.67.222.222" at the command line.

You likely have entered incorrect DNS settings if you get the following response:

Code:
Server:  UnKnown
Address:  208.67.222.222

Non-authoritative answer:
Name:    google.navigation.opendns.com
Addresses:  208.69.35.230
          208.69.35.231
Aliases:  www.google.com
So go back to the Windows section explained earlier and choose a different DNS server (yes, you can indeed use 208.67.222.222 as the DNS server - it's by opendns.com).

However, if you are receiving this response:

Code:
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  208.67.222.222

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out
Then most certainly your network settings are incorrect (Ie., incorrect IP address, subnet mask or gateway). Double check your settings as explained in the Windows section above.

If you insist that the settings are correct within Windows, try the following:

At the Windows command line, type "type /t 213.186.33.13". It will now continuously try to send a ping to OVH's ping server (you can stop it by pressing CTRL+C simultaneously).

Leave Windows running with this continuous ping while you SSH into your main server. After you have logged in with your credentials, type the following command from within Linux:

Code:
tcpdump -nS host 213.186.33.13 and icmp
It will start giving you details about what's happening with the ping from Windows (you can stop it by pressing CTRL+C). If it gives you this output:

Code:
03:48:39.085125 IP FA.IL.OV.ER > 213.186.33.13: ICMP echo request, id 14366, seq 1, length 64
03:48:40.089941 IP FA.IL.OV.ER > 213.186.33.13: ICMP echo request, id 14366, seq 2, length 64
03:48:41.093825 IP FA.IL.OV.ER > 213.186.33.13: ICMP echo request, id 14366, seq 3, length 64
... (etc) ...
Then it means Windows is properly sending out the ping, but it never left your server OR the main server is not receiving any responses (FA.IL.OV.ER is obviously the failver IP address)

In the latter case, make sure that you do not have any firewalls installed/enabled on the main server. You can usually verify this by typing "iptables -L" from the Linux (not Windows) command line. It should show:

Code:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
If it shows anything else than this, type the following command (all on the same line):

Code:
iptables -t nat -F && iptables -t mangle -F && iptables -F
And try again with tcpdump.

If you are getting a different output from tcpdump, like so:

Code:
03:48:39.085125 IP FA.IL.OV.ER > 213.186.33.13: ICMP echo request, id 14366, seq 1, length 64
03:48:39.089170 IP 213.186.33.13 > FA.IL.OV.ER: ICMP echo reply, id 14366, seq 1, length 64
... (etc) ...
Then Windows is the culprit instead. Go back to the Windows machine, stop the ping (press CTRL+C) and start checking if you have any Windows firewalls installed and/or enabled.

If you still do not have any connectivity, take the output from tcpdump and start a new topic in the Dedicated Servers forum (best not here), along with a short description of what you have tested so far.

kenzacm
25-01-2010, 01:43
any chance i could get the windows routing?

kenzacm
24-01-2010, 22:47
im going to give proxmox a try hehe, see if it eliminates all of my problems

Myatu
23-01-2010, 17:33
Just a heads up that OVH has Proxmox 1.5 available (although it says 1.4 in the OVH Manager).

You might also be interested in this Wiki article at Proxmox: http://pve.proxmox.com/wiki/Proxmox_VE_Kernel.

The Proxmox distro available at OVH comes with 2.6.24, which is the "latest and greatest" if you need both OpenVZ (containers) and KVM (fully virtualized) support.

If you only use KVMs, you might want to get the 2.6.32 kernel - it has the ability to share memory pages, which can significantly reduce the total memory usage ( = more KVMs per machine).

Regarding containers: I have found that using VENET network interface isn't always very reliable, especially when you mix both OpenVZ and KVM on the same server.

My personal recommendation is to use VETH instead. In fact, you now need to use VETH interfaces on containers if you want to directly assign a failover IP address to a it. This is because you need to use the MAC address assigned to the failover IP (OVH Manger -> Dedicated Server -> Services -> "Virtual Mac for VPS").

After you have created a container using a VETH network interface, you need to manually give it an IP address, etc. (Opposed to Proxmox doing this for you if you were to use VENET). On Debian-based distros (like Ubuntu), you can do this by editing the /etc/network/interfaces.tail file. Note the ".tail" ending! Then add something like this:

Code:
iface eth0 inet static
     address FA.IL.OV.ER
     netmask 255.255.255.255
     post-up route add XX.XX.XX.254 dev eth0
     post-up route add default gw XX.XX.XX.254
"FA.IL.OV.ER" should be obvious. "XX.XX.XX.254" is the gateway used by the server (host / CT0). See http://forum.ovh.co.uk/showthread.php?t=3469

A tip for both containers and KVMs is to disable the "Start at boot" option until you have tested it works OK with the network settings.

The reason for that is when you happen to use an incorrect MAC address (ie., you forgot to enter it, a typo, didn't add it on the OVH Manager, etc), then your server becomes locked out from OVH's network. With that option disabled, you can simply hard-reboot the server and you're back in to fix the MAC issue on the container. Otherwise you keep locking the server out as soon as the container starts up

So yes, Proxmox works fine with OVH's bridge mode networking. And the full LVM support in 1.4+ and updated drivers makes it a lot faster too!