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:

The strange thing is that I can then start the Centos 6 VM, and do

and then do

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!

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.

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:

The problem line at the top was

which I had as

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

which I had as

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:

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:

For reference as well, here is my physical machine's /etc/rc.local:

- As you can see I assign it 172.16.1.2. Correlate with:

in my qemu-ifup,.sh

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

- As you can see I assign the VM 172.16.1.1

Hope this helps somebody...