VMware vSphere 4.0 Update1 “A”
Coming of tweet from Eric Sloof, and from a blog post by Duncan Epping.
http://www.yellow-bricks.com/2009/12/10/esxi-4-0-update-1a/
http://downloads.vmware.com/d/details/esx40u1_a/ZHcqYmRqampiZGUlaA==
It looks as if VMware have released a U1-A, another sub-update to their update – shades of Service Pack 1a for Windows? I guess you could say that. The new update address the HP Insight Management Agent upgrade bug that reared its ugly head during the Thanksgiving Holiday period, which initiated an “August 12th” response from VMware in the form of announcements and eventually lead to them withdrawing U1 from VMware Update Manager.
The download page for U1-A also mentions a disconnect bug in ESXi that would occur after upgrading vCenter 4.0 to vCenter 4.0 U1.
http://kb.vmware.com/kb/1016262
The U1-A does NOT address this issue – and ESXi customers are advised NOT to upgrade until there is fix. That’s little comfort to people like me who have. I have ESXi host that repeated disconnects from vCenter even though its pingable. A restart of the network and management agents does not fix it.
Verdict? I will wiping the ESX host and putting ESX ‘Classic’ in the New Year.
As for U1. The jury is out on its quality. I upgraded because I wanted to use View4. Actually, View4 does work without the update – but to do so is unsupported. I’m now wondering if I should have bothered with U1.
I did a perfectly functional SRM4.0 deployment, however since U1 I’ve had nothing but problems – networking problems between the SRM and the vCenter. The trouble is it’s hard to conclude these problems are the fault of U1. Although nothing changed in my lab environment accept the U1 roll-out and the ‘repair’ of SRM that has to happen afterwards.
I guess should take heart. My woes are not in a production environment. But a lab environment. Rolling out U1 was a risk, but one that was quite small. I’ve decide to stop work for the rest of the year. I’m all tuckered out from 2009. I have course to teach next week in Swindon – and then its Xmas week. So I think I will leave the broken environment I currently have where it is – and start a fresh in the New Year.





RSS
iTunes
December 11th, 2009 at 5:18 am
[...] are pretty rough edges. Add that to a lot of the issues with vSphere Update 1 (well documented by Mike Laverick) and it looks to me like View 4 really was released too [...]
December 15th, 2009 at 6:31 pm
Had a similar problem. We didn’t upgrade our vSphere to U1 but left it at release build. All my ESXi hosts were fine with no management agents on them. Everything looked good until after the reboot -
8 hosts running ESXi (latest and greatest) showed up in vSphere as 3.5 hosts (of assorted builds). vSphere tried to install ESX agents on ESXi hosts – not a good choice.
6 hours with vmware support and do you know what fixed it? Timing reboots of the host with vSphere service restarts. I call that getting lucky
January 26th, 2010 at 2:02 am
Mike, were you ever able to attribute your SRM issues to Update 1. We’re working on an SRM 4 and U1 deployment and having very strange connectivity issues. We get disconnected repeatedly from the remote SRM server.
Thanks!
January 26th, 2010 at 8:48 am
Well, I never really did conclusively get to the bottom of my network problems. Although have appeared for the moment to “go away”. Yeah, I don’t you just love it when a problem randomly resolves itself – and your clueless to why. But a couple of points. Firstly, I’m still running on Update 1(a) – and I’m not convinced that U1(a) was the source of the problem. Secondly, I was using vmxnet on W2K3-32-Enterprize on a physical switch that wouldn’t support any of the advanced features – I’ve rolled back to using the ‘Flexible’ vmxnet driver – and that did NOT appear to be a killer. I’ve heard tales in the Linux world that the vmxnet3 driver caused problems. Thirdly, I team my NICs using “originating port ID”. This is meant to be ultra-compatible with any pSwitch configuration which is a must for me because I have the cheapest netgear gigabit switch in my lab environment. Occasionally, I split the NICs across two of these netgears simply because I’ve run out of ports. In the past (3.5) this didn’t cause a problem – and is of course best practise. Switching to a single vSwitch with single vmnic seems to have made things much better. SO… now I’m wondering if it is pSwitch that’s the problem or fault nic – causing an intermittent network outage… Putting my virtual dc, vc, sql, srm all on the same vSwitch has helped – because well, then there is no physical layer to worry about (except when the two SRM/VC’s need to chat to each other).
In short there doesn’t appear to be any reason – and the fact the problem disappeared isn’t one that reassures me it won’t come back again. I’m investing in single pSwitch that’s 48 ports to see if it is indeed a physical problem…