LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Virtualization and Cloud
User Name
Password
Linux - Virtualization and Cloud This forum is for the discussion of all topics relating to Linux Virtualization and Linux Cloud platforms. Xen, KVM, OpenVZ, VirtualBox, VMware, Linux-VServer and all other Linux Virtualization platforms are welcome. OpenStack, CloudStack, ownCloud, Cloud Foundry, Eucalyptus, Nimbus, OpenNebula and all other Linux Cloud platforms are welcome. Note that questions relating solely to non-Linux OS's should be asked in the General forum.

Notices

Reply
 
Search this Thread
Old 10-24-2012, 10:30 AM   #1
rylan76
Senior Member
 
Registered: Apr 2004
Location: Potchefstroom, South Africa
Distribution: Fedora 17 - 3.3.4-5.fc17.x86_64
Posts: 1,477

Rep: Reputation: 87
KVM - Class B real-world network, yet a Class C real-world config works? Why?


Hi Guys

I've got a Centos 6 instance running directly on hardware that is to exist in a Class B network environment.

I want to run a Qemu KVM instance that 100% emulates the physical hardware Centos 6 Class B network environment and services from the VM, so I can stop the physical Centos 6 and only use the VM Centos 6 instance for all services.

In order to connect the guest Centos 6 instance that is inside KVM to the "real world" Centos 6 that hosts itI've followed these steps as regards configuring the "real" Centos 6 instance so the virtual Centos 6 KVM instance can "talk" on my physical Class B network:

For real Centos 6:

Code:
sudo brctl addbr br0
sudo ifconfig eth0 0.0.0.0
sudo brctl addif br0 eth0
sudo ifconfig br0 192.168.1.120 netmask 255.255.255.0 up
sudo route add -net 192.168.1.0 netmask 255.255.255.0 br0
sudo route add default gw 192.168.1.1 br0
sudo tunctl -b -u john
sudo ifconfig tap0 up
sudo brctl addif br0 tap0
export SDL_VIDEO_X11_DGAMOUSE=0
sudo iptables -I RH-Firewall-1-INPUT -i br0 -j ACCEPT
qemu-kvm ~/win2k.img -m 512 -net nic -net tap,ifname=tap0,script=no
The strange thing is that I can then start the Centos 6 VM, and do

Code:
/sbin/ifconfig eth0 172.16.1.1 netmask 255.255.0.0 broadcast 172.16.255.255
and then do

Code:
ping 172.16.1.51
in the VM. 172.16.1.51 is a real-world physical machine, and the ping WORKS?!

Why, if my physical network is a class B network (as evidenced by the physical machine I have at 172.16.1.51) why can I do a class C real-world config-to-qemu-kvm, and yet ping from the Class B configured VM to the Class B configured physical machine on my real network?

E. g. I'm -completely- confused - shouldn't the physical Centos need a CLASS B config-to-qemu-kvm, to let the virtual Centos inside KVM work as a Class B -virtual- instance?

E. g. why does a Class C real-world tap config work backward to a Class B virtual qemu-kvm instance?

How would I configure a class B physical Centos 6 tap bridge, so that the qemu-kvm instance running virtually on that physical Centos box can use class B addressing?

Thanks!
 
Old 10-24-2012, 06:48 PM   #2
zoltan1
LQ Newbie
 
Registered: Oct 2012
Posts: 9

Rep: Reputation: Disabled
I believe the reason you can ping a real physical machine from inside the VM is because you're using a bridge (br0). You added both your host machine's eth0 adapter and your virtual machine's nic to the same bridge. Traffic will pass through, simply because a bridge adapter acts just like a physical "switch" device. You connect one or more machines to a physical switch and the traffic will go through. The vm can reach the outside Internet because you set the default gateway on your bridge to 192.168.1.1 and I assume that's where your actual router's is at.
 
Old 11-07-2012, 07:51 AM   #3
rylan76
Senior Member
 
Registered: Apr 2004
Location: Potchefstroom, South Africa
Distribution: Fedora 17 - 3.3.4-5.fc17.x86_64
Posts: 1,477

Original Poster
Rep: Reputation: 87
Hi guys

To all interested parties, I think I have solved this issue. In the tap0 setup script that sets up a bridged connection so the KVM VM can access the network, I made two mistakes. My whole premise and idea of what I needed to do, and what I went and did, was wrong.

The first mistake was to setup the bridge based on the wrong IP address. !

The second mistake was to use the wrong netmask for the Class B network I was on.

Once I corrected both of the above, everything started working. In fact I had huge issues with the above Class C / Class B mixup, which I only discovered after extensively testing the setup. I got random connections to either the VM or the host when trying to SSH to 172.16.1.1, and the VNC instance also disconnected randomly. It was all because I had the wrong netmask in the ifup script, and I was bridging on the wrong IP.

First, the rationale. What I wanted was this:

172.16.1.1 - static IP of physical Centos 6 machine (host)
172.16.1.2 - static IP of virtual Centos 6 KVM qemu machine (e. g. the guest which runs "inside" a KVM on 172.16.1.1)

So here is my qemu-ifup.sh for the above:

Code:
#!/bin/sh 
# 
# script to bring up the tun device in QEMU in bridged mode 
# first parameter is name of tap device (e.g. tap0)
#
# some constants specific to the local host - change to suit your host
#
ETH0IP=172.16.1.2
GATEWAY=172.16.1.9
BROADCAST=172.16.255.255
#
# First take eth0 down, then bring it up with IP 0.0.0.0 
#
/sbin/ifdown eth0
/sbin/ifconfig eth0 0.0.0.0 promisc up
#
# Bring up the tap device (name specified as first argument, by QEMU)
#
/usr/local/sbin/openvpn --mktun --dev $1 --user `id -un`
/sbin/ifconfig $1 0.0.0.0 promisc up
#
# create the bridge between eth0 and the tap device
#
/usr/sbin/brctl addbr br0
/usr/sbin/brctl addif br0 eth0
/usr/sbin/brctl addif br0 $1
# 
# only a single bridge so loops are not possible, turn off spanning tree protocol
#
/usr/sbin/brctl stp br0 off 
# 
# Bring up the bridge with ETH0IP and add the default route 
#
/sbin/ifconfig br0 $ETH0IP netmask 255.255.0.0 broadcast $BROADCAST
/sbin/route add default gw $GATEWAY
The problem line at the top was

Code:
ETH0IP=172.16.1.2
which I had as

Code:
ETH0IP=172.16.1.1
which was WRONG, since the Centos host's IP was 172.16.1.2, the bridging script needs to bridge on 172.16.1.2 as well, NOT NOT NOT 172.16.1.1 !

The problem line at the bottom was

Code:
/sbin/ifconfig br0 $ETH0IP netmask 255.255.0.0 broadcast $BROADCAST
which I had as

Code:
/sbin/ifconfig br0 $ETH0IP netmask 255.255.255.0 broadcast $BROADCAST
255.255.255.0 was an invalid netmask for my class B network!

Once I fixed both of these everything started working - I can now ssh to 172.16.1.1 to get to the physical hosts's SSH daemon, and I can ssh to 172.16.1.2 to get to the KVM qemu guest's SSH daemon.

Also, both accesses are stable and I no longer get the "random ssh daemon" problem I had earlier. Clearly it was all my fault, I had let IPs clash in the bridging step and I was using the incorrect netmask for a class B network. Class C had nothing to do with this, this whole thread was simply ignorance, inexperience and a lack of understanding and attention to detail.

Once the above ifup script is done, I start my KVM Qemu instance - something like so:

Code:
sh -f /home/verisharepdc/Desktop/qemu-ifup.sh tap0

/usr/local/kvm/bin/qemu-system-x86_64 /home/verisharepdc/Desktop/vdisk.img -m 2048 -smp 2 -vnc 172.16.1.2:1 -net nic -net tap,ifname=tap0,script=no

sh -f /home/verisharepdc/Desktop/qemu-ifdown.sh tap0
in order to get it to use the tap0 device to be visible at 172.16.1.1 on the network.

Note that in the above, the VNC feed for the running QEmu KVM instance is available at 172.16.1.2:1 - if I pass this as is to TightVNC (for example) it works fine and I can see the XWindows instance running inside the qemu KVM instance.

For reference, here is my qemu-ifdown.sh:

Code:
#!/bin/sh 
# 
# Script to bring down and delete bridge br0 when QEMU exits 
# 
# Bring down eth0 and br0 
#
/sbin/ifdown eth0
/sbin/ifdown br0
/sbin/ifconfig br0 down 
# 
# Delete the bridge
#
/usr/sbin/brctl delbr br0 
# 
# bring up eth0 in "normal" mode 
#
/sbin/ifconfig eth0 -promisc
/sbin/ifup eth0 
#
# delete the tap device
#
/usr/local/sbin/openvpn --rmtun --dev $1
For reference as well, here is my physical machine's /etc/rc.local:

Code:
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local
/sbin/ifconfig eth0 172.16.1.2 netmask 255.255.0.0 broadcast 172.16.255.255 up
route add default gw 172.16.1.9 eth0
#service dhcpd start
#service named start
cp /etc/resolv.conf.bak /etc/resolv.conf
#smbd -D
#nmbd -D
modprobe kvm-intel
modprobe kvm
modprobe tun
sh -f /home/verisharepdc/Desktop/run_vm_unattended.sh &
- As you can see I assign it 172.16.1.2. Correlate with:

Code:
ETH0IP=172.16.1.2
in my qemu-ifup,.sh

Here's my Qemu KVM instance's /etc/rc.local:

Code:
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local
/sbin/ifconfig eth0 172.16.1.1 netmask 255.255.0.0 broadcast 172.16.255.255
route add default gw 172.16.1.6 eth0
#service dhcpd start
#service named start
cp /etc/resolv.conf.bak /etc/resolv.conf
#service nmb start
#service smb start
- As you can see I assign the VM 172.16.1.1

Hope this helps somebody...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
The REAL cause of earthquakes - At least in THAT part of the world. Jeebizz General 40 04-29-2010 08:41 AM
Linux in the real world xeon123 Linux - General 1 09-27-2006 03:48 AM
world class german shepard website crAckZ General 1 09-13-2005 03:27 PM
Week 1 at C++ class/WinXP. A real challenge Mega Man X General 3 10-16-2003 04:11 PM
Libs and real-world use... GAVollink Linux - Software 2 10-14-2003 08:31 PM


All times are GMT -5. The time now is 04:02 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration