Using an OVH dedicated server to host VMs with public IPs is not hard if you know how, otherwise it can be a hellish nightmare!
Here's my little story with OVH's poorly maintained guide...
I recently learnt the hard way that
iproute2 was replacing a lot
of deprecated tools...
So you have a bunch of things that you can't rely on anymore, depending
on which Linux distribution you're using.
ifconfig. Interface names have become better, predictable,
and deprecated good old
eth0; so now you have
ens1 and that made
me kinda angry at first because I didn't know what "predictable" meant there,
since for me
eth0 for the first interface found was more "predictable" than
some randomy name starting with an
e followed by surprise letters and numbers!
Then I read about those predictable names and understood they actually made
And I understood why I was out of the loop! It was created in 2009 and
my networking knowledge hadn't had much update between 2009 and 2019!
/etc/network/interfaces on Ubuntu is deprecated, you have to look at
ifconfig doesn't work on Arch Linux (I think you can still install it, but
why install a deprecated tool?)
Then you have a lot of documentation that is more or less up to date.
And you have that awful name for this new
ip!!! Yes it's
convenient to have a short name for a tool, yes this name totally makes sense.
ip is the WORST command name if you're looking for information on
Google! Okay, it might not be the worst...
X isn't (wouldn't be) any better!
So instead of searching
ip, you have to add
iproute2, hoping that
the people who write about that command will mention
iproute2 (like I'm doing
I prefer Ubuntu because it's simpler, so many things are done for you! But then, you might argue that Ubuntu is heavy... And it certainly has become extra heavy! So heavy that for some obscure reasons, when I use Ubuntu for hosting virtual machines (VMs), it just doesn't work for me! I'm mainly a macOS user on a daily basis. But I do use Linux, from a little to a lot, but generally without a graphical user interface (GUI). But to manage VMs (creations, deletions, modifications, etc.), I don't wanna do it without a GUI because it's complicated, error-prone, and it's very useless unless you're mass-producing VMs, in which case it's mandatory to drop the GUI (or just use it to make your genesis template and then forget about it).
So, I used
ssh -CY to connect to the host and then I use
But when the host is Ubuntu, it's unusable under macOS. It's kinda usable
when the client is a Linux as well, so I booted a Live Ubuntu using a USB key
on a MacBook to have a Linux. But that's very inconvenient!
And at some point I tried Arch Linux for the host and surprisingly now I can
use macOS to
ssh -CY to the Arch Linux and launch
and it's quite usable!
I don't know why, I don't wanna investigate why, but I'm kinda happy I found
that solution. I'm guessing of course that it's all because Arch Linux is
lighter. But I really don't know why. Just like I don't know why Arch Linux's
pacman will install packages much much much faster than Ubuntu's
That's not my problem! I can't make every little problem my own, there are
too many! haha
For some reason, I couldn't get the network work without a NAT. Everytime I used a bridge, either it would make the VM lose its connection or worse, the host to become unreachable!
Long story short, now... here's the deal:
Just create your VMs. Use NAT. When the VMs are ready,
add a bridge interface (hotplug should be fine, I never had to reboot the VMs).
Select the host interface that has the internet. If your host uses
Arch Linux, it's likely to be
eno1, in which case select
Host device eno1: macvtap.
Enter the MAC address that OVH generated for your failover IP. If you don't
have one... I actually don't know if it's necessary! About 10 years ago, it
wasn't. But if it is and you don't have it, go to your OVH "manager" and
get one! Actually I expected OVH to provide DHCP for the VM using the bridge;
but it has never DHCPed for me so when I have time I'll try without setting
the MAC address on the OVH manager side. Anyway, here's a screenshot, it might
As soon as you create the interface, it should become available on your VM. (It'll also appear on the host but that doesn't matter.)
If you used the NAT, the good thing is that there's already a working connection on your VM so you can do it via SSH. But if you make sure you still have a VNC access to your VM, it'll help in case you mess up and your VM becomes unreachable!
So... I used OVH's documentation but either because I'm bad at following the steps and/or because it's just outdated, it never worked for me.
Once the new network interface is added, I create a 3-line script that I'll use everytime I need to connect the failover IP to my VM.
Run this script as user
root if your new network interface is
otherwise replace it by the proper name!
ip address add $FAILOVER_IP broadcast $FAILOVER_IP dev ens3 ip route add $HOST_GATEWAY_IP dev ens3 ip route add default via $HOST_GATEWAY_IP
$FAILOVER_IP has to be replaced by your failover IP;
$HOST_GATEWAY_IP is basically your host's IP where you replace the
last part with
Run this script as a sudoer if your new network interface is
otherwise replace it by the proper name!
sudo ifconfig ens9 $FAILOVER_IP netmask 255.255.255.255 broadcast $FAILOVER_IP sudo route add $HOST_GATEWAY_IP dev ens9 sudo route add default gw $HOST_GATEWAY_IP
And then see if your
$FAILOVER_IP is pingable!
it's easier to get to the clean way of doing it!
That "shortcut" solution that I give you here is not a very good way of doing things! Everytime you boot your VM, you have to reconfigure your interface...
But hopefully this will be useful to some people...