[kwlug-disc] Multiple NICs on Ubuntu Server 14.04

unsolicited unsolicited at swiz.ca
Fri Aug 15 14:54:29 EDT 2014


vm solutions create software virtual layer 2 switches as a software link 
for vm networking, and as the hardware interface from the whole.

My guess is your 2nd nic is not being picked up, or you would see an 
eth1 (unless you have 'ifconfig eth1 down'ed it sort of thing.)

You do not want two hardware interfaces on the same subnet unless you 
are bonding them into a single link, which requires hardware on the 
other end of the cable that understands such bonding. Which is highly 
unlikely that you have, or have set up. Such is not typically found in 
residential equipment.

Elsewise, your network will get confused. Two paths to the same 
destination. Packets going out one nic but coming back the other will 
get rejected, and vice versa. Essentially your network will go 
schizophrenic.

That is not to say a fair portion will continue to work, likely in a 
round robin, not load balanced, fashion, but you will find strange and 
bizarre things happen regularly. Like unsuccessful or dropped connections.

So the first question is: What is it you are trying to do? What do you 
mean by tame?

I do see http://www.linux-kvm.org/page/Networking

Some of the best advice I've seen, and follow, is until you have 
everything up and happy, don't have a 2nd nic present. It just 
complicates your life getting to where you're trying to go. You don't 
need networking issues getting their fingers in any issues, or appearing 
to, as you sort through things.

Internally, a 2nd nic is not going to buy you anything significant - 
your internal gigabit network will likely sufficient satisfy your speed 
requirements within the house, and out through your slower provider 
link, if that's your interest.

That's the physical. Security, if you're offering access to vm's from 
the outside world is a different thing. Be it a standalone LAMP server, 
or virtual variations thereof.

(And you're likely better off for the moment making sure it all works 
happily on a single nic, before introducing a second.)

{It's going to get even messier if you have a mix of vm's, some for 
external consumption, and some for internal consumption. All doable, but 
lots of little pieces to grok in between. e.g. Accept ssh/vnc/rdp for 
maintenance from a foreign, but internal, network address, but ignore 
for the other real world - when to the vm it's all foreign.}

In the end, some combination of the following, and it is not a complete 
or exhaustive list, will be involved:

- this internal kvm switch handing out dhcp to your vm's, on a SEPARATE 
subnet from your internal network.

- changing your router so that designated incoming ports or network 
requests are directed to this 2nd STATICALLY assigned second nic.

- ensuring that the virtual switch is SOLELY associated with this 2nd 
nic, and no inter-nic inter-networking bridging or cross-pollination 
occurs. You are likely ok as it stands as bridging between nics only 
happens when you deliberately set it up, not by itself. (But see schizo, 
above.)

- you will want to review your iptables or perhaps even load a gui / 
firewall package, so that what you want and expect is what you're 
getting. And make sure that any changes load at system startup 
(something I still haven't mastered, myself).

Which is all only to say, a number of disparate pieces enter the flow, 
each with their own learning curve. Easier to get things as you want 
then add this complexity as a standalone separate topic, rather than all 
complexities all at once.

My bet is that you will find any performance gain (vs security 
assurance) is not worth the additional complexity and maintenance oversight.

But, the first question to answer is: What is it you are looking to 
accomplish? Draw a diagram, and forget whether they're vm's or not. 
Whether you are configuring a virtual or a physical switch, it's all 
just an application interface, to you. It's just easier to get your head 
straight on what you want to do if you ignore whether they're physical 
or virtual, for the moment.



On 14-08-15 11:30 AM, Khalid Baheyeldin wrote:
> On Fri, Aug 15, 2014 at 10:40 AM, CrankyOldBugger
> <crankyoldbugger at gmail.com <mailto:crankyoldbugger at gmail.com>> wrote:
>
>
>     virbr0    Link encap:Ethernet  HWaddr ca:e3:65:49:dc:e4
>                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:0 errors:0 dropped:0 overruns:0 frame:0
>                TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>                collisions:0 txqueuelen:0
>                RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
>
>     Don't ask me why virbr0 is there.  (Google tells me it's there
>     because I started tinkering with KVM at some point but I never
>     finished the task.)
>
>
> Yes, I have that too, and yes, it is caused by libvirt/kvm. And it is
> not from configuration in /etc/network/interfaces.
>
>     I want to start building virtual machines on this box, but before I
>     do I would like to see the server using both NIC cards appropriately.
>
>
> You can make both cards work by putting something like this in your
> /etc/network/interfaces
>
>
> auto eth0
> iface eth0 inet dhcp
>
> auto eth1
> iface eth1 inet dhcp
>
> The above will make both interfaces come up at boot, and configure
> themselves via DHCP, so the router assigns them an IP address, ...etc
>
> Or you can assign that manually using something like:
>
> auto eth0
> iface eth0 inet static
>          address 192.168.0.2
>          netmask 255.255.255.0
>          network 192.168.0.0
>          broadcast 192.168.0.255
>          gateway 192.168.0.1
>
> auto eth1
> iface eth1 inet static
>          address 192.168.0.3
>          netmask 255.255.255.0
>          network 192.168.0.0
>          broadcast 192.168.0.255
>          gateway 192.168.0.1
>
> This means the first NIC will get 192.168.0.2 and the second will be .3,
> assuming that the router is at .1.
>
>     By that I mean it will share the load between any future VMs between
>     the two NICs,
>
>
> I am not sure what share the load means, or if there is a real answer to
> it as asked. So I will leave that to others who know more than me.
>
>     or at least reserve one NIC for the host server and one NIC for the VMs.
>
>
> This can be done in /etc/network/interfaces as well. Assuming you want
> the VMs to use only the 2nd network card, then you add:
>
> auto br0
> iface br0 inet dhcp
>          bridge_ports eth1
>
> And when creating a VM, via libvirt, you say:
>
> sudo virt-install --name vm_name ... --network bridge=br0 ...
>
> This tells libvirt to use the bridge br0, which uses eth1, which you
> have configured separately.
>
> I have not tried this specifically, but it "should work" (yeah, famous
> words!)
>
>     (I'm ashamed to say this is much easier in MS Hyper-V, but I would
>     much rather learn how to do this in Linux CLI!)
>
>
> Tsk tsk tsk ... traitors and infiltrators in our midst ... ;-)
>
>     So I guess my question is two-fold:
>
>     a) how do I tame my NICs in preparation for setting up VMs, and
>
>
> See above.
>
>       b) what's the preferred method for setting up VMs in Ubuntu
>     Server?  Does anyone know of a good how-to link?
>
>
> If you have kvm capable server, then use libvirt. You create VMs using
> virt-install on the command line, and use virt-viewer to see the BIOS
> and console output, and manage them using virsh.
>
> Or wait till November, when I will cover all this in a presentation for
> KWLUG.
> --
> Khalid M. Baheyeldin
> 2bits.com <http://2bits.com>, Inc.
> Fast Reliable Drupal
> Drupal optimization, development, customization and consulting.
> Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
> Simplicity is the ultimate sophistication. --   Leonardo da Vinci
> For every complex problem, there is an answer that is clear, simple, and
> wrong." -- H.L. Mencken
>
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>





More information about the kwlug-disc mailing list