Brilliant! Thanks Laine.
I really appreciate the help.
you could also avoid setting up the bridge
and just use macvtap bridge mode as you say you've done on your
own network. The only limitation of that is that it doesn't
permit direct communication between the host and the guests. If
that limitation is okay with you, then that's fine.
How does the performance of a bridge on the host (Ubuntu
bridge-utils) typically compare to a macvtap bridge? Is there an
expected performance advantage of one over the other? I was
hoping for better performance out of the macvtap bridge.
Time to buy some extra IPs it seems...
Most appreciated Laine.
On 2019-10-23 9:44 a.m., Laine Stump
10/23/19 12:43 AM, Paul O'Rorke wrote:
Can anyone advise me on the correct/best set up for Virtual
I have a guest in my server room wish to migrate to dedicated
server I rented in an offsite in a data centre. I rented a box
with one NIC and one public IP. I installed KVM on it and a
guest. (both Ubuntu 18.04 LTS server edition). I am struggling
to get the networking right.
Essentially I want the "Virtual Server Hosting" config mentioned
I have not had any luck setting that up. It is listed in the
"Routed" section but the graphic says the virtual switch should
be in bridged mode.
I also tried using macvtap, and since I have only one guest was
expecting to be able to just use the host IP
No, you will need one IP for the host, and one IP for the guest in
either bridged mode or for macvtap.
but it looks like the data centre have
restricted packets to the MAC address of the host NIC.
Yes, there is that restriction too. Usually hosting providers will
lock down the MAC addresses they allow through ports, in order to
prevent hostile clients from doing MAC spoofing to capture other
set up I can ping the public IP (it is
both eh host and the guest?)
No. An IP address refers to one entity. It can be the host or the
guest, but not both.
not their gateway. Should a macvtap not
be presenting the MAC address of the host NIC to the router and
thus allowing packets from the guest?
No, that is not what macvtap does. It creates a virtual NIC
(macvtap device) that is connected directly to the physical NIC,
and traffic from that device is injected directly into the output
queue of the physical device, MAC address and all.
I clearly have a lack of understanding of how this is working
and how it is meant to work. When I tried the same thing on mt
hardware/network I can create myltiple guests that all use the
macvtap interface and I have no problems getting connectivity to
the outside world.
Because on your own network you have no MAC address locking on
your switch port, and have multiple IP addresses available (one
for each guest) from the local DHCP server.
Before I approach the data centre about this I want to be sure I
understand what I am doing. I ultimately want to host a mail
server and several different web servers as guests all behind
this one host. I would alias their public IPs to the host NIC
and use IPtables to route traffic based on destination IP.
The only reason you would want iptables to be involved is if you
were limited to only 1 IP address for the host + all the guests.
In that case you could use *port* forwarding to cause incoming
traffic to the host on particular TCP ports to be forwarded to
Does that make sense? Can anyone suggest the right way to
No, not really :-)
If you can only get a single IP address, then you'll need to look
at the above link. If you can get the hosting provider to sell you
extra IP addresses / MAC addresses (usually extra IPs cost money
but MAC addresses are free, they just want to know what they are -
you will need one *of each* for each guest), then you should put a
bridge on your host's ethernet, and connect all the guests to that
bridge, configuring each with its unique IP address / MAC address
/ default route info given to you by the hosting provider. You can
use this as a reference to configure the host and guests:
(you could also avoid setting up the bridge and just use macvtap
bridge mode as you say you've done on your own network. The only
limitation of that is that it doesn't permit direct communication
between the host and the guests. If that limitation is okay with
you, then that's fine.)