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 Code:
/sbin/ifconfig eth0 172.16.1.1 netmask 255.255.0.0 broadcast 172.16.255.255 Code:
ping 172.16.1.51 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: Code:
#!/bin/sh Code:
ETH0IP=172.16.1.2 Code:
ETH0IP=172.16.1.1 The problem line at the bottom was Code:
/sbin/ifconfig br0 $ETH0IP netmask 255.255.0.0 broadcast $BROADCAST Code:
/sbin/ifconfig br0 $ETH0IP netmask 255.255.255.0 broadcast $BROADCAST 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 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 Code:
#!/bin/sh Code:
ETH0IP=172.16.1.2 Here's my Qemu KVM instance's /etc/rc.local: Code:
#!/bin/sh Hope this helps somebody... |
All times are GMT -5. The time now is 05:27 PM. |