<div dir="ltr">I guess my insistence on using multiple NICs comes from my (previous!) background with MS Hyper-V, where you would reserve one NIC for taking to the host machine, then any remaining NICS get shared amongst the VMs. Hard mindset to get out of. I shouldn't have attended so many MS training seminars, I think.<div>
<br></div><div>Well so far I've set up my router to show two reservations for the two NICs. I am working on the host machine remotely from work so I have all of my firewall port forwards set up (it's hard to go out on port 22 at work, so I use an uncommon port number from work to home router, then the home router flips me over to port 22 on the host machine).</div>
<div><br></div><div>I'm actually working on a Win7 box at work, so I am using an RDP manager that can handle SSH connections rather well (mRemoteNG if you're interested).</div><div><br></div><div>I've got the br0 set up in /etc/network/interfaces, along with both eth0&1 (for some reason I didn't have eth1 set up in my original email. not sure why not, but fixed now).</div>
<div><br></div><div>I've installed qemu-kvm, libvirt-bin, virtinst, and bridge-utils. I've set up vhost_net as well.</div><div><br></div><div>So now I'm just Googling away to see what else needs to be done before I start making VMs.</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 15 August 2014 15:42, Chris Irwin <span dir="ltr"><<a href="mailto:chris@chrisirwin.ca" target="_blank">chris@chrisirwin.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 15, 2014 at 2:54 PM, unsolicited <span dir="ltr"><<a href="mailto:unsolicited@swiz.ca" target="_blank">unsolicited@swiz.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">vm solutions create software virtual layer 2 switches as a software link for vm networking, and as the hardware interface from the whole.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br></blockquote>
<div><br><div>Only certain bonding modes require special equipment. I've used
bonding at home in the past (though don't bother anymore), and we've used it extensively at work for
years without any special considerations (but don't bother anymore since we've moved to a VM model over the last year).<br><br></div>See the mode section of the RHEL bonding docs for a description of the bonding modes.<br>
<br><a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sec-Using_Channel_Bonding.html" target="_blank">https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sec-Using_Channel_Bonding.html</a><br>
<br></div><div>We've actually found that it works better with dumber equipment. The only place we had issues with bonding was with some highly configurable layer-3-capable routing switches which were confused due to their ability to see multiple MAC addresses claiming the same IP. All hosts on the network didn't notice, and regular layer-2 switches were blissfully ignorant.<br>
<br></div><div><br>That said, I agree with the rest of your message. For home use, trying to bond multiple NICs together is a bit overkill for home use, and why I don't bother anymore.<br><br>I do still have three NICs in my VM server:<br>
<br>- The first is configured with an IP address and has all host traffic (including the NFS backing storage) run through this interface.<br><br></div><div>- The second NIC is an 'UP', but an unconfigured member of a bridge (brvm), which is also 'UP' but unconfigured. My virtual machines all connect to the brvm bridge for direct network access.<br>
</div><div><br></div><div>- My third NIC is configured similarly to the second, but is considered public (connected to my modem) and is connected only to my router VM :)<br><br>-- <br></div></div><div dir="ltr">Chris Irwin<br>
<<a href="mailto:chris@chrisirwin.ca" target="_blank">chris@chrisirwin.ca</a>></div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 15, 2014 at 2:54 PM, unsolicited <span dir="ltr"><<a href="mailto:unsolicited@swiz.ca" target="_blank">unsolicited@swiz.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">vm solutions create software virtual layer 2 switches as a software link for vm networking, and as the hardware interface from the whole.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
So the first question is: What is it you are trying to do? What do you mean by tame?<br>
<br>
I do see <a href="http://www.linux-kvm.org/page/Networking" target="_blank">http://www.linux-kvm.org/page/<u></u>Networking</a><br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
(And you're likely better off for the moment making sure it all works happily on a single nic, before introducing a second.)<br>
<br>
{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.}<br>
<br>
In the end, some combination of the following, and it is not a complete or exhaustive list, will be involved:<br>
<br>
- this internal kvm switch handing out dhcp to your vm's, on a SEPARATE subnet from your internal network.<br>
<br>
- changing your router so that designated incoming ports or network requests are directed to this 2nd STATICALLY assigned second nic.<br>
<br>
- 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.)<br>
<br>
- 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).<br>
<br>
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.<br>
<br>
My bet is that you will find any performance gain (vs security assurance) is not worth the additional complexity and maintenance oversight.<br>
<br>
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.<div>
<br>
<br>
<br>
<br>
On 14-08-15 11:30 AM, Khalid Baheyeldin wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On Fri, Aug 15, 2014 at 10:40 AM, CrankyOldBugger<br></div><div><div>
<<a href="mailto:crankyoldbugger@gmail.com" target="_blank">crankyoldbugger@gmail.com</a> <mailto:<a href="mailto:crankyoldbugger@gmail.com" target="_blank">crankyoldbugger@gmail.<u></u>com</a>>> wrote:<br>
<br>
<br>
virbr0 Link encap:Ethernet HWaddr ca:e3:65:49:dc:e4<br>
inet addr:192.168.122.1 Bcast:192.168.122.255<br>
Mask:255.255.255.0<br>
UP BROADCAST MULTICAST MTU:1500 Metric:1<br>
RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br>
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0<br>
collisions:0 txqueuelen:0<br>
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)<br>
<br>
<br>
Don't ask me why virbr0 is there. (Google tells me it's there<br>
because I started tinkering with KVM at some point but I never<br>
finished the task.)<br>
<br>
<br>
Yes, I have that too, and yes, it is caused by libvirt/kvm. And it is<br>
not from configuration in /etc/network/interfaces.<br>
<br>
I want to start building virtual machines on this box, but before I<br>
do I would like to see the server using both NIC cards appropriately.<br>
<br>
<br>
You can make both cards work by putting something like this in your<br>
/etc/network/interfaces<br>
<br>
<br>
auto eth0<br>
iface eth0 inet dhcp<br>
<br>
auto eth1<br>
iface eth1 inet dhcp<br>
<br>
The above will make both interfaces come up at boot, and configure<br>
themselves via DHCP, so the router assigns them an IP address, ...etc<br>
<br>
Or you can assign that manually using something like:<br>
<br>
auto eth0<br>
iface eth0 inet static<br>
address 192.168.0.2<br>
netmask 255.255.255.0<br>
network 192.168.0.0<br>
broadcast 192.168.0.255<br>
gateway 192.168.0.1<br>
<br>
auto eth1<br>
iface eth1 inet static<br>
address 192.168.0.3<br>
netmask 255.255.255.0<br>
network 192.168.0.0<br>
broadcast 192.168.0.255<br>
gateway 192.168.0.1<br>
<br>
This means the first NIC will get 192.168.0.2 and the second will be .3,<br>
assuming that the router is at .1.<br>
<br>
By that I mean it will share the load between any future VMs between<br>
the two NICs,<br>
<br>
<br>
I am not sure what share the load means, or if there is a real answer to<br>
it as asked. So I will leave that to others who know more than me.<br>
<br>
or at least reserve one NIC for the host server and one NIC for the VMs.<br>
<br>
<br>
This can be done in /etc/network/interfaces as well. Assuming you want<br>
the VMs to use only the 2nd network card, then you add:<br>
<br>
auto br0<br>
iface br0 inet dhcp<br>
bridge_ports eth1<br>
<br>
And when creating a VM, via libvirt, you say:<br>
<br>
sudo virt-install --name vm_name ... --network bridge=br0 ...<br>
<br>
This tells libvirt to use the bridge br0, which uses eth1, which you<br>
have configured separately.<br>
<br>
I have not tried this specifically, but it "should work" (yeah, famous<br>
words!)<br>
<br>
(I'm ashamed to say this is much easier in MS Hyper-V, but I would<br>
much rather learn how to do this in Linux CLI!)<br>
<br>
<br>
Tsk tsk tsk ... traitors and infiltrators in our midst ... ;-)<br>
<br>
So I guess my question is two-fold:<br>
<br>
a) how do I tame my NICs in preparation for setting up VMs, and<br>
<br>
<br>
See above.<br>
<br>
b) what's the preferred method for setting up VMs in Ubuntu<br>
Server? Does anyone know of a good how-to link?<br>
<br>
<br>
If you have kvm capable server, then use libvirt. You create VMs using<br>
virt-install on the command line, and use virt-viewer to see the BIOS<br>
and console output, and manage them using virsh.<br>
<br>
Or wait till November, when I will cover all this in a presentation for<br>
KWLUG.<br>
--<br>
Khalid M. Baheyeldin<br>
</div></div><a href="http://2bits.com" target="_blank">2bits.com</a> <<a href="http://2bits.com" target="_blank">http://2bits.com</a>>, Inc.<div><br>
Fast Reliable Drupal<br>
Drupal optimization, development, customization and consulting.<br>
Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra<br>
Simplicity is the ultimate sophistication. -- Leonardo da Vinci<br>
For every complex problem, there is an answer that is clear, simple, and<br>
wrong." -- H.L. Mencken<br>
<br>
<br></div><div>
______________________________<u></u>_________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org" target="_blank">kwlug-disc@kwlug.org</a><br>
<a href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank">http://kwlug.org/mailman/<u></u>listinfo/kwlug-disc_kwlug.org</a><br>
<br>
</div></blockquote><div><div>
<br>
<br>
______________________________<u></u>_________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org" target="_blank">kwlug-disc@kwlug.org</a><br>
<a href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank">http://kwlug.org/mailman/<u></u>listinfo/kwlug-disc_kwlug.org</a><span class="HOEnZb"><font color="#888888"><br>
</font></span></div></div></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div dir="ltr">Chris Irwin<br><<a href="mailto:chris@chrisirwin.ca" target="_blank">chris@chrisirwin.ca</a>></div>
</font></span></div>
<br>_______________________________________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a><br>
<a href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
<br></blockquote></div><br></div>