public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Javier Guerra <javier@guerrag.com>
Cc: Chris Lalancette <clalance@redhat.com>,
	Mike Snitzer <snitzer@gmail.com>,
	kvm@vger.kernel.org
Subject: Re: Simple way of putting a VM on a LAN
Date: Thu, 24 Jul 2008 00:15:21 -0400	[thread overview]
Message-ID: <488801D9.6020007@tmr.com> (raw)
In-Reply-To: <90eb1dc70807091023g6d26aba8pa324d6c5cd2b955@mail.gmail.com>

Javier Guerra wrote:
> On Wed, Jul 9, 2008 at 11:28 AM, Bill Davidsen <davidsen@tmr.com> wrote:
>   
>> A bit of the original problem seems to have been clipped before you read it,
>> or I stated it poorly.
>>     
>
> i think you're very confused.  maybe you got it working the hard way,
> but it's really simple to do the easy way.
>   

Your easy way seems to mean using Debian, other distributions don't have 
some of the scripts, or they are in different places or do different 
things. Other thoughts below.
> first, you have to do some small preparations on the host machine, but
> nothing difficult.  this is what i do on my workstation (kubuntu) so
> that i can fire up a test VM at any moment's whim:
>
> - setup a bridge, and use it as main interface
> - add a /etc/qemu-ifup script
> - kvm kernel module
> - make sure /dev/kvm and /dev/net/tun have the correct privilege access.
>
> for the first one, in debian-like systems just use the following in
> /dev/network/interfaces:
>   

That's Debian thing.
> # The loopback network interface
> auto lo
> iface lo inet loopback
>
> # The primary network interface
> auto br0
> iface br0 inet static
>         address 172.18.13.66
>         netmask 255.255.0.0
>         network 172.18.0.0
>         broadcast 172.18.255.255
>         gateway 172.18.0.1
>         bridge_ports eth0
>
> that makes br0 my main interface, and adds eth0 to it. when i'm not
> running any VM, it doesn't interfere in any way, except for any
> utilities that default to eth0... if that were a problem, i could
> simply rename eth0=>peth0 and br0=>eth0 (i think the Xen scripts do
> similar tricks)
>   

That's an interesting trick. I don't know of any problems I'm having 
which require it, but a useful thing to consider.
> when that's set, /etc/qemu-ifup just have to setup the tun/tap
> interface and add to the bridge:
> #!/bin/sh
> ifconfig $1 0.0.0.0 promisc up
> brctl addif br0 $1
>
> and that's it!  no need to meddle with iptables.  note that i don't
> even set the IP, the VM is connected to the LAN, and it setups it's
> own IP "from inside"
>   

Not being a trusting person I find that a bridge is an ineffective 
firewall, but with a bit of trickery that could live on the VM, to the 
extent it's needed. Now the "sets up its own IP" is a mystery, since 
there's no place I have told it what the IP of the machine it replaces 
might be. I did take the obvious step of setting the macadrs of the tap 
to that of the NIC in the original machine, but here I find a problem, 
at boot DHCP is not being used, or perhaps the issue is that some 
internal kvm DHCP service is being used instead of sending the requests 
out and letting my server provide the IP (and gateway, and nameservice, 
and etc). Setting up the IP and routing by hand does result in a working 
configuration, however, so other than the lack of control from using 
iptables to forward packets, it works well.

If the DHCP worked as expected it would really be easy.
> hope that helps
>   

I thank you for sharing your info, it was a good starting point even 
though some of the steps were not portable.

Well, it provides an easier way to get things working, there's one case 
where the iptables is still desirable, but that is a corner case for 
sure. Modulo the DHCP issue it works well, so I can say it did help, 
although not in the way you expected, I suspect.

I'm going to write it up while I can remember what I did and understand 
my notes. I have a bunch of tcpdump files from the physical NIC (eth0) 
and the bridge (br0), and wireshark, so I may get some idea of why DHCP 
isn't working, that would finish the job in most cases. Even if I have 
to do a bit of manual setup, it's faster than setting up iptables, and 
acceptably secure as long as the kvm host is at least as secure as the 
original.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 



  reply	other threads:[~2008-07-24  4:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-27  1:54 Simple way of putting a VM on a LAN Bill Davidsen
2008-06-27  4:46 ` Mike Snitzer
2008-06-27  7:04   ` Chris Lalancette
2008-07-09 16:28     ` Bill Davidsen
2008-07-09 17:23       ` Javier Guerra
2008-07-24  4:15         ` Bill Davidsen [this message]
2008-07-24 14:22           ` Javier Guerra
2008-07-25 16:44             ` Bill Davidsen
2008-07-25 22:31               ` Stuart Jansen
2008-07-26 17:26                 ` Bill Davidsen
2008-06-27 22:44 ` Freddie Cash

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=488801D9.6020007@tmr.com \
    --to=davidsen@tmr.com \
    --cc=clalance@redhat.com \
    --cc=javier@guerrag.com \
    --cc=kvm@vger.kernel.org \
    --cc=snitzer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox