IMHO the best way - How to configure a dedicated server running Linux (e.g. Ubuntu 14.04 LTS) with KVM virtualisation to work inside a 1and1 (1 and 1, one and one) hosting environment
When I first purchased a 1and1 medium dedicated server package I chose to image install Ubuntu Linux 14.04 LTS on it and setup KVM/QEMU virtualization with libvirt; little did I know I was going to run into a major road block.
The typical way for virtualization hypervisors to share the physical network card is through a network tap or macvtap and this allows the host server's virtualised clients to utilise their own virtualized NIC (network interface card) potentially through hardware support. However in the 1and1 environment due to security reasons the host is restricted to network traffic leaving the host only able to utilise just the one already known (to 1and1) layer 2 MAC address that is the physical MAC address of your dedicated servers NIC hardware.
After my investigation, I was ultimately left with three choices as far as I could determine.
1. The first option: While the dedicated server package itself is rather nice this security requirement effectively hobbles the server to some extent because it means the host operating system has to take on the function of a router (in software) and do some additional IP traffic forwarding and optionally NAT manipulation. So your first choice is to act quickly and ask 1and1 for a refund on your fees and terminate your contract based on undeclared functional restrictions and then go elsewhere. Ideally, 1and1 would create an administrative interface that allows you to add MAC addresses and associate them with additional IP addresses you have added to your package allowing the bridging options to work. But this is probably not ever going to happen or it will at some glacial pace; so it is not really a solution. Please send them feedback or an email if you want to inspire them to change. The other two choices that follow assume you are going to put up with their limitations and inflexibility for now.
2. The second option is to do as the 1and1 support email briefly suggests and setup NAT routing on the host server's one IPv4 address you are given with the package. This is not an ideal situation as you are going to have to compromise on sharing the limited available ports of the one public address across multiple servers. The aim here is to somehow configure the host server to map specific external ports on that public IP address to specific virtual server ports on the internal NAT virtualised (internally) bridged network. You can utilise this approach here to complete this task. Refer: http://serverfault.com/questions/170079/forwarding-ports-to-guests-in-libvirt-kvm
The commands are shown here (adjusted for the context of this example and just in case this link is lost later).
Here is an alternative approach I found but did not test http://secomputing.co.uk/2012/02/21/Forwarding-ports-to-KVM-clients/
In addition to utilising NAT alone you could add additional IPv4 addresses to the external network interface on the host (giving NAT access to more IP:Port pairs) using this approach:
Edit and save the changes below to /etc/network/interfaces.
Note: I haven't addressed how you set and use specific internal IP's for each VM as this is not an option I have pursued because of this and other issues. This approach all gets rather complex and difficult to administer and also has the issue of having the host also have to implement NAT translations on all the traffic to multiple IP addresses.
3. The third option which I have chosen to implement is the primary concern of this blog article is to utilise a separate IPv4 address for each virtual server (and assumes these are available to you) and utilise IPv4 routing to forward any IPv4 datagram for the virtual server without having to transform them with NAT (and vica versa in the outward direction). While not as efficient as hardware virtualized network bridging this approach has the benefit of reducing the load on the host server and thus increasing the performance because it does not require the host server to modify the IP frame content but just redirect it. Warning don't get fooled into thinking you can use the default routing option (as I did) in libvirt as this is not designed for use with isolated IPv4 host addresses but a larger vlsm block of addresses. I suppose you could use multiple single address networks with a different network to each VM but this just gets really messy not to mention the waste of memory and constant context switching on the host required to make it work.
To make it easier to follow here is a diagram of how this third configuration approach looks.
Please note this guide is coming from a Ubuntu 14.04 LTS (Trusty Tar) perspective and there may be some alterations required for other Linux distributions or Ubuntu versions but the principles and the approach should remain the same.
Step 1. In the GUI tool virt-manager-2 (which utilises libvirt) right click on the localhost (QEMU) entry and select the Details option on the bottom of the menu. Then in the dialog (shown below) choose the Virtual Networks option. Note: the Device name virbr0 as shown in the example below and that Forwarding is set to NAT and is enabled; also note the Network details (192.168.122.0/24). Write them down as we will need these later.
Name State Autostart ----------------------------------------- default active yes
The typical way for virtualization hypervisors to share the physical network card is through a network tap or macvtap and this allows the host server's virtualised clients to utilise their own virtualized NIC (network interface card) potentially through hardware support. However in the 1and1 environment due to security reasons the host is restricted to network traffic leaving the host only able to utilise just the one already known (to 1and1) layer 2 MAC address that is the physical MAC address of your dedicated servers NIC hardware.
If you configure the default bridging and startup a virtual client your server will attempt to send traffic out with a "spoofed" mac address (according to 1and1) and this will be discarded and the server automatically disconnected from the Internet (only accessible from the remote console service for alteration) and if you're "lucky" you will also likely get an email from a 1and1 administrator telling you so and if the traffic has stopped they may reconnect you (as they kindly did for me). Here is the email I initially got from 1and1 admin (while I was trying to troubleshoot my server from the remote console):
Dear XXXXXX XXXXX, (Customer ID: XXXXXXX)To which I responded
Thank you for contacting us. (I had to laugh as I really only contact them with a spoofed ping)
Your server has been disabled at the switch as a result of network traffic generated with false MAC address header information. This is most often due to a virtual machine running with an independent interface although this is not the only cause of MAC spoofing. To utilize the use of our network with a virtual environment, you must enable NAT on the virtual machine so that it uses the host interface.
If you have not installed any virtualization software, there could be another application or process causing the MAC spoof and may need to be investigated further on your part. The switch port lock is an automated process that will disconnect you again in the future as soon as a spoofed MAC address is encountered. This is a necessary security precaution that 1&1 has employed for the protection of our network and our other customers.
Currently, I have re-enabled your connection at the switch port however if the same behavior continues, your account may be locked pending a re-image of the server. Please contact our Dedicated Server Support Department at 0330 123 0275 if you'd like to speak with an agent directly regarding this matter.
You may receive a short survey within the next 24-48 hours. Please take a moment to complete it so that we may continue to improve our customer experience.
If you have any further questions please do not hesitate to contact us.
--
Sincerely,
XXXXXXXX
Dedicated Server Support
1&1 Internet Inc.
Facebook: https://www.facebook.com/1and1
Twitter: https://www.twitter.com/1and1help
To which I got a polite but almost completely unhelpful response which led me to perform many Google searches and all with no suitable results and hence this blog post being created after many days of investigation and trial and error.Hi XXXXXXXI have looked on your support site for a linux (ubuntu) guide for setting up multiple IP's on Linux and whether network bridging is allowed or supported for virtualisation and found nothing.
I am not sure how to do it so that it complies with your security / architecture requirements.
I basically want a separate IPv4 address for each internal virtual server.From what you say in this email it appears you are saying I must add all the IP's to the one physical MAC on eth0 on the host. Then NAT/Route each external IP address to each internal virtual address.Do you have any reference material or information as to how it should/could be done to meet the requirements of the 1and1 environment?Thanks, XXXXXXX
After my investigation, I was ultimately left with three choices as far as I could determine.
1. The first option: While the dedicated server package itself is rather nice this security requirement effectively hobbles the server to some extent because it means the host operating system has to take on the function of a router (in software) and do some additional IP traffic forwarding and optionally NAT manipulation. So your first choice is to act quickly and ask 1and1 for a refund on your fees and terminate your contract based on undeclared functional restrictions and then go elsewhere. Ideally, 1and1 would create an administrative interface that allows you to add MAC addresses and associate them with additional IP addresses you have added to your package allowing the bridging options to work. But this is probably not ever going to happen or it will at some glacial pace; so it is not really a solution. Please send them feedback or an email if you want to inspire them to change. The other two choices that follow assume you are going to put up with their limitations and inflexibility for now.
2. The second option is to do as the 1and1 support email briefly suggests and setup NAT routing on the host server's one IPv4 address you are given with the package. This is not an ideal situation as you are going to have to compromise on sharing the limited available ports of the one public address across multiple servers. The aim here is to somehow configure the host server to map specific external ports on that public IP address to specific virtual server ports on the internal NAT virtualised (internally) bridged network. You can utilise this approach here to complete this task. Refer: http://serverfault.com/questions/170079/forwarding-ports-to-guests-in-libvirt-kvm
The commands are shown here (adjusted for the context of this example and just in case this link is lost later).
sudo iptables -t nat -I PREROUTING -p tcp -d 111.111.110.110 --dport 80 -j DNAT --to-destination 192.168.122.2:80
sudo iptables -t nat -I PREROUTING -p tcp -d 111.111.110.110 --dport 22 -j DNAT --to-destination 192.168.122.2:22
sudo iptables -I FORWARD -m state -d 192.168.122.0/24 --state NEW,RELATED,ESTABLISHED -j ACCEPTHere is an alternative approach I found but did not test http://secomputing.co.uk/2012/02/21/Forwarding-ports-to-KVM-clients/
In addition to utilising NAT alone you could add additional IPv4 addresses to the external network interface on the host (giving NAT access to more IP:Port pairs) using this approach:
Edit and save the changes below to /etc/network/interfaces.
admin@host:~# sudoiface lo inet loopback#----------------------------------------# The primary network interface (first IP address assigned by 1and1)# MAC 44:8a:5b:XX:XX:XXauto eth0#IPv4 #1 111.111.110.110 (fake address for illustration only) assigned by DHCPiface eth0 inet dhcpiface eth0 inet6 static address 2001:08D8:091D:6C00:0000:0000:00XX:XXXX netmask 64 post-up ip -6 route add fe80::1 dev eth0 post-up ip -6 route add default via fe80::1 dev eth0 post-down ip -6 route del default via fe80::1 dev eth0#The virtual IP interfaces on same MAC (required by 1and1)#Note: 1and1 do not support bridging with unknown MAC address spoofing#----------------------------------------# Additional 1and1 IP address (assigned to host)
#IPv4 #2 111.111.110.111 (fake address for illustration only)
auto eth0:0iface eth0:0 inet6 manualiface eth0:0 inet static address 111.111.110.111 broadcast 111.111.110.111 netmask 255.255.255.255 #nameserver 8.8.8.8 #gateway 10.255.255.1#----------------------------------------
Once you have an additional IP address on the external interface you can also NAT those ports off to another VM for example:
sudo iptables -t nat -I PREROUTING -p tcp -d 111.111.110.111 --dport 80 -j DNAT --to-destination 192.168.122.3:80
sudo iptables -t nat -I PREROUTING -p tcp -d 111.111.110.111 --dport 22 -j DNAT --to-destination 192.168.122.3:22
3. The third option which I have chosen to implement is the primary concern of this blog article is to utilise a separate IPv4 address for each virtual server (and assumes these are available to you) and utilise IPv4 routing to forward any IPv4 datagram for the virtual server without having to transform them with NAT (and vica versa in the outward direction). While not as efficient as hardware virtualized network bridging this approach has the benefit of reducing the load on the host server and thus increasing the performance because it does not require the host server to modify the IP frame content but just redirect it. Warning don't get fooled into thinking you can use the default routing option (as I did) in libvirt as this is not designed for use with isolated IPv4 host addresses but a larger vlsm block of addresses. I suppose you could use multiple single address networks with a different network to each VM but this just gets really messy not to mention the waste of memory and constant context switching on the host required to make it work.
To make it easier to follow here is a diagram of how this third configuration approach looks.
Please note this guide is coming from a Ubuntu 14.04 LTS (Trusty Tar) perspective and there may be some alterations required for other Linux distributions or Ubuntu versions but the principles and the approach should remain the same.
Step 1. In the GUI tool virt-manager-2 (which utilises libvirt) right click on the localhost (QEMU) entry and select the Details option on the bottom of the menu. Then in the dialog (shown below) choose the Virtual Networks option. Note: the Device name virbr0 as shown in the example below and that Forwarding is set to NAT and is enabled; also note the Network details (192.168.122.0/24). Write them down as we will need these later.
Or from the shell command line do this:
admin@host:~# sudoadmin@host:~# sudo
Step 2. In the GUI tool virt-manager-2 (which utilises libvirt) or libvirt itself you need to create your virtual machine(s) (outside the scope of this discussion) shown here as vm1 with the default NAT network.
Step 3. On each of the client VM's, you need to edit the network configuration as follows to add the external IPv4 address that will be used. You first need to add these to your 1and1 or other dedicated server packages in the 1and1 server administration web control panel i.e. admin.1and1.co.uk):
Edit and save the changes below to /etc/network/interfaces.
Note: The use of the default automated DHCP network will help with the host environment managing the VM's and also allow the VM to automatically know about the default gateway which is 192.168.122.1 (in the example). Importantly this approach does not upset any assumptions about a default environment which makes it all easier to both setup and manage. It also allows for inter-VM traffic to stay within the host environment.
Edit and save the changes below to /etc/network/interfaces.
Step 4 (Optional). On the host system you may need to edit the network configuration (in a similar way to the previous step) as follows to add any additional external IPv4 address that will be used by the host (itself or for NAT in a hybrid approach as described in a similar way in the earlier second option) that will not be used exclusively on any specific VM. This is also shown in our conceptual diagram (above) as two host addresses on eth0 (physical) and eth0:0 (virtual as in network, not machine) interfaces.
Edit and save the changes below to /etc/network/interfaces.
There appear to be issues with the above command for some people on Ubuntu 14.04 LTS and this may be avoided by performing and waiting for a full reboot. I always do a reboot (especially during initial configuration) as you just know in the long run it saves you problems.
Step 5. Now that you have all the host and VM network interfaces configured we need to reconfigure the host system to forward IPv4 (i.e. behave like a router). This is first done by enabling the IPv4 forwarding and then configured with some static routes that let the host know how to get to the VM's external IPv4 addresses.
http://www.itzgeek.com/how-tos/mini-howtos/change-default-network-name-ens33-to-old-eth0-on-ubuntu-16-04.html
Rod
Or from the shell command line to check a VM is using the default network do this:
admin@host:~# sudo
Id Name State
----------------------------------------------------
2 vm1 running
3 vm2 running
admin@host:~# sudo
<domain type='kvm' id='2'>
<name>vm1</name>
<uuid>093536e5-e5db-4a40-83c2-befa39cfa185</uuid>
...
<devices>
...
<interface type='network'>
<mac address='52:54:00:4f:89:15'/>
<source network='default'/>
<target dev='vnet0'/>
<model type='rtl8139'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</interface>
...
</devices>
...
</domain>
Edit and save the changes below to /etc/network/interfaces.
admin@vm1:~# sudoiface lo inet loopback#----------------------------------------# The primary network interface (default network IP address assigned by host)# MAC 52:54:00:4f:89:15auto eth0#The default IPv4 address is assigned by DHCP from host range in above config (step 1)iface eth0 inet dhcp#Note: adding this prevents the server boot being delayed searching for an IPv6 address
iface eth0 inet6 manual
#----------------------------------------
# The additional 1and1 IPv4 address (assigned to host)
#IPv4 #2 111.111.111.112 (fake address for illustration only)
auto eth0:0iface eth0:0 inet static address 111.111.111.112 broadcast netmask 255.255.255.255#Note: adding this prevents the server boot being delayed searching for an IPv6 address
iface eth0:0 inet6 manual
#----------------------------------------Note: The use of the default automated DHCP network will help with the host environment managing the VM's and also allow the VM to automatically know about the default gateway which is 192.168.122.1 (in the example). Importantly this approach does not upset any assumptions about a default environment which makes it all easier to both setup and manage. It also allows for inter-VM traffic to stay within the host environment.
Edit and save the changes below to /etc/network/interfaces.
admin@vm2:~# sudoiface lo inet loopback#----------------------------------------# The primary network interface (default network IP address assigned by host)# MAC 52:54:00:4f:89:16auto eth0#The default IPv4 address is assigned by DHCP from host range in above config (step 1)iface eth0 inet dhcp#Note: adding this prevents the server boot being delayed searching for an IPv6 address
iface eth0 inet6 manual
#----------------------------------------
# The additional 1and1 IPv4 address (assigned to host)
#IPv4 #2 111.111.112.113 (fake address for illustration only)
auto eth0:0iface eth0:0 inet static address 111.111.112.113 broadcast netmask 255.255.255.255#Note: adding this prevents the server boot being delayed searching for an IPv6 address
iface eth0:0 inet6 manual
#----------------------------------------Step 4 (Optional). On the host system you may need to edit the network configuration (in a similar way to the previous step) as follows to add any additional external IPv4 address that will be used by the host (itself or for NAT in a hybrid approach as described in a similar way in the earlier second option) that will not be used exclusively on any specific VM. This is also shown in our conceptual diagram (above) as two host addresses on eth0 (physical) and eth0:0 (virtual as in network, not machine) interfaces.
Edit and save the changes below to /etc/network/interfaces.
admin@host:~# sudoiface lo inet loopback#----------------------------------------# The primary network interface (first IP address assigned by 1and1)# MAC 44:8a:5b:XX:XX:XXauto eth0#IPv4 #1 111.111.110.110 (fake address for illustration only) assigned by DHCPiface eth0 inet dhcpiface eth0 inet6 static address 2001:08D8:091D:6C00:0000:0000:00XX:XXXX netmask 64 post-up ip -6 route add fe80::1 dev eth0 post-up ip -6 route add default via fe80::1 dev eth0 post-down ip -6 route del default via fe80::1 dev eth0#The virtual IP interfaces on same MAC (required by 1and1)#Note: 1and1 do not support bridging with unknown MAC address spoofing#----------------------------------------# Additional 1and1 IP address (assigned to host)
#IPv4 #2 111.111.110.111 (fake address for illustration only) assigned static
auto eth0:0iface eth0:0 inet6 manualiface eth0:0 inet static address 111.111.110.111 broadcast 111.111.110.111 netmask 255.255.255.255 #nameserver 8.8.8.8 #gateway 10.255.255.1#----------------------------------------
At this point, you will have to either restart the host or restart the networking services before moving on.
admin@host:~# sudoThere appear to be issues with the above command for some people on Ubuntu 14.04 LTS and this may be avoided by performing and waiting for a full reboot. I always do a reboot (especially during initial configuration) as you just know in the long run it saves you problems.
admin@host:~# sudo
admin@host:~# sudo
Then run ifconfig to see what the host network configuration looks like.
admin@host:~# sudo
eth0 Link encap:Ethernet HWaddr 44:8a:5b:XX:XX:XX
inet addr:111.111.110.110 Bcast:111.111.110.110 Mask:255.255.255.255
inet6 addr: 2001:8d8:91d:XX00::XX:XX59/64 Scope:Global
inet6 addr: fe80::468a:XXff:XXXX:XX64/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:486848 errors:0 dropped:0 overruns:0 frame:0
TX packets:484024 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:257678231 (257.6 MB) TX bytes:283858615 (283.8 MB)
Memory:f4200000-f4300000
eth0:0 Link encap:Ethernet HWaddr 44:8a:5b:XX:XX:XX
inet addr:111.111.110.111 Bcast:111.111.110.111 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:f4200000-f4300000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:704861 errors:0 dropped:0 overruns:0 frame:0
TX packets:704861 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1997403589 (1.9 GB) TX bytes:1997403589 (1.9 GB)
virbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:23592 errors:0 dropped:0 overruns:0 frame:0
TX packets:22688 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:26969783 (26.9 MB) TX bytes:16754232 (16.7 MB)
#Enable IPv4 forwarding (permanently) by writing a value to file
admin@host:~# sudosh -c "echo 1 /proc/sys/net/ipv4/ip forward"
#Setup the static IP routes (temporarily)admin@host:~# sudoadmin@host:~# sudo
#Check the routes are thereadmin@host:~# sudo routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Ifacedefault 10.255.255.1 0.0.0.0 UG 0 0 0 eth010.255.255.1 * 255.255.255.255 UH 0 0 0 eth0111.111.111.112 * 255.255.255.255 UH 0 0 0 virbr0111.111.112.113 * 255.255.255.255 UH 0 0 0 virbr0192.168.122.0 * 255.255.255.0 U 0 0 0 virbr0
You're now probably itching to test it with a ping from somewhere else on the internet. If you do you should get a message back from the host's primary outside IPv4 address something like this:
Pinging 111.111.111.112 with 32 bytes of data:
Reply from 111.111.110.110: Destination port unreachable.
So you noticed it doesn't quite work yet (you'd get something similar from the inside going out also); this is because the libvirt daemon has setup a default NAT configuration in iptables and this also needs adjusting with the insertion (at the top of the list of rules) of some iptable commands to allow the forwarding to override the standard NAT process.
sudo iptables -I FORWARD 1 -t filter -d 111.111.111.112/32 -o virbr0 -j ACCEPTsudo iptables -I FORWARD 1 -t filter -s 111.111.111.112/32 -i virbr0 -j ACCEPTsudo iptables -I FORWARD 1 -t filter -d 111.111.112.113/32 -o virbr0 -j ACCEPTsudo iptables -I FORWARD 1 -t filter -s 111.111.112.113/32 -i virbr0 -j ACCEPT
Step 6. To allow these additions to the standard libvirt configuration to survive reboots then you have to somehow have them apply after the libvirtd daemon has done its stuff. Libvirt has a built in hooking mechanism that would ideally allow this to work but I (2014-ORIGINALLY) had problems getting it to work (2017-AND NOW HAVE IT WORKING) and gave up for this simpler approach (as identified in the NAT option earlier) that basically just relies on testing for the presence of the libvirtd process and then waiting 10 seconds for it to finish its configuration before applying the changes. As they are not really time sensitive beyond being applied after libvirtd has finished its setup this approach worked fine for me.
Edit and save the changes below to /etc/rc.local.
admin@host:~# sudo
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
#----------------------------------------------------------------------------
#Script to enable external IP address forwarding to hosted virtual machines.
#Refer to: http://serverfault.com/questions/170079/forwarding-ports-to-guests-i$
#Added by Rod Dines 18 Sept 2014 - blogger.com@roddines.com
(
# Make sure the libvirt has started and has initialized its network.
while [ `ps -e | grep -c libvirtd` -lt 1 ]; do
sleep 1
done
# 1. Wait for libvirtd to do all the stuff it needs to do setting up networking
sleep 10
# 2. Now set up custom iptables rules.
# a) These are for NAT forwarding configuration only
#iptables -t nat -I PREROUTING -p tcp -d 111.111.110.110 --dport 80 -j DNAT --to-destination 192.168.122.2:80
#iptables -t nat -I PREROUTING -p tcp -d 111.111.110.110 --dport 22 -j DNAT --to-destination 192.168.122.2:22
#iptables -t nat -I PREROUTING -p tcp -d 111.111.110.111 --dport 80 -j DNAT --to-destination 192.168.122.3:80
#iptables -t nat -I PREROUTING -p tcp -d 111.111.110.111 --dport 22 -j DNAT --to-destination 192.168.122.3:22
#iptables -I FORWARD -m state -d 192.168.122.0/24 --state NEW,RELATED,ESTABLISHED -j ACCEPT
# b) These allow 1and1 external IP address forwarding to VM's with external address
iptables -I FORWARD 1 -t filter -d 111.111.111.112/32 -o virbr0 -j ACCEPT
iptables -I FORWARD 1 -t filter -s 111.111.111.112/32 -i virbr0 -j ACCEPT
iptables -I FORWARD 1 -t filter -d 111.111.112.113/32 -o virbr0 -j ACCEPT
iptables -I FORWARD 1 -t filter -s 111.111.112.113/32 -i virbr0 -j ACCEPT
# 3. Now add any custom static routes to the ip routing table
# to enable external IP address forwarding
route add -host 111.111.111.112 dev virbr0
route add -host 111.111.112.113 dev virbr0
) &
# Note: That last & is important to have this task continue in the background.
#----------------------------------------------------------------------------
Step 7. At this point, you will have to restart the host to test it all works.
admin@host:~# sudo
Then do some pinging and SSH to test.
References:
https://wiki.libvirt.org/page/VirtualNetworking#Isolated_mode_2http://www.itzgeek.com/how-tos/mini-howtos/change-default-network-name-ens33-to-old-eth0-on-ubuntu-16-04.html
That's it and happy virtualizations. Please let me know if there are any errors you have discovered or if something is not clear. I hope this helps someone on their way.
Rod
Comments
thank you so much for this HowTo, you saved my day/week :).
really great job u did!
Regards
I worked hard about a week to get it done, but failed !
At last I found your blog. And read it completely. I'm trying to get things done as you showed your effort.
There is no dedicated package available like 1&1 and their price. I searched a lot and compare several companies for dedicated server. Only 1&1 I got great on dedicated resources. They are providing latest hardware and NVMe SSD with Gbit port speed. So, the best dedicated resources for cheap I found is 1&1.
But I was lost my hope to host 2/3 VM in a dedi server, as for the 1&1 MAC binding policy.
I thought this was impossible, but now I get hope from your post.
Great thanks,
-Bilal
But 1and1 has their own tutorial post to get this done.
Here is the two post 1and1 IONOS has published.
https://www.ionos.com/help/server-cloud-infrastructure/linux-dedicated-server/administration/change-or-add-ipv4-address-to-linux-dedicated-server/
https://www.ionos.com/help/server-cloud-infrastructure/linux-dedicated-server/administration/install-virtual-machines-on-linux-dedicated-server/
Many thanks for the update on IONOS(1and1). Possibly you are having problems due to the age of the article. It is a very confusing subject area.
I may update this if I use them again.
Thanks, Rod.