The next issue you'll see is that with OVH the gateway is inside a different subnet. Our rationale was that usually if you start handing out IP addresses to containers you have more than one address, and that usually means you have a block, which means it won't be a /32 subnet, which means you in theory also have a broadcast address, so using /32 didn't make sense to us.
However, OVH's intention on dedicated servers seems to be to not use a broadcast address (since it's a single host, unless you use the vRack which is a different story). And in addition to that their gateways are usually outside your subnet. This is an issue because most network configuration tools cannot deal with this and require manual intervention, which is why their documentation tells you to create `post-up` and `pre-down` entries in the /etc/network/interfaces file. (And we're not sure it's our job to deal with this routing situation - personally I find that's the network management layer's job, ie ifup/ifdown, systemd-networkd or whatever it is you're using - ie. if the gateway isn't reachable it makes sense to add a route to it on the interface the gateway line is specified on... but this problem keeps popping up...)
We'll soon add an OVH entry to our wiki explaining the necessary steps in detail.
In short: use 'static' addresses and leave all the fields blank, that way PVE will not touch the container's /etc/network/interfaces file and you can configure it manually.