Every VirtFusion server needs a working network path: a Linux bridge on the hypervisor that the VPS attaches to, and IP addresses that VirtFusion hands out from blocks you define. Getting this right before you sell the first VPS saves many "no network" tickets later.
Before you start
- A control server and at least one hypervisor added as in Add a KVM hypervisor to VirtFusion.
- The IPv4 subnet(s) and IPv6 prefix your datacentre routed to the hypervisor, with gateway, netmask and any MAC restrictions your provider applies.
- Out-of-band access (IPMI/KVM console), because bridge changes can drop SSH.
Understand the model
VirtFusion keeps networking in two layers:
- On the hypervisor: a bridge (commonly
br0) that joins the physical uplink and the virtual NICs of customer servers. - In the admin area: IP blocks (IPv4 ranges and IPv6 subnets) with their gateway and resolvers, which you attach to one or more hypervisors. When a server is created, VirtFusion picks free addresses from the attached blocks and passes them to the server through cloud-init.
Note: Exact menu labels vary between VirtFusion releases. The steps below describe the sections by purpose; use the official VirtFusion documentation for the wording in your version.
Create the bridge on the hypervisor
- Connect through the IPMI console, not SSH.
- Move the host IP from the physical interface to a bridge. On Debian/Ubuntu with netplan, the physical interface gets no address and the bridge carries it:
network: version: 2 ethernets: eno1: {} bridges: br0: interfaces: [eno1] addresses: [203.0.113.10/24] routes: - to: default via: 203.0.113.1 nameservers: addresses: [1.1.1.1, 8.8.8.8] parameters: stp: false forward-delay: 0 - Apply with
netplan tryso the change rolls back automatically if you lose access, then confirm withip addr show br0. - In the hypervisor's settings in VirtFusion, set the network bridge name to the one you created.
For netplan basics see Set a static IP with netplan.
Add an IPv4 block
- In the admin area, open the IP blocks section and create a new IPv4 block.
- Enter the network, gateway and netmask exactly as the datacentre assigned them. Keep the network address, gateway, broadcast address and the hypervisor's own IP out of the usable range.
- Set the resolvers customers will receive.
- Attach the block to the hypervisor (or hypervisor group) that has that subnet routed to it.
Warning: Never attach a block to a hypervisor the subnet is not routed to. The server boots with an address that has no path and the customer sees no network.
Add an IPv6 subnet
- Create an IPv6 block with the routed prefix (for example a /48 or /56) and its gateway.
- Choose the size given to each server; a /64 per VPS is the common, standards-friendly choice.
- Attach it to the same hypervisor. If the prefix is routed to the hypervisor's link address rather than on-link, check with your provider which gateway to use.
Inside the VPS the address is set by cloud-init; Linux VPS IPv6 setup helps when you need to check it by hand.
Check afterwards
- Create a test server and confirm it pings its gateway, an external IPv4 address and an IPv6 address such as
2606:4700:4700::1111. - Run
bridge linkon the hypervisor and check the server's tap interface is a member ofbr0. - Set reverse DNS for the test IP, as explained in Reverse DNS and email deliverability.
Troubleshooting
- Server gets an IP but no traffic: the provider may filter unknown MAC addresses. Ask for virtual MACs or a routed setup.
- Only IPv4 works: the IPv6 gateway is wrong or the prefix is not routed yet; test from the hypervisor with
ping -6. - No free IPs: the block is full or not attached to that hypervisor.
