Repository navigation
[not really a bug] Installing on Proxmox/OVH [Soyoustart] #2441
Description
Steps To Reproduce
Installing the virtual machine with a failover IP on OVH/Soyoustart server does not work.
The VM start, but cannot resolve anything (no DHCP of course), neither the static IP configuration works (read below why and how to fix)
Expected Result
Be able to manually edit the .yaml (or choose some kind of checkbox to enforce this behayviour)
Actual Result
Impossible to activate NIC=> cannot configure the VM => abort
Screenshots, Videos, or Pastebins
No response
Additional Context
The problem lies in the peculiarity of the .yaml file to use a "strange" IP router, mandatory for OVH/Soyoustart
A "standard" OVH server have 1 "real" IP, and N "other" IPs (the failover).
The normal gateway is the IP.254
In this example the "first" IP is 176.178.179.180 => the gateway become 176.178.179.254
With a failover IP 37.1.2.3, on 00:51:52:53:54:55 (this is a ESXi legacy, whatever it is on proxmox)
The "routes" section is the key: it's mandatory (AFAIK)
Something like that (on ens19)
network:
version: 2
ethernets:
ens19: #object name
dhcp4: false # dhcp v4 disable
dhcp6: false # dhcp v6 disable
addresses: [37.1.2.3/32]
match:
macaddress: 00:51:52:53:54:55
nameservers:
addresses: [8.8.8.8,208.67.222.222]
routes:
- to: 0.0.0.0/0
via: 176.178.179.254
on-link: true
My usual "quick-and-dirrrrrty" trick is
- control-C to enter "standard" shell
- changing the netplan .yaml by hand
- netplan apply
- launch another shell (alt f2)
- run the "normal" installation process
Of course, nothing impossible for a fairly experienced user, but I think it represents a blocking problem for those less accustomed
Kind regards
Build Version
25.0.2
Environment
By downloading the VM
Environment Details
- Proxmox 7.3.4
- Running on OVH/Soyoustart barematel
- 1 "real" IP + N failover, running on failover IP
Activity
enoch85 commentedon Feb 8, 2023
Very special case and the first one I've seen with this issue over the past years.
So you expect us to implement a fix?
fcorbelli commentedon Feb 8, 2023
In fact, no :) personally not a problem (for me)
I would think more of a "do you wanto to manually edit the .yaml file?" then running nano (very FreeBSD style) on it.
Because at the next reboot the installer "rebuild" the configuration file, and then - again - everything freezes, cannot access from web or ssh
Maybe an addendum in the documentation?
Just my 1 cent
codedbreeze commentedon Apr 8, 2025
@fcorbelli thank you for putting this out here. I've been trying to get my instance to connect using a failover IP, for a couple hours now, until a search led me here. With your instruction above, it worked at once.
crowetic commentedon Jul 18, 2025
I run all of my instances on OVH bare metal hypervisors with failover IPs. What I do, that makes this a LOT easier, is simply run a VM as a firewall instance, and make that instance provide DHCP to the rest of the VMs. That way, you only need to configure OVH's annoying (and now even modified from original annoying, to a new type of annoying) network configuration ONCE, on the firewall VM, then from there the firewall VM handles all of the failover IPs.
You can set the firewall VM's mac address as the failover IP's virtual MAC, and let it handle all of the IPs, then you have full router control over all of them, with no VM requiring special network configuration.
I do this with a proxmox hypervisor, and an ipfire VM running as my firewall VM, this also allows you to have another layer of protection, intrusion detection, etc.
I then configure the IPfire VM with 'aliases' for the entire public IP block from OVH, and then I can route traffic to and from any IP I choose via SNAT and DNAT rules, all while not having the requirement of modifying the networking on any individual VM.
Makes my life a whole lot easier. Just a suggestion.
fcorbelli commentedon Jul 18, 2025
There can be a thousand different ways to solve the problem.
The point, in my opinion, that should be emphasized is that a large portion of users who use a packaged "something"—for example, a Nextcloud VM—might not be particularly knowledgeable in the field of IT.
That’s why I suggested studying some sort of mechanism, preferably automatic, or manual if necessary, to help less experienced users.
I wrote an entire operating system for Alpha AXP, using vi, roughly around the time Torvalds started writing Linux (we’re almost the same age), so I don’t exactly have networking issues myself.
But that’s not the case for everyone, and this is a blocking—and frankly, "disheartening"—problem.