I just received the following email:
Duncan,
I just wanted to let you know that you have passed the VI3 Design exam, the third of five parts of the VCDX certification program. Next steps are the submission of applications and then the defense.
Scoring our exams took a long time because we were in the alpha group. But I passed… I’m happy! I just submitted my Design and all application forms, and I’ve got the defense scheduled for upcoming Monday! Yihaaa,
I just received an email about an excellent article on VI:OPS. The article is titled “Automating Network Setting Changes and DNS Updates on Recovery Site Using VMware vCenter Site Recovery Manager“. It includes a PDF file which contains a description for configuring automatic IP-Changes but also includes batch files for DNS updates.
When performing site failover, IT administrators are often faced with challenges to deal with disparate networks on the recovery site:
- Network properties of virtual machines need to be customized according to the network specification of the recovery site.
- Domain Name Server (DNS) records pertaining to these virtual machines need to be updated.
VMware® vCenter Site Recovery Manager (SRM) enables customers to design automated recovery plans that incorporate all these necessary network property changes, relieving them of the repetitive and error-prone manual tasks.
This paper shows the mechanisms that SRM customers can use in order to automate these tasks related to network related changes.
A quick intro: my name is Ian Gibbs, and I’m a former VMware PS Consultant like Duncan currently is. I’ve just transitioned to a role with a VMware customer where I’m responsible for delivering VMware View for real to 3000 users. Duncan has kindly invited me to share the things I learn with the world. I hope to post some scripts and things I create to help make life easier for you all.
This week I have been redesigning the storage layout for the View implementation. There’ll be a few other posts to come on this as it has turned out to be a massive topic, but this sub-task has been to determine the rate at which the vClone disks are growing so that I can size the datastores properly. We have around 100 pilot VMs and I wanted to see how big each vClone disk was versus its age. This turns out to be harder than you’d imagine, as ESX/Linux/Unix file systems don’t store file creation times. Anyway, a script was required and duly created. I hope you too find it useful. To use it:
My results average out roughly like this:
3hrs: 560Mb
20hrs: 700Mb
90hrs: 850Mb
We’ve moved the pagefile off C: to the UDD so my results will probably be lower than yours. Now to find out why it goes to half a gig so quickly…
I was just reading a discussion on the VMTN community on CPU affinity. The general opinion of the Experts is “Don’t use CPU affinity”. I fully agree with them, ESX is more than capable to handle the scheduling on it’s own with just a limited overhead. And like Ken Cline also stresses it could harm performance because of NUMA load balancing for instance.
Something that’s often overlooked though when one does CPU affinity is that people tend to give the VM vCPUs a 1:1 relationship with host cores. In other words a VM with two vCPUs will be pinned down to two cores on the host.
This does make sense doesn’t it? No it actually doesn’t. There’s more to a VM than just it’s vCPUs. I would like to refer to page 132 of the Resource Management Guide, aka HA-DRS Bible. In short, besides the vCPUs there are several VM associated threads that need to be scheduled as well. When affinity is set these threads, or worlds as VMware calls them, will be scheduled on the assigned cores. You can imagine that when you use the vCenter client to manage the client these threads(Video / Keyboard / Mouse / CD-Rom etc) will need to be scheduled on the same set of cores as the vCPUs need to be scheduled on… If you have a two vCPU VM and want to use CPU affinity pin it down to at least three cores! Before you start assigning cores to your VM also read the bulletpoints on page 133 why you shouldn’t.
The CPU affinity setting for a virtual machine applies not only to all of the virtual CPUs associated with the virtual machine, but also to all other threads (also known as “worlds”) associated with the virtual machine. Such virtual machine threads perform processing required for emulating mouse, keyboard, screen, CD‐ROM and miscellaneous legacy devices.
In some cases, such as display‐intensive workloads, significant communication might occur between the virtual CPUs and these other virtual machine threads. Performance might degrade if the virtual machineʹs affinity setting prevents these additional threads from being scheduled concurrently with the virtual machineʹs virtual CPUs (for example, a uniprocessor virtual machine with affinity to a single CPU, or a two‐way SMP virtual machine with affinity to only two CPUs).
For the best performance, when manual affinity settings are used, VMware recommends that you include at least one additional physical CPU in the affinity setting in order to allow at least one of the virtual machineʹs threads to be scheduled at
the same time as its virtual CPUs (for example, a uniprocessor virtual machine with affinity to at least two CPUs or a two‐way SMP virtual machine with affinity to at least three CPUs).
Just noticed three SRAs were updated. Might be worth checking out:
I added one of the fixes which is included with the EMC Symmetrix SRA cause I blogged about it a couple of months ago and I’m glad this has been solved.
I just noticed this awesome work by LucD. He developed two scripts which can import and export DRS affinity rules. Especially in large environments or environments that have multiple affinity rules this is an excellent solution. Take a look at the link above for more details. Luc posted the script half way down the topic in text but also added a modified version at the bottom. The VI Toolkit at it’s best… or should we call it PowerCLI these days?
I still receive a lot of beta invitation requests while it has been really quiet around Bluebear Kodiak over the last couple of months. (I did a (p)review a while back) I just received an email that a brand new version of the Kodiak beta is about to be released. I already received the Air file but haven’t been able to test it yet. But Matt Miller of Bluebear uploaded a demo video just which shows some of the new features and I must say it really looks slick.
If you are still looking for an invite, I received another 50 and it’s on a first come first serves base. Just click here for an invitation.
(update: the invites don’t seem to be working, I will ask Bluebear to fix it asap.)
