Skip to main content

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.

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)

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 responded
Hi XXXXXXX

I 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
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.

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 ACCEPT

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.

admin@host:~sudo nano /etc/network/interfaces


iface lo inet loopback
#----------------------------------------
# The primary network interface (first IP address assigned by 1and1)
# MAC 44:8a:5b:XX:XX:XX
auto eth0
#IPv4 #1 111.111.110.110 (fake address for illustration only) assigned by DHCP
iface eth0 inet dhcp
iface 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:0
iface eth0:0 inet6 manual
iface 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
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.


Or from the shell command line do this:

admin@host:~sudo virsh net-list --all
Name State Autostart ----------------------------------------- default active yes
admin@host:~sudo virsh net-dumpxml default <network connections='2'> <name>default</name> <uuid>8e0747a9-21fe-4649-8e11-0328fd85749a</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr0' stp='on' delay='0'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254'/> </dhcp> </ip> </network>

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.


Or from the shell command line to check a VM is using the default network do this:

admin@host:~sudo virsh list --all
 Id    Name                           State
----------------------------------------------------
 2     vm1                            running
 3     vm2                            running

admin@host:~sudo virsh dumpxml vm1
<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>

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.

admin@vm1:~sudo nano /etc/network/interfaces


iface lo inet loopback
#----------------------------------------
# The primary network interface (default network IP address assigned by host)
# MAC 52:54:00:4f:89:15
auto 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:0
iface eth0:0 inet static
  address 111.111.111.112
  broadcast 111.111.111.112
  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:~sudo nano /etc/network/interfaces


iface lo inet loopback
#----------------------------------------
# The primary network interface (default network IP address assigned by host)
# MAC 52:54:00:4f:89:16
auto 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:0
iface eth0:0 inet static
  address 111.111.112.113
  broadcast 111.111.112.113
  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:~sudo nano /etc/network/interfaces


iface lo inet loopback
#----------------------------------------
# The primary network interface (first IP address assigned by 1and1)
# MAC 44:8a:5b:XX:XX:XX
auto eth0
#IPv4 #1 111.111.110.110 (fake address for illustration only) assigned by DHCP
iface eth0 inet dhcp
iface 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:0
iface eth0:0 inet6 manual
iface 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:~sudo sudo service network-manager restart

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.

admin@host:~sudo shutdown -r now

There is an alternative approach that can be used.  Make sure you do the down and up on the same command line otherwise you may lock yourself out form briinging it back up.

admin@host:~sudo ifconfig eth0 down && ifconfig eth0 up

Then run ifconfig to see what the host network configuration looks like.


admin@host:~sudo ifconfig

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)

Step 5Now 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.

#Enable IPv4 forwarding (permanently) by writing a value to file
admin@host:~# sudo sh -c "echo 1 /proc/sys/net/ipv4/ip forward"

#Setup the static IP routes (temporarily)
admin@host:~sudo route add -host 111.111.111.112 dev virbr0
admin@host:~sudo route add -host 111.111.112.113 dev virbr0

#Check the routes are there
admin@host:~sudo route
Kernel IP routing table
Destination      Gateway         Genmask         Flags Metric Ref    Use Iface
default          10.255.255.1    0.0.0.0         UG    0      0        0 eth0
10.255.255.1     *               255.255.255.255 UH    0      0        0 eth0
111.111.111.112  *               255.255.255.255 UH    0      0        0 virbr0
111.111.112.113  *               255.255.255.255 UH    0      0        0 virbr0
192.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 ACCEPT
sudo iptables -I FORWARD 1 -t filter -s 111.111.111.112/32 -i virbr0 -j ACCEPT
sudo iptables -I FORWARD 1 -t filter -d 111.111.112.113/32 -o virbr0 -j ACCEPT
sudo iptables -I FORWARD 1 -t filter -s 111.111.112.113/32 -i virbr0 -j ACCEPT
Step 6To 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 nano /etc/rc.local

#!/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 shutdown -r now

Then do some pinging and SSH to test.

References:
https://wiki.libvirt.org/page/VirtualNetworking#Isolated_mode_2
http://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

n4pstar said…
Hello Rod,

thank you so much for this HowTo, you saved my day/week :).

really great job u did!

Regards
Rod Dines said…
@n4pstar Gee thanks for the feedback it was nice to know this large effort in documenting was used by at least one other peer.

Popular posts from this blog

Install or Reinstall TeamViewer 11/12/13 Personal (Non-Commercial) License on Windows Server (2012/2012 R2/2016 etc) [Updated Dec 2017]

After running out of the TeamViewer commercial trial period I sought to find a solution to the problem of having to buy an expensive licence for my home server (which is only used for non-commercial personal use).[Update Dec 2017]: I can confirm that these procedures still apply and work with Teamviewer version 12 and 13 also (as tested on Windows Server 2016).
Procedure A: If TeamViewer is NOT Already Installed (Note: If it is already installed, then first follow procedure B. below)Download and Run the installer downloaded from http://www.teamviewer.com/. On the Welcome to TeamViewer page be sure to check the "Show advanced settings" check box (outlined in red at bottom left in picture), then click "Accept - next". Leave the "Advanced settings" installation window open (as shown above) and start Windows Explorer (i.e. the file manager, not Internet Explorer). Now go to your temp directory by typing "%tmp%" into the location bar and hitting enter.…

Migrating/cloning an Apple MAC OSX with Windows 7 / 8 / 10 Bootcamp partition to another hard or solid state (HDD / SSD) disk drive (Updated March 2018)

I got a Mac Book Pro 13" in 2012 that in 2016 I upgraded to a 240GB SSD from a similar sized 250GB HDD.  Since then I have followed this procedure a number of time for friends and customers. This week I again had to upgrade that same Mac Book Pro from the 240GB SSD to a new 480GB SSD and again came across a number of problems.  For this reason, I have decided to invest my time in documenting this troublesome process for the benefit of others and so next time I have to do it I won't have to remember and re-discover everything again.

TL;DR - The Crux of this article is that unfortunately, there is no easy way to just copy the whole old drive, with the different Mac and Windows Bootcamp partitions to a new drive. However, with this guide, the complex process is fully explained and broken up into five manageable and easy to understand processes along with their individual steps to do so.

NOTE: I use the word 'drive' loosely here but these processes could work to/or from eit…

Removing the WLAN / WiFi pcie card whitelist on Lenovo IdeaPad u410 Touch with BIOS update

WARNING! PLEASE READ THE ENTIRE POSTBEFORE USING / DOING ANYTHING!

BACKGROUND
I recently (early 2016) acquired a 2013 Lenovo IdeaPad u410 Touch.

It was not my first choice but still useful but I wanted to upgrade it to more recent tech and make it more usable as it is not the fastest CPU around, i.e. an i5-3337U dual core (quad thread) at 1.8GHz.
http://ark.intel.com/products/72055/Intel-Core-i5-3337U-Processor-3M-Cache-up-to-2_70-GHz


First thing I did was upgrade the BIOS to latest (as anyone would/should do really) version 65CN99WW (8/28/2014) available here:
http://support.lenovo.com/au/en/products/laptops-and-netbooks/ideapad-u-series-laptops/ideapad-u410?beta=false

I then added 2 x Kingston SO-DIMM KVR16LS11/8 1.35V (Low Voltage) 8G DDR3 1600 Notebook Ram SODIMM's despite the specs I could find all saying it would only take 8GB and it works fine with the 16GB as the Intel i5-3337U CPU (says 32GB) & Mobile Intel HM77 Express Chipset specifications suggest. 
https://www.lenovo.co…