by Duncan Epping
VMware Wolf is generating some awesome blogposts lately:
All the blog posts contain a downloadable html file with a grid. The grid contains problems followed by possible resolutions.
Great blog posts and very useful information, visit VMware Wolfs blog and download the files! Great stuff for your troubleshooting toolkit!
Today I visited a customer that wanted to enable the VMware tools timesync during an automated install of a Windows VM. The customer didn’t want to use powershell / perl or anyother SDK enabled tool. So what’s left?
“C:\Program Files\VMware\VMware Tools\VMwareService.exe” –cmd “vmx.set_option synctime 0 1”
So this command ticks the checkbox for timesync via VMware Tools, which can come in handy when doing RIS alike installs.
How cool is this video about Distributed Power Management, it demonstrates how DPM works and what the possible utility savings could be. Just watch it:
I’ve been doing VMware Design Reviews lately and so are my colleagues of the PSO department. A Design Review is quick scan of your design documentation by a VMware consultant. The consultant will hold your docs against best practices and propose changes to the design.
One of the things we encounter on a regular base is that admins took the easy path for their Storage Design zoning. So what’s zoning? In short: a way to partition your fabric into smaller subsets. These small subsets provide you with a better security and less interference.
You can do zoning in two ways, Soft and Hard. With “soft zoning” you use the device WWN in a zone without any restrictions to what port this WWN is attached. With “hard zoning” you put the port into a specific zone. So what do I prefer? I would prefer “hard zoning” because you need to know how your devices are connected and it makes troubleshooting a lot easier.
So now I’ve chosen a way to zone I can just write down all my port numbers, create a zone and drop them in and I’m done… Well not so fast, that’s another choice one has to make before you start. How am I going to zone, single initiator zoning or multi initiator zoning? So what’s a single initiator zone: a single hba in a zone with the target device(s). And a multi initiator zone is all initiators that need to communicate with a device(s) in one zone. As one can imagine multi initiator zones are really easy to setup but definitely not my first choice.
Single initiator zones are the way to go. If there’s no need, and for ESX there isn’t, for initiators to be able to communicate with each other then they shouldn’t be able to. Not only is this more secure, because initiators can’t communicate with each other, it also cuts out a lot of rubbish on your fibre. Rubbish as for instance “Registered State Change Notifications”. Although RSCN storms don’t occur that often anymore as they used to it’s still a risk of contention and should be avoided when possible. So if you’re doing a design or preparing for one keep this in mind: Single Initiator Zones are the way to go!
There are a whole bunch of good articles on the net about zoning, read them you might learn a thing or two:
Have fun,
It used to be a best practice to increase the “das.failuredetectiontime” to 30000 for an active/standby setup. This way when a failover to another nic occurs one would have atleast 30 seconds to switch over before HA starts shutting down VM’s. The default value is 15000 by the way.
If it’s not really clear I’m talking about a setup like this:
I just noticed in the Resource Management Guide pdf that the best practice is to increase it to 60000. In other words, it can take up to 60 seconds before your HA starts restarting machines. For a secondary service console you only need to increase by 5 seconds cause of the fact that an additional isolation address needs to be checked. In other words a secondary service console saves you 30 seconds when isolation occurs which can be a lot in a 7×24 environment.
So like I blogged three months ago, going for a secondary service console is definitely the best option you have for service console redundancy today! Keep in mind though that your secondary service console needs to be in a different subnet than the primary!