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
next prev parent 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