A virtual machine has no network: looking in the right order

The machine boots, it runs, but there is no network. The first reflex is to go inside the machine and look at its network settings, and that usually costs time, because that is the last link in the chain.

First, see the shape of the chain

There is a bridge on the server, and that bridge behaves like a switch. The virtual machine's network card is plugged into that switch. The switch itself is attached to a physical port. The chain is: machine, bridge, physical port, outside world. If any of these links is broken, the inside of the machine looks perfectly healthy, the cable looks connected, and traffic goes nowhere.

First link: is the card on the right bridge

Look at which bridge the machine's network card is attached to. Machines built from a template, or moved from another server, keep carrying the old bridge name. If that name no longer exists on this server, the card is plugged into nothing.

Second link: does the bridge have a way out

If a bridge has no physical port in it, that bridge is a switch facing inward only: the machines on it see each other and nothing else. Sometimes this is on purpose, sometimes it is skipped during setup. The symptom "the machines can see each other but there is no internet" almost always points here.

Third link: the tagging question

If your network uses tagged traffic, what the upstream switch expects and what the machine sends have to match. Sending untagged where tagged is expected, or the reverse, produces no error at all. Everything looks right and no packet passes. Because it is silent, this is the link that eats the most time.

Fourth link: now the inside of the machine

By the time you get here there are three things to check, and the three point in different directions. If no address is obtained at all, the problem is further up. If there is an address but nothing goes out, look at the gateway. If everything works but names do not resolve, the issue is name resolution, not the network. Separating those three symptoms is half the diagnosis.

There is also the cloning trap: if a copied machine carries the same network identity as its source, the same address gets handed to two machines and the connection drops in turns.

The "it worked yesterday" case

The chain was the same yesterday, so look for what changed: a firewall inside the machine, a rule on the server side, or an expired record on whatever hands out addresses. On a setup that worked yesterday, the bridge layout rarely breaks by itself.

What Atlas does

On the network page Atlas shows the physical ports, the bridges, the addresses and the routes in the same place, so you follow the chain above by looking rather than by assembling it in your head. When you change the network configuration a rollback countdown starts: if you do not confirm, the old configuration comes back on its own, and that countdown runs on the server, not tied to your browser. So a change that cuts your connection does not leave you locked out.