ESXi DNS configuration issue

[Thuleman]

Configure Management Network -> IP Configuration -> Use dynamic IP address and network configuration is checked.

When I try to set Configure Management Network -> DNS Configuration to Use the following DNS server addresses and hostname, it appears to do that, but then reverts back to Obtain DNS server addresses and a hostname automatically.

The subnet the box is on uses DDNS. ESXi sets to hostname to the full domain name, i.e. hostname.sub.domain.com

I can ping ESXi on the IP address that was given to the box by DHCP, but I can not ping it on the hostname. I believe this is due to the fact that our network wants the hostname by itself, rather than as full qualifying domain.

However, I also can't ping the box using hostname.sub.domain.com.sub.domain.com.

My question is two-fold:
#1 Why doesn't ESXi allow me to set the DNS Configuration to manual?
#2 Any idea why I am not reachable using the hostname?

Athankyou.

 

[lopoetve]

you're going to make me rebuild my esxi VM aren't you?

frak... I'll get on it. I'm betting that we override the DNS settings by default on DHCP. You'll probably have to write a script in boot that builds the resolv.conf file.

I'll be the first to admit that ESX + DHCP = BAD.

 

[sabregen]

I have had multiple issues in trying to use DHCP or avoiding using the FQDN in an ESX(i) environment. I recall the instructor in the VCP class telling us at least in two different labs (when people couldnt gain access) "This is why you want to use the FQDN." Setting DNS manually, and having DHCP running sounds like a nightmare waiting to happen, and yours has just begun.

Side note - lopoeve's a BSG fan. FRAK EARTH

 

[Thuleman]

I don't have this issue with my ESX boxes as they are in a subnet where I have assigned IPs (physically different location as well). This ESXi is sitting in my office where I am on a DHCP and DDNS based VPN, not much I can do about that.

The leases are 48 hours long and there doesn't appear to be much turn-over in this subnet. I could just set the DHCP assigned IP as my static IP and be done with it (not best practice, for sure ). The DHCP assigned IP of my workstation hasn't changed since I built it some 20 months ago and considering that it was turned off for a couple weeks here and there.

I agree that it looks like the DNS settings are set to auto by default when DHCP is enabled.

By and large this isn't a real problem as I can connect to the IP address using the VI client, I just can't reach the machine by host name. I didn't load any VMs yet, so not sure how this would affect them. I definitely need the hostname to work properly on the VMs as DDNS guarantees that they are reachable even if the DHCP assigned IP changes.

 

[lopoetve]

VM portion should be fine, since they'll act like their own boxes. I've been rebuilding luns all day so I haven't been able to recreate the ESXi box. I'll get on that one shortly.

 

[lopoetve]

I have had multiple issues in trying to use DHCP or avoiding using the FQDN in an ESX(i) environment. I recall the instructor in the VCP class telling us at least in two different labs (when people couldnt gain access) "This is why you want to use the FQDN." Setting DNS manually, and having DHCP running sounds like a nightmare waiting to happen, and yours has just begun.

Side note - lopoeve's a BSG fan. FRAK EARTH

LOL. Frak gaeta!

 

[sabregen]

This ESXi is sitting in my office where I am on a DHCP and DDNS based VPN, not much I can do about that.

I didn't load any VMs yet, so not sure how this would affect them. I definitely need the hostname to work properly on the VMs as DDNS guarantees that they are reachable even if the DHCP assigned IP changes.

Sounds like your setup is very similar to mine. What is your DDNS client? I am using no-ip's DUC on my home machine as the gateway into my network. Are you running an AD domain? Is there any DNS doing reverse lookup on your local subnet? Is your DDNS host machine running windows? Have you tried flushing the DNS cache on it? Have you defined a hosts file on this machine (failing all else)?

lopoetve - Gaeta...what a little bitch. Zareck is good at pulling people's strings, I'll give him that. That last episode was GREAT

 

[Thuleman]

Sounds like your setup is very similar to mine. What is your DDNS client? I am using no-ip's DUC on my home machine as the gateway into my network. Are you running an AD domain? Is there any DNS doing reverse lookup on your local subnet? Is your DDNS host machine running windows? Have you tried flushing the DNS cache on it? Have you defined a hosts file on this machine (failing all else)?

Whoooo ... slow down ....!
No AD here. I have no control over the network at all. I plug the Cat 5e into the wall and into the box, and it all magically works.

When I hook a Centos box into this network I need to create/edit the \etc\hosts and the \etc\sysconfig\network files to add the hostname (without domain) to make DDNS work properly.

 

[lopoetve]

you'll have to do the same, ish, for ESXi

unfortunately, at least one of those (/etc/hosts) is dynamically generated. I haven't checked sysconfig network (or the equivalent) for ESXi - I'll check at work tomorrow.

for /etc/hosts, you'll have to add a script to the box and call it from rc.local - have it echo the appropriate lines to the file.

 

[sabregen]

Whoooo ... slow down ....!
No AD here. I have no control over the network at all. I plug the Cat 5e into the wall and into the box, and it all magically works.

When I hook a Centos box into this network I need to create/edit the \etc\hosts and the \etc\sysconfig\network files to add the hostname (without domain) to make DDNS work properly.

Maybe you can make it the network admins' problem, lol.

 

[Thuleman]

Maybe you can make it the network admins' problem, lol.

I wish I could.
The network folks are overworked, understaffed, and underpaid (yeah, even considering the economic climate), I don't really want to annoy the crap out of them with this little stuff. Me coming in and saying that I need 25 GigE ports for my new cluster, an IP address range, VLANs set up, OoB managment, etc. was probably enough to burn up whatever clout I had with them.

 

[Thuleman]

I actually have an update on this. After some further investigation on how DDNS works on my current linux boxes I found that I have the following under Centos:

file:
/etc/dhclient-eth0.conf

content:
send host-name "hostname";

 

[Thuleman]

Bumping this old thread to confirm that the issue is the same in ESXi 4.
Using DHCP and setting static DNS does not propagate the hostname properly even though the ESXi internal test shows no problem (resolving hostname OK).

Server is not reachable via hostname, reachable just fine via IP.

lopoetve, any suggestions on how to get the above mentioned "send host-name 'hostname'" into ESXi 4?

Also, should I file an SR/bug report for this, or is that just not worth doing as we don't really know whether it's an ESXi problem or a problem with the way our DNS server is set up (over which I have zero control).

 

[AreEss]

The ONLY godsdamned way to work around this stupidity is quite literally, going to give you some nice ugly fits.
First, you'll need to write a shell script which regularly updates /etc/hosts. No. I'm not joking about that. If you're gonna run eth0 as DHCP, you absolutely must have a script which does this, in crontab, period.
Second, you'll need a script which refreshes the DHCP lease on a regular schedule, but always does it not more than 5 minutes before the /etc/host update script runs. Loving this already, aren't you?
Now are you ready for the really really really fun part?
Here's what your dhclient.conf is going to look like:

interface "eth0" {
request subnet-mask, broadcast-address, routers;
supersede domain-name "your.TLD"
supersede domain-name-servers servers go in here;
}

I'm presuming that ESXi isn't stupid enough to use broken DHCP clients. (If that config doesn't work, then the client is one of the broken ones.) You can't miss or skip any single part of this; every single piece in here is absolutely required. You may also need to manually edit/replace /etc/resolv.conf, I don't know how ESXi behaves with regards to that file.
Oh, and it'll break any time you do any network configuration in ESXi, until the next time the scripts run through. And it may break ESXi, because you'll be messing with files that it may want to control tightly.

And this is why you should bridge a NIC into the guest, and bounce it back down to ESXi through a virtual or a separate one. Or tell the network admins to quit being idiots and give you a static, because you need one.

 

[lopoetve]

The ONLY godsdamned way to work around this stupidity is quite literally, going to give you some nice ugly fits.
First, you'll need to write a shell script which regularly updates /etc/hosts. No. I'm not joking about that. If you're gonna run eth0 as DHCP, you absolutely must have a script which does this, in crontab, period.
Second, you'll need a script which refreshes the DHCP lease on a regular schedule, but always does it not more than 5 minutes before the /etc/host update script runs. Loving this already, aren't you?
Now are you ready for the really really really fun part?
Here's what your dhclient.conf is going to look like:

interface "eth0" {
request subnet-mask, broadcast-address, routers;
supersede domain-name "your.TLD"
supersede domain-name-servers servers go in here;
}

I'm presuming that ESXi isn't stupid enough to use broken DHCP clients. (If that config doesn't work, then the client is one of the broken ones.) You can't miss or skip any single part of this; every single piece in here is absolutely required. You may also need to manually edit/replace /etc/resolv.conf, I don't know how ESXi behaves with regards to that file.
Oh, and it'll break any time you do any network configuration in ESXi, until the next time the scripts run through. And it may break ESXi, because you'll be messing with files that it may want to control tightly.

And this is why you should bridge a NIC into the guest, and bounce it back down to ESXi through a virtual or a separate one. Or tell the network admins to quit being idiots and give you a static, because you need one.

Areess,, no offense, but you don't know what you're talking about for once. ESXi doesn't HAVE a crontab. Hell, it doesn't even really have a COS. Second, it doesn't have a dhclient that fits that format, unless something changed from the RC to Gold - ESX is NOT linux, and ESXi has about as much in common with linux as Windows does with an elephant . Fourth, the file that it does use is dynamic, generated at boot. You can edit it all you want - it'll unpack it from the tarball at the next boot and wipe out your changes, same as editing the hosts file. Same with the limited 'cron' system that exists (fun, eh?)

Fifth, I don't have a clue what you're suggesting he do with the guest. You can't bridge NICs in ESXi. He really does need a static IP.

 

[lopoetve]

Bumping this old thread to confirm that the issue is the same in ESXi 4.
Using DHCP and setting static DNS does not propagate the hostname properly even though the ESXi internal test shows no problem (resolving hostname OK).

Server is not reachable via hostname, reachable just fine via IP.

lopoetve, any suggestions on how to get the above mentioned "send host-name 'hostname'" into ESXi 4?

Also, should I file an SR/bug report for this, or is that just not worth doing as we don't really know whether it's an ESXi problem or a problem with the way our DNS server is set up (over which I have zero control).

Lets get this shit figured. Open an SR, PM me the case number so I can monitor. We'll find out either way and get an answer for sure. I'm currently sitting in Heathrow, or I'd rebuild this right now and test for sure - I'll be home in about 18 hours, and then I'll start building an ESX4i box - I need to test something else anyway. We'll figure out where the issue is and get an official answer for everyone else.

I'll see what files we can edit and what we can't in the 4 Gold master bundle too. I ~hope~ we at least left rc.local static so we could generate the files we need, but there's no guarantee for that. And there's no guarantee it'll stay local - this is the disadvantage of ESXi.

 

[AreEss]

Areess,, no offense, but you don't know what you're talking about for once. ESXi doesn't HAVE a crontab. Hell, it doesn't even really have a COS.

Gimme, oh, maybe 3 days? If that? I can do very, very unpleasant things to ESXi - at least from some people's perspective. I'm a Unix admin first and foremost. ESX 3 + root = playground.

Second, it doesn't have a dhclient that fits that format, unless something changed from the RC to Gold - ESX is NOT linux, and ESXi has about as much in common with linux as Windows does with an elephant .

Really? Then why's it using Linux dhclient? You drank too much kool-aid. Want me to get out the packet sniffer to confirm? There's a specific pattern to that dhclient which is unique and recognizable, and also broken. The format I posted is ISC. The format you posted is unique to Linux. Plus I did a lot of snooping around in 3. Markers and behaviors give things away. ESX and ESXi are Linux based in terms of everything that matters to me from an administrative standpoint. Doesn't matter if the kernel's unique; I don't get to play with that. I get to play with userland, and that's Linux.

Fourth, the file that it does use is dynamic, generated at boot. You can edit it all you want - it'll unpack it from the tarball at the next boot and wipe out your changes, same as editing the hosts file. Same with the limited 'cron' system that exists (fun, eh?)

Which is about what I expected, to be honest. ESX/ESXi try to be too smart, which is what annoys me. There's ways around it, by screwing with file permissions, but not sure how ESXi would react to that. And I don't have any room for ESXi to test it at the moment. I could probably make it do what it needs, but frankly, it's far more effort than it's worth. Then again, I have existing scripts...

Fifth, I don't have a clue what you're suggesting he do with the guest. You can't bridge NICs in ESXi. He really does need a static IP.

I may be describing it wrong. Workstation has "Bridge" mode, right? I forget the terminology within ESXi, but essentially dedicate an entire NIC to the guest, and add a virtual interface that connects to the other guests internally. I might have also mixed up platforms and methods, given how tired I was, 'cause I know I can do exactly that with LPARs - dedicate a physical to an LPAR, then add a Virtual Switch Interface on a shared port, IIRC. (I'd have to get my notes, since Virt Switch is new.)

 

[lopoetve]

Gimme, oh, maybe 3 days? If that? I can do very, very unpleasant things to ESXi - at least from some people's perspective. I'm a Unix admin first and foremost. ESX 3 + root = playground.

Not supported. That's why the COS is called tech support mode. It's not supposed to ever be touched except by vmware support for troubleshooting - that's why it's dynamically generated.

Really? Then why's it using Linux dhclient? You drank too much kool-aid. Want me to get out the packet sniffer to confirm? There's a specific pattern to that dhclient which is unique and recognizable, and also broken. The format I posted is ISC. The format you posted is unique to Linux. Plus I did a lot of snooping around in 3. Markers and behaviors give things away. ESX and ESXi are Linux based in terms of everything that matters to me from an administrative standpoint. Doesn't matter if the kernel's unique; I don't get to play with that. I get to play with userland, and that's Linux.

Probably because it was ganked and modified in some form. Doesn't mean you can do what you want with it though, or taht the config files work like you expect. Userland on ESXi is not Linux - it's a pseudo POSIX based area.

Which is about what I expected, to be honest. ESX/ESXi try to be too smart, which is what annoys me. There's ways around it, by screwing with file permissions, but not sure how ESXi would react to that. And I don't have any room for ESXi to test it at the moment. I could probably make it do what it needs, but frankly, it's far more effort than it's worth. Then again, I have existing scripts...

It'll ignore them. The entire userland is unpacked from a master tarball at boot, so everything will be overwritten - it really only exists in memory It's a pseudo environment. FWIW, ESX will let you do that if you want - just not i. i is designed to be embedded and ignored.

I may be describing it wrong. Workstation has "Bridge" mode, right? I forget the terminology within ESXi, but essentially dedicate an entire NIC to the guest, and add a virtual interface that connects to the other guests internally. I might have also mixed up platforms and methods, given how tired I was, 'cause I know I can do exactly that with LPARs - dedicate a physical to an LPAR, then add a Virtual Switch Interface on a shared port, IIRC. (I'd have to get my notes, since Virt Switch is new.)

Yep, but taht doesn't exist in ESX - you can't bridge a card directly to a VM - you just connect it to a vswitch.

 

[AreEss]

Not supported. That's why the COS is called tech support mode. It's not supposed to ever be touched except by vmware support for troubleshooting - that's why it's dynamically generated. Probably because it was ganked and modified in some form. Doesn't mean you can do what you want with it though, or taht the config files work like you expect. Userland on ESXi is not Linux - it's a pseudo POSIX based area. It'll ignore them. The entire userland is unpacked from a master tarball at boot, so everything will be overwritten - it really only exists in memory It's a pseudo environment. FWIW, ESX will let you do that if you want - just not i. i is designed to be embedded and ignored.

Note to self; ESX. Not ESXi. I'm a System Administrator and kernel developer. You do not deny me my userland, under penalty of me finding many, many ways to break things and make it your problem.

Yep, but taht doesn't exist in ESX - you can't bridge a card directly to a VM - you just connect it to a vswitch.

And connecting it to a vswitch isn't the same, because the point of the direct allocation is to keep any other host from doing DHCP incidentally or deliberately on the same port. Presuming it's an ADS environment, AD itself can crash the entire DHCP service or worse horribly if it gets unexpected DHCP_ACKs. It also can and will abort portions - including GATEWAY and DNS - if it gets multiple ACKs. And potentially crash there too. (I might have accidentally done that to a production environment once or twice.)
And guess what happens on some brain dead OSes when they see a DHCP_OFFER for the same MAC, even though they aren't actually configured for DHCP. And since DHCP is entirely MAC based, every OFFER across the wire is likely to be pushed up into guests.
Sigh.

 

[Thuleman]

FWIW, the DHCP/DNS I am up against isn't AD, it's some appliance, unknown to me at this point which make and model. I am considering to actually put in an SR with our networking people over this, although it's probably futile to have them change anything on the DHCP/DNS end.

 

[lopoetve]

FWIW, the DHCP/DNS I am up against isn't AD, it's some appliance, unknown to me at this point which make and model. I am considering to actually put in an SR with our networking people over this, although it's probably futile to have them change anything on the DHCP/DNS end.

Do it. We need an answer.

Note to self; ESX. Not ESXi. I'm a System Administrator and kernel developer. You do not deny me my userland, under penalty of me finding many, many ways to break things and make it your problem.



And connecting it to a vswitch isn't the same, because the point of the direct allocation is to keep any other host from doing DHCP incidentally or deliberately on the same port. Presuming it's an ADS environment, AD itself can crash the entire DHCP service or worse horribly if it gets unexpected DHCP_ACKs. It also can and will abort portions - including GATEWAY and DNS - if it gets multiple ACKs. And potentially crash there too. (I might have accidentally done that to a production environment once or twice.)
And guess what happens on some brain dead OSes when they see a DHCP_OFFER for the same MAC, even though they aren't actually configured for DHCP. And since DHCP is entirely MAC based, every OFFER across the wire is likely to be pushed up into guests.
Sigh.

Userland notes logins in the messages log - fiddling in there on ESXi is unsupported for this reason Hence why it's called "tech-support" mode, and gives you huge red text telling you not to fiddle around when you login.

You do have to realize that the VMs pass their own MAC through the vswitch - it functions like an actual switch, not like a network card. Objects on the physical network will see the VM MAC addy, not the switch MAC addy, much like bridged modes - you just bridge it to multiple vms at once, and they all have their own hardware address. You will never see the vmnic MAC addy on the network - or shouldn't. It's why ESX has it's own "virtual ports" that it uses for the COS even - the vswif is a generated network card just like a VM network card ( which makes sense, since the COS is actually a VM as well ).

 

[AreEss]

Do it. We need an answer.

Ugh, yeah. I have a funny feeling if it's some appliance, that the appliance may be broken, then. Wanna fire up some packet sniffing for me?

You do have to realize that the VMs pass their own MAC through the vswitch - it functions like an actual switch, not like a network card. Objects on the physical network will see the VM MAC addy, not the switch MAC addy, much like bridged modes - you just bridge it to multiple vms at once, and they all have their own hardware address. You will never see the vmnic MAC addy on the network - or shouldn't. It's why ESX has it's own "virtual ports" that it uses for the COS even - the vswif is a generated network card just like a VM network card ( which makes sense, since the COS is actually a VM as well ).

Of course, this presumes that there are no problems with this whatsoever, and that the upstream switch supports this mode of operation on the port. Which is why you don't ever just say it will work fine. There are more than a few switches out there which will collapse a fake MAC from this, into the hardware MAC. Just because it's not designed to do so, does NOT mean it won't happen. Frankly, people should presume it will happen. Remember, an ESX/ESXi host is not going to be capable of signaling MDI/MDIX or indicating that it's a switch, typically. (I'm rusty on my GigE frames, but there's a couple ways to indicate an endpoint is a switch. Not that all switches observe them.) Even when you're writing the vMAC into the frame header, that doesn't guarantee it won't get a rewrite by some overzealous switch.
An example: vMAC -> HW MAC -> Switch, Switch does not ack HW MAC as a Switch, so it collapses all vMACs into the HW MAC and rewrites all frames with what it considers an invalid header. Thus, all traffic at Layer 2 appears to be solely from and to the HW MAC. The only place this causes problems? DHCP.

The key thing is that in most situations, MAC doesn't matter. MAC is really only for ARP/RARP related traffic, such as DHCP servers and clients. Server side, it doesn't matter; spurious offers don't crash anything (just run you out of IPs,) and spurious ACKs don't bother systems that aren't DHCP servers - plus ACK should go to IP. PXE booting makes the request itself, so even if the MAC gets collapsed, it's the only thing looking for or caring about the response. Past these points, your traffic is exclusively at layer 3 or above, where MAC no longer matters. This is especially true if you're using VLANs, too - the switch won't rewrite the VLAN frame tag. IP and VLAN traffic can be switched, bridged, or routed by the vSwitch at it's pleasure.

 

[lopoetve]

ESX is supposed to hide the hardware mac - I've never seen it have a problem, to be honest, on anything from your $5 Linksys switch to a Cisco Nexus.

It's ciscoesque software that makes the vswitch - they support CDP and everything (And have from the 3.0.X era), so they'll respond just like a switch That's the whole point. You're way overthinking them.

And actually, the vswitch can re-write vlan tags. Causes all kinds of fun. They're a switch - limited management, mind you, but you treat them just like a switch. I'm not on the networking team or I'd go into more detail.

 

[AreEss]

ESX is supposed to hide the hardware mac - I've never seen it have a problem, to be honest, on anything from your $5 Linksys switch to a Cisco Nexus.

That's because most common switches, don't try to be smarter than bare bones, and Nexus is supposed to be smart enough to recognize it as VMWare. There's not a lot of switches that do that kind of stupidity, but they do exist. In a special level of hell where they aren't burning nearly enough for my tastes.

It's ciscoesque software that makes the vswitch - they support CDP and everything (And have from the 3.0.X era), so they'll respond just like a switch That's the whole point. You're way overthinking them.

No, that's the problem is that they're Cisco based. What happens when your switch isn't a Cisco and doesn't talk CDP? That's the point I'm trying to make here. Not everything is Cisco. And Cisco is hopefully getting thrown out of more places, with how they're attempting to blackmail and ransom customers.

And actually, the vswitch can re-write vlan tags. Causes all kinds of fun. They're a switch - limited management, mind you, but you treat them just like a switch. I'm not on the networking team or I'd go into more detail.

Well sure, but I was talking about the distant end switch, not the vSwitch. Most switches will not rewrite VLAN tags. If you have routing between VLANs, it'll just strip the VLAN tag and pass the other VLAN a 1500 frame. The other VLAN slaps the tag on, and you're done. To me, it's remarkably boring, having written code to do it. The real fun is when you have one interface on, say, 4 different VLANs, and still need to do hardware tagging in the MAC. At which point I switch from coffee to straight whiskey.

 

[lopoetve]

That's because most common switches, don't try to be smarter than bare bones, and Nexus is supposed to be smart enough to recognize it as VMWare. There's not a lot of switches that do that kind of stupidity, but they do exist. In a special level of hell where they aren't burning nearly enough for my tastes.

Nothing else has ever had problems either. I dare you to show where someone has had an issue with the hardware MAC showing up on the network.

No, that's the problem is that they're Cisco based. What happens when your switch isn't a Cisco and doesn't talk CDP? That's the point I'm trying to make here. Not everything is Cisco. And Cisco is hopefully getting thrown out of more places, with how they're attempting to blackmail and ransom customers.

Nothing else has the problem you're talking about either. Cisco or not. It acts ~exactly~ like a switch. Please, find somewhere someone has had a problem or seen a vmnic show up on the network as even being involved in the process. I've never seen it, and no one here has seen it that I've asked

Well sure, but I was talking about the distant end switch, not the vSwitch. Most switches will not rewrite VLAN tags. If you have routing between VLANs, it'll just strip the VLAN tag and pass the other VLAN a 1500 frame. The other VLAN slaps the tag on, and you're done. To me, it's remarkably boring, having written code to do it. The real fun is when you have one interface on, say, 4 different VLANs, and still need to do hardware tagging in the MAC. At which point I switch from coffee to straight whiskey.

You can have a vmnic on as many vlans as you want - the tagging is done inside the vswitch. You're assuming a problem that doesn't exist - VMWare engineering got this one taken care of a long long time ago.

 

[AreEss]

Nothing else has ever had problems either. I dare you to show where someone has had an issue with the hardware MAC showing up on the network. Nothing else has the problem you're talking about either. Cisco or not. It acts ~exactly~ like a switch. Please, find somewhere someone has had a problem or seen a vmnic show up on the network as even being involved in the process. I've never seen it, and no one here has seen it that I've asked

I'd have to get access to hardware that is incredibly hard to get access to. There's also some misconfiguration involved. Any network misconfigured can cause untold problems. Just because you haven't heard of a problem or seen a problem, doesn't mean it doesn't exist or can't. Part of my job is not just finding, but finding ways to cause problems, so I'm ahead of them.
Long short, the simple description of how to cause it is thus; take a slightly drain bamaged switch. Configure ports to not permit more than X MACs per port (AKA refuse to connect to another switch on that port.) At this point, one of two things will happen: only traffic from the first MAC to touch the port will get passed, or the switch will completely freak out. For extra bonus fun, configure enough VMNICs to exceed the MAC table of a switch and watch how broken things get.

You can have a vmnic on as many vlans as you want - the tagging is done inside the vswitch. You're assuming a problem that doesn't exist - VMWare engineering got this one taken care of a long long time ago.

No, I'm not. I'm spot on, because VMWare does it in software. That's not hardware. Believe me, I have written more than a few ethernet drivers over the years. Doing it in software is cake; you ignore hardware VLAN tagging beyond setting MTU to 1536. Doing it in the MAC with MAC hardware tagging is far, far harder. Last time, I set up one queue per VLAN, and ended up doing queue bursting with register change between bursts.
The difference between hardware and software tagging is this; software tagging, the software creates the frame at 1536 with the VLAN tag already written. Hardware tagging, the software creates and receives frames at 1500 while the NIC handles the VLAN tag in hardware.

 

[lopoetve]

I'd have to get access to hardware that is incredibly hard to get access to. There's also some misconfiguration involved. Any network misconfigured can cause untold problems. Just because you haven't heard of a problem or seen a problem, doesn't mean it doesn't exist or can't. Part of my job is not just finding, but finding ways to cause problems, so I'm ahead of them.
Long short, the simple description of how to cause it is thus; take a slightly drain bamaged switch. Configure ports to not permit more than X MACs per port (AKA refuse to connect to another switch on that port.) At this point, one of two things will happen: only traffic from the first MAC to touch the port will get passed, or the switch will completely freak out. For extra bonus fun, configure enough VMNICs to exceed the MAC table of a switch and watch how broken things get.

Sure, that'll limit VMs, and that does happen - the switch won't see the VMnic mac though, in my experience - only the VM MAC addresses (and any vswif/vmknics that are on there). VMNIC = physical nic, btw, so you only have as many of them as you do physical ports. You won't see the VMnic mac any more than you'd see the mac of your switch in a physical world.

It's been thought out - the physical port is transparent.

No, I'm not. I'm spot on, because VMWare does it in software. That's not hardware. Believe me, I have written more than a few ethernet drivers over the years. Doing it in software is cake; you ignore hardware VLAN tagging beyond setting MTU to 1536. Doing it in the MAC with MAC hardware tagging is far, far harder. Last time, I set up one queue per VLAN, and ended up doing queue bursting with register change between bursts.
The difference between hardware and software tagging is this; software tagging, the software creates the frame at 1536 with the VLAN tag already written. Hardware tagging, the software creates and receives frames at 1500 while the NIC handles the VLAN tag in hardware.

Software that emulates hardware buddy. It looks like hardware to the network.

 

[Thuleman]

... and now; Back to our regular scheduled broadcast of the original problem.

The SR with my network folks was short and sweet, as expected, they say it's a client problem.

The DNS server (bind) accepts whatever name is passed to them by the DHCP (dhcpd) server.
The client needs to pass the host name to the DHCP server. This works without additional steps in Windows, Mac, and apparently also Debian based linux. Redhat based linux (YES! I know ESXi is not Linux!) must ad the send host name "hostname"; line to the dhcp config as it doesn't automagically pass the host name to the DHCP server.

 

[Thuleman]

The SR with VMware was short and sweet, as expected, they say it's a network problem.

Well, not really a network problem, but a network issue. If I want the ESXi host to be accessible by host name, then I need to give it a static IP address. There is no supported way (unsupported ways are unknown atm) to replicate the send host name command on ESXi.

 

[lopoetve]

hang on, I'm back in town.

 

[gimp0]

Case of beer + 2-3 light sabers for the networking team = problem solved