What I learned yesterday: DvSData Folder,View all IPs, Sysprep & Guest Customization
Following on this weeks theme of letting people know I’m just human and learn something new everyday. Here’s what I learned yesterday.
What is the DvSData Folder?
If you are using DvSwitches you might notice on your on one your shared VMFS volumes a .DvSData folder like so:
I was prompted to investigate further via an email from Jeremy Waldrop of varrow.com asking me what the heck this folder was for. In truth I wasn’t 100% sure, pretty clearly it has something to do with DvSwitches, and the fact that although DvSwitches are configured in vCenter fundementally where they stored/live/do there work is down to the ESX hosts. After all that’s where the physical VMNICs are. I’d seen this folder whilst writing my vSphere4 book, and it was one of those “I must double back and check that out” things, which I hadn’t gotten around to working out.
I figured some of my collegues on the private trainer forum had problem come across this – so forum-wacked there. Here’s what the DvSdata folder is all about (by the way this is a cut and paste job, because I can’t think of more succinct way of putting this!)
“DVS switches create a “hidden vSwitch” on each ESX host. This enables the ESX host to continue to use the DVS switch even if the vCenter Server goes down. The data that describes DVS is stored automatically on each ESX host in some shared storage location. The actual location is chosen automatically. One of the things can do is use the net-dvs command to locate where in shared storage information on a particular DVS is. Here is a sample though. Early in the net-dvs output it correlated the HEX code for the DVS switch with the switch name:
./usr/lib/vmware/bin/net-dvs
View all IPs of VM:
This has probably been around for years and years, but its new to me. I frequently give some of my “core” VMs multiple IP addresses. Don’t want to get into the ins and outs of why I do this – but I do. Sometimes I forget what IPs I’ve assigned to which VMs. I don’t have many “core” VMs that I do this too (about
but the number of IPs is growing, and I’m bit bloody lazy and I’ve never listed these in a spreadsheet. Previously, I would remote console to a VM and do ipconfig /all completely unaware that in vCenter4 their is a View All button that will show you all the IPs assigned:
Of course, if I want to list all my IPs in use (perhaps to put together that spreadsheet I should have) a bit of PowersHell might be handy too:
Get-VM | select name, @{Name=”IP”; expression={foreach($nic in (Get-View $_.ID).guest.net) {$nic.ipAddress}}}
Sysprep.inf & Guest Customization:
This is one I’ve known for a while but never every bothered look into – re-using the sysprep.inf file create a guest customization profile. I alway create a new guest customizations by running through the wizard and saving them at the end. I’ve never just created the guest customization by scratch, and that’s where I saw the sysprep.inf option. Why is this hand? Well, the guest customization wizard only handles a fraction of your deployment needs. Unless your using View3 “Linked Clones” which can add virtual desktops to the right OU, if you using ordinary template deployments, all your new virtual desktops get dumped in the default computers container. Well, not if you use a sysprep.inf file which support computer account placement!









RSS
iTunes
December 19th, 2009 at 7:20 pm
Hi Mike
Just following up on this .dvsData and local db chat we had on twitter with a little article.
Reading through your notes here I read that vCenter decides where to store the .dvsData folder but that this generally tends to be shared VMFS storage. Can I presume this is what vCenter accesses?
If it’s shared storage I’m thinking that as long as all hosts can see it they can work off the .dvsData folder. I’m thinking that the local db only comes into play if both the vCenter server is down and the ESX host cannot connect to the shared storage location that houses the .dvsData folder.
Be interested to hear your thoughts on this one
Regards
Craig Stewart
December 22nd, 2009 at 2:49 pm
That’s good question – one would assume if the DvSwith changes – that change is first sent to the VCDB, then to the DvSFolder, followed by local sync to the local DB. But to be quite honest I don’t know if that is the correct order. There’s nothing in product documentation as far as I am aware that would tell you that – product documentation doesn’t even mention the DvSwith Folder… Let me ask some folks at VMW and see what they say…