Javier Guerra wrote:
On Wed, Jul 9, 2008 at 11:28 AM, Bill Davidsen <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
