Tag Archives: vmware

DHCP, Linux bridges and VMware

1 Reply

I do a lot of testing with eve-ng which is in turn running on a VM within ESXi. Naturally I have a Distributed V-Switch, with multiple uplinks for redundancy.

EVE-NG version: 2.0.3-92
Platform: ESXi 6.5
Security config on hypervisor:

  • Promiscuous mode Accept
  • MAC address changes Accept
  • Forged transmits Accept

Unfortunately this seems to break DHCP for reasons I can’t quite fathom. If we look at the topology we are working with:

The DHCP server is hosted on the same hypervisor/dvSwitch, but for some crazy reason, the DHCP Response never makes it across the bridge within the EVE-NG VM.

brctl show
bridge name     bridge id               STP enabled     interfaces
pnet2           8000.000c2976c6ca       no              eth2
                                                        vunl0_1_0
                                                        vunl0_2_1
                                                        vunl0_3_0
                                                        vunl0_4_0
tcpdump -i vunl0_2_1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vunl0_2_1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:05:32.267298 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:cb:38:c2 (oui Unknown), length 300
11:05:32.267602 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:cb:38:c2 (oui Unknown), length 300
11:05:34.265517 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:01:00:00 (oui Unknown), length 300
11:05:34.265784 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:01:00:00 (oui Unknown), length 300
tcpdump -i pnet2 port bootps -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pnet2, link-type EN10MB (Ethernet), capture size 262144 bytes
11:07:32.903789 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:00:00:cb:38:c2, length 300
11:07:32.904151 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:00:00:cb:38:c2, length 300
11:07:32.944639 IP 172.168.1.3.67 > 172.168.1.243.68: BOOTP/DHCP, Reply, length 308
11:07:32.944679 IP 172.168.1.3.67 > 172.168.1.243.68: BOOTP/DHCP, Reply, length 308
11:07:32.944695 IP 172.168.1.3.67 > 172.168.1.243.68: BOOTP/DHCP, Reply, length 308
11:07:32.944817 IP 172.168.1.3.67 > 172.168.1.243.68: BOOTP/DHCP, Reply, length 308
11:07:34.499852 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:00:00:01:00:00, length 300
11:07:34.500099 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:00:00:01:00:00, length 300
11:07:34.500326 IP 172.168.1.3.67 > 172.168.1.240.68: BOOTP/DHCP, Reply, length 308
11:07:34.500409 IP 172.168.1.3.67 > 172.168.1.240.68: BOOTP/DHCP, Reply, length 308
11:07:34.500434 IP 172.168.1.3.67 > 172.168.1.240.68: BOOTP/DHCP, Reply, length 308
11:07:34.500508 IP 172.168.1.3.67 > 172.168.1.240.68: BOOTP/DHCP, Reply, length 308

Seems this issue has been seen before here.

Note that eth0 doing a DHCP request works fine, but the request coming via eth2 dies on the eth2 side of the bridge.

A workaround is to disable the redundant uplinks, which allows the DHCP Response to work as expected.

Updating VCSA

Leave a reply

Fairly simple to update the vCenter Server Appliance, but I had a bit of hunting to track it down myself. Main point is to connect to your VCSA on port 5480. Authentication is using your root account not the SSO one.

As always, be sure to take a backup before you do this.

Once signed in, click Update, Check for Updates. Check Repository (note that VCSA will need internet connectivity for this).

Then under available updates, click install updates, install all updates, and reboot when prompted.

Link

An EMC systems engineer has written a blog post about the VMAX FAST VP array. While it’s full of good advice, he unintentionally sums up everything that’s wrong with many applications in IT today: the knobs.

This is a problem I’ve seem more then once – the box has many nerd-knobs and therefore people feel they have to fiddle with them. Once they start to do that, inevitably something goes wrong and the performance drops. Then they start to fiddle some more to try and ‘fix’ it, until there are so many knobs turned it is impossible to maintain/troubleshoot.

 

Using KVM on top of ESXi

Leave a reply

KVM and VMware

I’ve been playing with SDN, VMs etc. in a lab. Given that I don’t have a load of servers lying around I tend to use VMs (so nested virtualisation) on ESXi. As I learned the hard way there are a few little details you have to watch if you want to use the KVM hypervisor.

ESXi5.1 (or later)

Virtualized HV is fully supported for virtual hardware version 9 VMs on hosts that support  Intel VT-x and EPT or AMD-V and RVI.

Virtual Hardware

Something I learned the hard way was that the VMs I created have virtual hardware VM version 8 by default. This was the default under ESXi 5.0 and doesn’t support virtualised HVs. Using the Web Client stop the VM and upgrade the hardware to VM Version 9 (or later)

vm-hardware-upgrade

vSphere Web Client – Exposing Hardware Virtualisation

With vSphere 5.1 you cannot create a new VM in the Windows vSphere client and allow the virtualization features of the processor to be presented.  So you will want to use the web client to create the shell not the windows client. This seems to be the way it will stay going forward – only the web client will have all the features shown.

Check the ‘Expose hardware virtualisation to Guest OS’ box under the CPU settings.

webClient_virtual_hardwareAnd that should do it – your Guest OS will now be able to run KVM hypervisor (or any other one of your choice)