0

Morning all

I'm currently trying to set-up a Nested CentOS 7.0 KVM host inside a vSphere ESX 5.1.0 hypervisor. I've been following http://virtuallyhyper.com/2012/07/installing-kvm-as-a-virtual-machine-on-esxi5-with-bridged-networking/
I've managed to get the KVM Host installed successfully, and it's configured to support KVM and libvirt.

However the issue comes in when I try and pxeboot a KVM Guest against my existing DHCP server.
I can see a DHCPDISCOVER being issued by iPxe, and the DHCP server logs a DHCPOFFER, but it never receives a DHCPREQUEST from iPxe on the kvm-guest.

I've setup the KVM host with a bridged network, and disabled the 'default' NAT network:

[root@kvm-test ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.005056970ea0       yes             ens160
                                                        vnet0
[root@kvm-test ~]# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.18.51  netmask 255.255.255.0  broadcast 192.168.18.255
        inet6 fe80::250:56ff:fe97:ea0  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:97:0e:a0  txqueuelen 0  (Ethernet)
        RX packets 105230  bytes 13897310 (13.2 MiB)
        RX errors 0  dropped 11  overruns 0  frame 0
        TX packets 105566  bytes 44412894 (42.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::250:56ff:fe97:ea0  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:97:0e:a0  txqueuelen 1000  (Ethernet)
        RX packets 105378  bytes 15365254 (14.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 106773  bytes 44491366 (42.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 217153  bytes 54126840 (51.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 217153  bytes 54126840 (51.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fc54:ff:fec1:978  prefixlen 64  scopeid 0x20<link>
        ether fe:54:00:c1:09:78  txqueuelen 500  (Ethernet)
        RX packets 40  bytes 17480 (17.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 743  bytes 48921 (47.7 KiB)
        TX errors 0  dropped 755 overruns 0  carrier 0  collisions 0

The guest is configured with a 'bridged' interface:

[root@kvm-test ~]# virsh edit 2
<domain type='kvm'>
  <name>kvm-guest.test.card.co.uk</name>
  <uuid>82c15c03-aec5-4dd9-ad23-67275f742c89</uuid>
  ...
  <devices>
    <interface type='bridge'>
      <mac address='52:54:00:c1:09:78'/>
      <source bridge='br0'/>
      <model type='e1000'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
  </devices>
</domain>

iptables is disabled on the KVM host, and there's no local dhcp server running.

Any ideas on what the issue could be?

Cheers
Gavin

  • did you find an answer? My idea is, that maybe your guest has a blocing firewall? – sedrubal Jan 18 '15 at 16:20
  • Not found an answer as yet... Can confirm that the firewall is switched off on the qemu host... So it's not that... – fatmcgav Jan 19 '15 at 17:06
1

I Had same problem and I solved it by typing the following command :

brctl setageing 'bridgename' 0. where the name of your bridge goes in the 'bridgename' spot.

To make it persitent after a reboot, you can add this command at the end of the file /etc/rc.local.

Br.

  • Note that this disables MAC address learning on the bridge, which will cause it to forward all traffic to all attached ports, rather than just the one the destination device is actually connected to. That said, it did help me debug my issue by allowing traffic to pass. – vilhalmer Feb 11 '18 at 14:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.