Howto: Removing a disk from a VM - howto identy the right disk?

From time to time, we need to remove disks from a VM. If there's only two or three disks attached to the VM, it's typically not a problem figuring out which one to remove e.g. if the disks have different sizes. But if you have seven or eight disks and they are the same size, then it's a bit more tricky - let's say if you're asked to remove the 'E-drive'. Under 'Edit Settings' for the VM, the disks only have a number which does not necessarily correspond with anything within the VM.

So how to identify exactly which disk that corresponds with a given volume within Windows?

The match can be made by looking at the SCSI target ID for the disk - this can be identified both in WIndows and under 'Edit settings' for the VM (A VM can have four SCSI controllers with up to 15 disks on each controller, so a maximum of 60 disks per VM).

To identify SCSI target ID within the VM:

Go to Computer Management -> Disk Management

Right click a disk and choose Properties

On the General tab you will see the Bus number (SCSI controller) and the Target ID (SCSI target ID), note the number - in this case below the ID is 4.

To identify SCSI target ID from the VI client:

Now go to 'Edit Settings' for the VM under and locate the disk with the corresponding target ID (see Virtual Device Node for the disk). Make sure the that the controller number and SCSI ID is the same. In this case it is Hard Disk 5 that have SCSI ID 4.

Shut down the VM to remove the disk.

Resetting the root password on ESXi 5 (and ESXi 4)

Yesterday, we had a fairly nasty situation at work where a standalone ESXi 4.1 host had to be rebooted. After reboot it did not automatically reconnect to vCenter and so a manual reconnect was done which prompted for root password. Unfortunately, we did not have the root password (don't ask). The host was joined to a domain but it could not be added to vCenter by using domain credentials and ssh to host with domain credentials did not work either. So, having 19 VMs down and no way to power them back on, I was basically screwed (all VMs were residing on DAS).

According to this VMware KB article there is no supported way to reset the root password on an ESXi v4 or v5 other than to reinstall it (or do a repair). I contacted VMware support and they sent me a guide for doing it in an unsupported way.

Finally, I mounted the ESXi 4.1 install ISO and did a repair. This resets most host configurations such a root password, network configuration, ntp settings, domain etc. After this I could set the pas

sword, reconnect to vCenter and then I had to reconfigure the host. Fortunately, the VMs were not completely gone from vCenter but were presented as greyed out orphaned VMs. So I could still see which LUNs the VMs were residing on. That way, the .vmx files could be located (except for one VM that had been renamed in vCenter without svMotioning or migrating it to another LUN afterwards...), the orphaned VM could be removed and the VM could be readded. It was quite a boring process but a least it worked.

Today, I wanted to recreate the password reset method in my home lab to see if I had actually done it in the correct way. I can confirm that, at least, on a virtual ESXi 5 it works and it is possible to reset the password to blank.

These are the steps
Download a Linux live bootable ISO. I used KNOPPIX. Mount the ISO and boot the host.

Once booted into KNOPPIX, open a shell.


Run the following set of commands:

# fdisk -l
# mkdir /mnt/disk
# mount /dev/sda5 /mnt/disk

(Mounting the correct device is the tricky part. To me, it was rather confusing which one to choose. For both the Fujitsu server that I dealt with and for the virtual ESXi, though, it was in sda5 that the state.tgz file was located.
VMware suggested using the following command for HP servers:
# mount /dev/cciss/c0d0p5 /mnt/disk - c0d0p5 is controller 0, disk 0, partition 5)

# cd /mnt/disk
# ls -al
# cp state.tgz state.tgz.bak
# cd /ramdisk
# mkdir temp
# cd temp
# tar zxf /mnt/disk/state.tgz
# ls -al
# tar zxf local.tgz
# cd etc
# nano shadow


Blank out the encrypted password. For example change root:$1$ywxtUqvn$9e1iXjGVd45T5IAgRxAuV.:13358:0:99999:7:::
to root::13358:0:99999:7:::

See below screendumps for before and after:

Save the shadow file.

Run the following commands to repackage everything:

# cd ..
# rm -rf local.tgz
# tar zcf local.tgz *
# chmod 755 local.tgz
# rm -rf /mnt/disk/state.tgz
# tar zcf /mnt/disk/state.tgz local.tgz
# ls -al /mnt/disk/
# umount /mnt/disk
# shutdown -r now

Disabling cores in BIOS for BL460c Gen8

Due mainly to licensing rules imposed by Oracle and Microsoft, there is an increasing demand for either locking VMs to specific hosts (like with VM-host-affinity rules) or for decreasing the number of physical CPUs or logical cores in the ESX hosts.

For HP hardware it is possible to order Blade servers with 2, 4, 6, or 8 cores - at least for BL460c Gen8. But in my company, we like to keep things as standard as possible, not having too many different hardware models.

As per Gen8, it is possible to disable a given number of cores in the BIOS. It has to be increased/decreased in pairs from 1 to 8. So as a minimum you can have 1 core enabled on each CPU. It is not possible to deactivate one of the physical CPUs.

Downloading VMware tools seperately from VMware site

The other day I had to extract the VMware tools ISO for a customer. One way to do it is to log on to a VM that has not updated VMware tools to latest version, choose to upgrade VMware tools manually and then copy all of the files on the mounted ISO and make a new ISO.

However, the different versions of VMware tools can also be downloaded directly from VMware's website on http://packages.vmware.com/tools. There are also tools version for Windows servers.

I found some more info on it on this site

Why Are There Two VMX Files?

Have you noticed that for a powered on virtual machine in vSphere 5.1, there is now an additional VMX file that ends with an ~ (tilde) found within the virtual machine's configuration directory?

This was an observation that was made by a few folks and some thought it might be related to a virtual machine's lock file which is created when a virtual machine is powered on. After a bit of research, it turns out this extra VMX file is not a lock file but actually an "edit file". This edit file is a copy of the original VMX file and when changes are required, they are applied to the edit file first. Once the changes are complete, the edit file is then atomically swapped with the original VMX file which helps prevent potential VMX file corruption. In the worst case event where the original VMX file is somehow corrupted, the virtual machine can be restored using the edit file.

This is another reason why you should not be manually editing a virtual machine's VMX file, especially when it is still powered on. For any VMX configuration changes, you should be automating using the vSphere API through the use of either PowerCLI or the vSphere SDK for Perl.

How to change SID in Windows Server 2008 R2

Most of the tech guys usually work on VMware and some other Virtual platforms and usually install the same OS to create multiple copies. You can do this copy by two methods.

1.      By cloning the virtual machine

2.      By Changing the SID of the OS so that it will not conflict.

In previous version of Windows like 2003 we usually use NewSID.exe that is recommended by Microsoft to changing the SID. But if you will use this NewSID.exe with windows server 2008 it will work but if you will use this for Windows Server 2008 R2 then your OS will be crashed and will be rebooted in recovery mode every time you restart.

In this blog i will describe you how to change SID on Windows Server 2008 R2.
The method is to use sysprep. 

First, click on  Start->Run, type sysprep and press OK.

This will open sysprep folder which is located in c:\Windows\System32. Open sysprep application.

This will open System Preparation Tool 3.14 window. As a System Cleanup Action select Enter System Out-of-Box Experience (OOBE).

Important: select Generalize if you want to change SID, it’s not selected by default.

As Shutdown Options select Reboot.

It will take some time for sysprep to finish.

After rebooting you will have to enter some data, like Country or region, Time and currency and Keyboard input.

Also, you will have to accept EULA. After booting, in Server Manager you’ll see that everything is changed, if you had some settings that you had configured earlier that will be changed as you have some new OS.

You can check the SID if you want to check
Also you can use the PsGetSid that is very small utility to check the SID

How To Backup & Restore Free ESXi Host Configuration

ESXi host configurations can easily be backed up and restored using either the vCLI's vicfg-cfgbackup or PowerCLI's Get-VMHostFirmware cmdlet. These commands along with others that perform "write" operations are only supported when you have a (paid) licensed version of ESXi. If you are using free ESXi, the remote commands are only available for "read-only" operations.
Note: In my personal opinion, it is much quicker and more efficient to re-install ESXi and apply your configurations using either a scripted deployment such as kickstart or a combination along with post configuration scripts. Re-installs become extremely trivial when you centralize your ESXi host configurations, even for small setups. 

Having said that, if you are running free ESXi in a small shop or in a home lab and wish to backup your ESXi host configurations, you can still do so by leveraging a neat little tool called vim-cmd found within the ESXi Shell. There is a section under hostsvc/firmware which manages the ESXi host configuration which also uses the same vSphere APIs that both vicfg-cfgbackup & Get-VMHostFirmeware command uses.

Under this section of vim-cmd, there are four commands:

• backup_config   
• reset_config    
• restore_config  
• sync_config

Prior to actually backing up your ESXi host configuration, run the following command which will flush the ESXi configuration changes:

vim-cmd hostsvc/firmware/sync_config

To backup the ESXi host configurations, run the following command which will generate a file that will be automatically stored in /scratch/downloads and can also be downloaded from a web browser using the URL shown from the output:

vim-cmd hostsvc/firmware/backup_config

Before restoring your ESXi host configurations, you will need to ensure the file is renamed to configBundle.tgz and stored under /tmp directory. You will also need to ensure the ESXi host is placed in maintenance mode by running the following command:

vim-cmd hostsvc/maintenance_mode_enter

To restore the ESXi host configurations, run the following command and specify the backup configuration file which should reside in /tmp/configBundle.tgz:

vim-cmd hostsvc/firmware/restore_config /tmp/configBundle.tgz

Note: Upon completing the restore, it will automatically reboot your ESXi host.

Here is a screenshot using the above commands to backup and then restore ESXi host:

Note: You can not restore an ESXi host using a configuration file backed up from a different host.

Enable Auto Startup After Power Failure For Apple Mac Mini

I recently came across a very useful tidbit after receiving several inquires asking how to configure an Apple Mac Mini to automatically startup after a power failure. This is extremely useful for situations where power is eventually restored and you are not physically around to press the power button. Automatically starting up after a power failure is not a new feature of the Mac Mini and it actually exists on most modern day systems and can be configured using a variety of tools.

The challenge arises when you are running ESXi, how do you go about enabling this functionality in ESXi itself? Well the answer is actually quite simple, you can enable this outside of ESXi. Normally to enable this feature you can either run a setpci command on UNIX/Linux system or configure the energy saver settings in OS X. Several folks from the VMTN community such as zippytiff and twuhabro have already confirmed having success using the latter option when booting OS X off a USB or SD card to modify the energy saving settings.

I finally got a chance to look into this a bit more for myself and with a bit of research, I found several other methods which also works and may potentially be easier.

Note: I have heard that historically the auto startup flag has not persisted in older Apple hardware, but for the new Mac Mini 5,3 and 6,2, they seem to be persisting without any issue from my testing. YMMV depending on your hardware and/or firmware.

Method 1 (Configure in OS X)

If you already have OS X install on your Mac Mini, then you just need open up the System Preferences and enable auto startup under the Energy Saver section. Once that has been enabled, you can then perform your ESXi installation.

If you already have ESXi installed, then you can use either Method 2 or 3.

Method 2 (Configure using bootable Ubuntu on USB)

We can create a bootable Ubuntu image running off of a USB device (minimal footprint) and run the following setpci command to enable auto startup:

setpci -s 0:1f.0 0xa4.b=0

If you are interested in the gory details on the above command, please refer to this great article which breaks it all down for you. After you have created your Ubuntu image using the instructions in the above link, you can boot off of the USB device (Make sure to hold down ALT/OPT key so you can select to boot off of the USB device). Once Ubuntu has booted up, you will right click on the purple icon on the upper left hand corner and type in terminal.

You will then launch the terminal application and type the following to change over to root user.

sudo su -

Finally, you will enter the above setpci command which will enable the auto startup. At this point, you can type reboot and remove the USB device.

Method 3 (Configure using bootable OS X on USB)

Another method is to create a bootable OS X image running off of a USB device and change the power management settings by using the pmset utility. To enable auto startup, run the following command in the terminal:

pmset autorestart 1

You will need the original OS X installer and if you are using either Lion or Mountain Lion, you can use Lion DiskMaker to help you create the bootable USB image (Make sure to hold down ALT/OPT key so you can select to boot off of the USB device). Once the OS X installer boots up, at the top select Utilities and click on the Terminal application.

Go ahead and run the above command to enable auto start and then type reboot and remove the USB device.

The last thing to do of course is to actually test this out on your Mac Mini. Go ahead and let the system boot up and then yank the power cord and then give it a few seconds before plugging it back in. You should see the Mac Mini automatically power back on after you plug the power back in.

VMware vSphere can virtualize itself + 64-bit nested guests

Running VMware ESXi inside a virtual machine is a great way to experiment with different configurations and features without building out a whole lab full of hardware and storage. Virtualization enthusiasts everywhere have benefited from the ability to run ESXi on ESXi, first introduced with the vSphere 4 release.

VMware vSphere 5 makes it easier than ever to virtualize hypervisor hosts. With new capabilities to run nested 64-bit guests and take snapshots of virtual ESXi VMs, the sky is the limit for your cloud infrastructure development lab. Heck, you can even run Hyper-V on top of vSphere 5 — not that you’d want to.

Physical Host Setup

The physical host running VMware ESXi 5 requires just a few configuration changes; here is a guide:

• Install VMware ESXi 5 on a physical host and configure networking, storage, and other aspects as needed
• Configure a vSwitch and/or Port Group to have Promiscuous Mode enabled
• Create a second Port Group named “Trunk” with VLAN ID All (4095) if you want to use VLANs on virtual hypervisors
• Log in to Tech Support Mode (iLO or ssh) and make the following tweak to enable nested 64-bit guests

  echo 'vhv.allow = "TRUE"' >> /etc/vmware/config

Virtual VMware ESXi Machine (vESXi) Creation

For various reasons, it’s not feasible to clone virtual ESXi VMs. As an alternative, create a fully-configured shell VM to use as a template — it can be cloned before ESXi is installed.

Create a new VM with the following guidance:

• Guest OS: Linux / Red Hat Enterprise Linux 5 (64-bit)
• 2 virtual sockets, 2+ GB RAM
• 4 NICs — connect NIC 1 to the management network and the rest to the “Trunk” network:
• Thin provisioned virtual disks work fine
• Finish creating the VM, then edit the following settings
  • Options/General Options: change Guest Operating System to Other – VMware ESXi 5.x
  • CPU/MMU Virtualization: Use Intel VT … EPT… ( bottom radio button)
• Don’t power this VM on — keep it to act as a template
• Clone and install VMware ESXi via ISO image or PXE boot
• Add to vCenter and configure virtual ESXi hosts for action

Nested 64-bit Guests

With the release of VMware vSphere 5, nested guests can be 64-bit operating systems. Just be sure to make the change to /etc/vmware/config on the physical host as indicated above.

Nested guests can be migrated with vMotion between virtual or physical VMware ESXi hosts; this requires a vMotion network and shared storage.

Nested Hyper-V Virtual Machines

It is possible to run other hypervisors as vSphere virtual machines, and even power on nested VMs. Here you can see Hyper-V running a CentOS virtual machine — all on VMware ESXi. Talk about disrupting the space-time continuum!

A couple of extra tweaks are needed to enable this, and performance is not great. Nevertheless, an amazing feat of engineering from VMware!
Do the following to enable Hyper-V on VMware ESXi:

• Add hypervisor.cpuid.v0 = FALSE to the VM configuration

• Add —-:—-:—-:—-:—-:—-:–h-:—- to the CPU mask for Level 1 ECX (Intel)

How to Access vSphere Remote Console Using vSphere & VMRC API

We can provide access to the remote console of a virtual machine in a vSphere environment to your end users. This can be accomplished by leveraging both the vSphere and VMRC (Virtual Machine Remote Console) APIs and can be useful if you are building a custom portal for users to access their virtual machines. To use the VMRC API, you can download the latest VMRC 5.1 SDK which provides the following:

The VMRC SDK allows you to use a Web-based application to connect to a vCenter- or vCloud Director-managed virtual machine and access that virtual machine’s console in a browser window. You can interact with the virtual machine console input and screen. You can also use the VMRC SDK to manage virtual and physical device connections on a vCenter-managed virtual machine.

The VMRC SDK includes documentation to the API as well as a sample webpage implementing some basic functionality of the VMRC API. I recently received a question on how to get started with the sample as it was not completely intuitive and thought I take you through the required steps to get the sample working.

Step 1 - Download the VMRC 5.1 SDK and extract the contents to your local desktop.

Step 2 - Open the vmrc-embed-example.html using a web browser located in the docs folder.

Note: In my example, I uploaded both the javascript and html file to a web server and accessed the sample by connecting to the server instead of running it locally on my desktop. This was to show how users could access the custom portal using the VMRC SDK.

Step 3 - At the top of the page where it says "VMRC Modes", make "MKS" is selected in the drop down box and click on the "+" icon to add. Then go ahead and click on the "Start" button to start a VMRC instance and ensure you see a success message on the right hand side of the console box.

Step 4 - To authenticate to VMRC, you will need a session ticket which will be obtained through the use of the vSphere API using the acquireCloneTicket() method provided by the SessionManager managed object. In this example, we will be using the vSphere MOB to quickly retrieve our session ticket, but in a real implementation, you would programamtically retrieve the session ticket along with few othe pieces of information to connect to the VMRC. Open up a new tab in your web browser and connect to the following URL:

https://reflex.primp-industries.com/mob/?moid=SessionManager&method=acquireCloneTicket

Note: Make sure you substitute in your vCenter Server IP Address/Hostname

Once you have authenticated, go ahead and click on the "Invoke Method" which should generate a session ticket:

Step 5 - Copy the session ticket string and go back to our VMRC sample page. We will now need to fill out the following sections before we can access the remote console of a virtual machine:

• Hostname (IP Address/Hostname of your vCenter Server)
• Allow SSL Validation Errors (Check this if you are using self signed SSL certificates)
• Ticket (Paste the session ticket from the previous step here)
• VM ID (This is the MoRef ID of the VM you wish to connect to the remote console)

Once you have filled out the minimum required fields, go ahead and click on the "Connect" button and if everything was successful, you should now see the remote console of the virtual machine you selected.

Downgrade Forest Functional level or Domain Functional Level in Server 2012

Today i will share that How we can downgrade the Forest Functional level or Domain Functional level for server 2008 or 2012 .

It is there that revert to the lower FFL or DFL is not possible but in server 2008 and 2012 it is possible.
(FFL- forest functional level) (DFL- domain functional level)

Here in my scenario i have server 2012 with forest functional level and domain functional level "windows server 2012", as you can see below the FF.

dd
As you can see the FFL of the domain server12.com is "windows server 2012 released candidate"
and if you want to add ADC with server 2008 , it will not allow to do so and to add that you need to downgrade the FFL and DFL to 2008.

Now i will use the power shell Active directory module to do this activity.You need to run the following power shell command

Set-ADForestMode server12.com -ForestMode Windows2008Forest

It will ask you if you are sure to perform this task ,press Y as shown below

You can see in the above snapshot that the downgrade is done and even when you will see the the FFL level from the domains and trust it will show you the current FFL is windows server 2008.

Now you need to downgrade the DFL to server 2008.

Below you can see that the server12.com domain has DFL as windows server 2012 .

Now you can follow the same procedure to downgrade the DFL as shown below.You have to run the following command.

Set-ADDomainMode server12.com -DomainMode windows2008domain

Now you will see both of your FFL and DFL are now on Windows server 2008.

How to Analyze Windows Memory Dump

Welcome back guys :)

Today here I am going to explain about how to analyze the memory dump.

As in my previous post I have describe to you: How to create memory dump and where you can find that dump file.

Let’s say you have configured a memory dump on a server and server got unexpected down with BSOD.

Now you need to go to the default location i.e. %SystemRoot%\Memory.dmp for the memory dump file.

You can find the memory.dmp as below.

This memory.dmp file is the dump file for complete dump. Now you need to analyze it ;)

There are bundle of software in the market for the same, some are free of cost and some are licensed.
Microsoft has tool that we can use to analyze the memory dump on Microsoft platforms called as windows debugger (dbg_x86_6.11.1.404). You can download it from here.

After downloading the debugger you need to do little bit configuration before analyzing the dump.

Now you need to configure the symbol path for it. Before doing it just do the following

1.      Create a folder named “symbols” without quotes in the root drive.
2.      Open the Windbg and then go to FileàSymbol file path.
3.     Set the path to “SRV*c:\symbols*http://msdl.microsoft.com/download/symbols “without quotes.

Symbol Path:- Symbol files provide a footprint of the functions that are contained in executable files and dynamic-link libraries (DLLs).Additionally, symbol files can present a roadmap of the function calls that lead to the point of failure.

Now the configuration is done, now you need to open the dump file in the debugger.

Now you need to open dump file , To do this goto File-->Open Crash Dump

After you open the Memory.dmp, it will make some calculation and load the symbols as below.

Now you need to write the command "!analyze -v " to get the details

After this command you will get the details about the reason behind the Crash :)

The reason for the crash was fltmgr.sys file.

As you all are System Admins so you must have good google search skills,Now just google it and get the reason for the same.

I have found the reason and the there is some Hotfix from Microsoft for this error.

http://support.microsoft.com/kb/955087

This is How we can Analyze the dump.

How to enable memory dump on a windows server

It is very often we see the blue screen on the Microsoft based OS.Basically we called this blue screen as 
Blue Screen Of Death (BSOD).

I have asked the question "what is BSOD" from many guys during the interviews but usually they replied
that it happened due to RAM or HDD failure, they simply reply that in this case they will replace either RAM or HDD to fix this issue on the server. 

So today i will give a idea about this BSOD and how to analyze this issue on windows platform.

->What is BSOD ?
->The Blue Screen of Death , displayed by the Microsoft Windows family of operating systems upon encountering a critical error,of a non-recoverable nature, that causes the system to crash.Stop errors are hardware or driver related, causing the computer to stop responding in order to prevent damage to the hardware or data.

->Type of memory dump ?
->There are three type of dumps created

1. Complete Memory Dump
2. Kernal Memory Dump
3. Small Memory Dump

1. Complete Memory Dump:-A Complete Memory Dump is the largest kernel-mode dump file. This file contains all the physical and virtual memory for the machine at the time of the fault.If you select the complete memory dump option, you must have a paging file on the boot volume The Complete Memory Dump file is written to %SystemRoot%\Memory.dmp by default.The Complete memory dump option is not available on computers that are running a 32-bit operating system and that having 2 gigabytes (GB) or more of RAM (by default).

2. Kernal Memory Dump:  A Kernel Memory Dump contains all the memory in use by the kernel at the time of the crash.The dump file will be around one-third the size of the physical memory on the system. This dump will not include unallocated memory or any memory allocated to applications. It only includes memory allocated to Windows kernel.The Kernel Memory Dump file is written to %SystemRoot%\Memory.dmp by (default)

3. Small Memory Dump:- A Small Memory Dump is much smaller than the other two crash dump files. It is exactly 64 KB in size (128KB on 64-bit systems) .This kind of dump file can be useful when space is greatly limited. However, it contains very less information for the reason of the crash.

                              How to enable memory dump on a windows server

Here i am going to configure the memory dump on Win-7/server 2008

1. Right click on my computer and click on properties then click on 2. Advance system setting option on left side ,then click on 3. Advance tab, Now click on 4. setting under Startup and recovery.Below are the screenshot

Same you can configure from the registery as well from the location as mentioned below

HKLM\System\CurrentControlSet\Control\CrashControl
All the things that you can configure via GUI can be configured via registery as well.

• Write an event to the System Log checkbox = LogEvent
• Automatically Restart checkbox = AutoReboot
• Write Debugging Information drop-down = CrashDumpEnabled
• Dump File text box = DumpFile
• Overwrite any existing file checkbox = Overwrite 

                              How to Crash the server manually using keyboard

Now you have configured the memory dump on the server and now you can check as well if it is creating the memory dump file on the server or not.Also when you need to create memory dump file manually after a crash ,do the following to configure the same.

Using PS/2 keyboard :-


1. Start Registry Editor.
2. Locate the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

3. On the Edit menu, click Add Value, and then add the following registry entry:

Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1

4. Exit Registry Editor, and then restart the computer.


 Using USB keyboad:

1. Start Registry Editor.
2. Locate the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters

3. Make sure that the following registry entry is enabled:

Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1

4. Exit Registry Editor.

If You can generate a system memory dump by holding down the right CTRL key and pressing the SCROLL LOCK key twice. (Ctrl+Scroll lock twice)

Note: Pressing left CTRL key does not generate the system memory dump.



Will come with new Blog shortly on How to Analyze the memory dump....... ;)

Set Up Windows 2003 R2 NFS Server for VMware ESXi Backups

Generally my preference is to use Linux as an NFS server.  On the internet you will see frequent reference to the belief that NFS works better on Linux/UNIX.  Recently I decided to try and set up NFS services on Windows to see how well it would perform.  In this tutorial I will set up Services for UNIX 3.5 on a Windows 2003 R2 server and configure it using the User Name Mapping service to allow a VMware ESXi to use it as a datastore for VMs or backups via non-anonymous connections.

First off grab the Windows Services for UNIX (SFU) installation files here.  Extract the files from the download file and run the setup.

Click Next.

Select Custom Installation and click Next.

Under NFS select Client for NFS and Server for NFS for installation.  Although in the image I have not unselected them you can unselect all the other UNIX utilities.

Scroll down and under Authentication tools for NFS select User Name Mapping to be installed.  Again this and Client/Server NFS should be the only three options that need to be installed.  Click Next.

Click Next.

Select Local Mapping Server, and select Password and group files.  Click Next.

Now go to Windows Explorer and create a directory to store the password and group lists from the VMware ESXi host.

In this example I will create a directory C:\SFU for the password/group files.  Unfortunately SFU will install the program files into this directory and will delete the password/group files, so after the install is completed you’ll need to recopy the files here.  They do need to be placed here initially so the installer will find them.  Or obviously you could use a different directory for the password/group files.

Enter the path for the password and group list files, click Next.

Click Next.  Allow the install to complete.

Create User Name Mapping

Go to Start > Administrative Tools > Services for UNIX Administration.

In the left pane go to User Name Mapping, then in the middle top click Maps.

Uncheck Simple maps.  Then under Advanced maps click Show User Maps.

Now click the List Windows Users and List UNIX Users buttons.

Select a Windows user and UNIX user to map each other to, I just mapped the UNIX/ESXi root user to Administrator.  Now click the Add button.

Click OK.

Click OK.

You will now see the new user mapping below.  Optionally you could create a group mapping as well, but I found that it isn’t necessary.

In the upper right click the Apply button.  Then close the window.

Now go out to a directory that you’d like to make available via NFS, right click it and select Properties.

Click the NFS Sharing tab in the dialog, then select Share this folder.  Now click the Permissions button.

Change the Type of access to Read-Write, and check Allow root access.  This is not the most secure setup, so you may want to limit what is available in this directory.  Click OK.

Click OK.

Now go into the Services MMC, we now need to restart the User Name Mapping service.

NFS requires a variety of network ports to be made available, so for now I will disable the Windows firewall.  Obviously this is not recommended for production environments.

Click Properties.

Click Advanced.

Click Settings.

Select Off, then click OK.

Connect VMware ESXi to NFS Datastore

Go into the vSphere Client.  Select the ESXi host, then in the main pane click Configuration, then under Hardware select Storage.

In the Datastore section click Add Storage.

Choose Network File System and click Next.

Enter the NFS server hostname/IP address, the name of the nfs folder share name with a preceding /, and a datastore name and click Next.

If all goes well the NFS share from Windows will now show up under datastores!  You now have a place for your virtual machine backups.  I have actually found that read/write performance from Linux and ESXi clients connecting to the Windows NFS server if very good.  Good luck!