# [SOLVED] KVM/Qemu networking question

## cach0rr0

not sure which forum to post this, really a crapshoot to be honest. 

SO, I'm about to set up a few KVM guests, and long story short, I have three spare public static IP's I intend to give them. 

However, I only have one physical NIC in this machine. 

Right now: 

eth0 is x.x.x.90

eth0:0 is .91

eth0:1 is .92

eth0:2 is .93

The latter three I'd intended to give to the KVM guests. They'll all have the same gateway (.94) broadcast (.95) and netmask (255.255.255.248). 

I'm trying to get my  head around just how to do this. Do I need to set up a bridge? Can I not simply tell the guests "hey, eth0:1 is yours!" ? 

My main problem honestly, is that I'm so in the dark on proper terminology, I don't even know what to google. 

Any pointers/help appreciated.

----------

## Hu

eth0:1 is largely a fiction needed by some legacy tools that cannot understand placing multiple addresses directly on a single interface.

Create a bridge br0.  Remove your existing address from eth0.  Add eth0 to the bridge.  Apply your .90 address to the bridge.  Create tap devices for the guests and add those devices to the bridge.  Configure each kvm to open a tap device as its network interface with -net tap.  Configure the guest operating systems to place the .91/.92/.93 addresses on their respective virtual NICs.  Each guest will need its own tap device.  The Gentoo netscripts can handle at least some of the tap creation/bridge join logic for you.

Since you will temporarily remove an address from eth0, it is best to do this from the console.  You can get away with moving it remotely if you execute the remove-address/join-bridge/add-address step as a semicolon-separated shell sequence, assuming you get it right on the first try.  Get it wrong and the machine will have no address, at which point you need to get on the console to fix it.

----------

## cach0rr0

cool, cheers for that. 

I'm actually typing this response from that machine, so access wont be a problem thankfully! 

this rig used to be an all-purpose-do-everything server, with a 'hardened' gentoo deployment occupying the entirety of it. 

maintaining RBAC for a multi-purpose server became a pain, so I'm turning it into an "i occasionally use it as a desktop", with a bunch of hardened guests, that serve only one specific purpose, and therefore easy to maintain RBAC policy. 

That's the info I needed though. Will post back one way or another.

----------

## cach0rr0

yip, this worked, marking solved. 

got lost in some of the wiki jargon, and could probably do this through existing scripts, but i wrote my own simplistic ones that do nothing more than mirror the commands i used to get this up and running by default

-bring eth0 up, but dont give it an IP

-bring br0 up, give it the original ip/netmask/broadcast, set the default route with the 'route' command

-starting qemu-kvm as such:

```

qemu-kvm -drive file=/kvm/web/apache.img,if=virtio,boot=on -cdrom /share/iso/systemrescuecd-x86-1.5.4.iso -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -m 2048

```

in the guest, drive shows up as /dev/vda, nic shows up as eth0, so we're all good honestly. 

by default the guest's eth0 had a 10.x.x.x.x address. I just set it to the new public IP with "ifconfig eth0 x.x.x.91 broadcast x.x.x.95 netmask 255.255.255.248" and "route add default gw x.x.x.94"

downloading the hardened stage and portage as we speak. 

Thanks again Hu, always a big help!

----------

## Hu

You're welcome.  That qemu-kvm invocation looks good.  You could optionally use virtio for the network card as well, since you are using Linux guests.

The existing scripts are definitely able to support this usage.  For baselayout-1, look at config_iface to set the address statically, mac_iface if you need to change the MAC address of the tap device, tuntap_iface to declare it as a tunnel device, tunctl_iface to create it owned by the user running kvm, bridge_iface to statically add bridge ports, and bridge_add_iface to dynamically add bridge ports.  Use bridge_iface for eth0 and any other physical cards, since you want to bring them up and add them to the bridge when you initialize networking.  Use bridge_add_iface for the tuntap devices, so that they can be started when you need them, but will be added to the bridge when they are started.  This avoids having the system create and bridge all the tuntap devices when networking is started, which is wasteful if you will only be running the guests for a small part of the system's uptime.

----------

## cach0rr0

had to change my install a fair bit, but the networking bit at least works

-the latest hardened-sources couldnt mount my btrfs volumes (probably the subvoluming stuff)

-the latest one from anarchy's overlay initially got a 404 snagging the grsec patch

-i copied the ebuild locally, modified to snag patch from ./~spender instead of test, as well a new patch name

-that went through fine, kernel build fine, never got past "Uncompressing kernel Image - Ok, Booting the kernel" or whatever, regardless of permutation of nolapic/acpi=off/etcetcetc

so first things first. moved off of btrfs onto something i know 2.6.29-hardened can mount

then I'll see if I can get a more recent one working again from anarchy's overlay

[s]then I'll try moving back to the virtio driver for both net and disk, and patch the system back together from there. Right now just using -hda

one thing at a time.[/s] EDIT: went to virtio for both net and disk. No issues, just had to change fstab and grub.conf to use vda* instead of sda*. [s]The networking piece of this was easy (though, I should build out a proper firewall, I'm wasting a public IP by having to go this bridge route.)[/s]. I still think I'm wasting an IP this way. I hate NAT, but IP's arent cheap, so 1:1 might be better. We'll see. 

anyway, it's cooking along nicely. The primary purpose of this box will be hosting KVM guests, so they'll be up full time. The host disk is all luks with boot and keys on separate USB, so it wont be shutting off in the near future either hopefully! 

This is my first go round with KVM, will be interesting to fiddle with along the way and see how close i can get to bare metal.

----------

