I recently installed Windows 2008R2 Server Core on a test vm to host DNS. Usually after I create a vm I install VMware Tools, but with no GUI in Core this has to be run via command line, syntax below:
msiexec.exe /i %CD_DRIVE%:”VMware Tools.msi” /qn
(/i = package options; qn =no UI)
You need to mount the VMware tools package prior to running the above command, i.e. select Install/Upgrade VMware Tools from the guest menu.
I was sitting in my living room yesterday evening with iPhone in hand ready to log onto one of my virtual test servers to perform a few changes. Usually this wouldn’t be a problem as I recently purchased the WYSE client app for the iPhone, and most tasks can be performed quite easily (well worth the £8.99). I completely forgot that I had actually shut this vm down a few days ago to make room for a new build – when I say room I really mean that I needed the physical RAM availability!
Then I got thinking, wouldn’t it be great to have an app that could manage ESX and VCenter. All to save me getting up and walking the 2m to grab the laptop off of the sideboard!
I had a quick search around and stumbled across the VManage app for a reasonable £1.79. I read the reviews etc and decided that although some users were having issues with various iOS releases or different VCenter flavours, I’d still give it a go. Well I should probably have listened to the reviews and saved my cash. Although the app is filled with promise the delivery leaves a lot to be desired. After numerous failed connection attempts (to ESX 4.1 and VCenter 4.1 – although admittedly not on the supported list) and ESX 4.0 I submitted a bug report to the developer and continued my search. (I should also mention that I’m running iOS 4.0 which I found also to be unsupported..!)
Now I don’t think I’ve had my head in the sand for the last year or so, but I stumbled across a VMware Beta product called VCenter Mobile and in all honesty I’ve never heard about this project. So I download the Beta appliance to have a better look.
The appliance is in OVF format so the import into VCenter takes just a few minutes. After the install you need to log onto the console to configure the network settings (DHCP enabled by default). Once the initial config has been set you can then navigate to https://servername:5480 to make any other network related alterations. The default username/password is set as root/vmware. Obviously the password should be altered.
The appliance can be accessed from http://servername/vim where it acts as a proxy for the IP/hostname of your VC or ESX server you wish to access. These entries are saved in a list view for later use, very handy.
I’ve tested this on ESX4.0 and VC4.1, all functioning with no issues so far. I’ve taken a few screenshots to show as examples, including general views (ESX & VC), VMotion migrations options etc.
Best of all it’s web based (running on Apache Tomcat) so can be accessed from any mobile device with a browser, and it’s free! This will be one Beta program I’m definitely keeping up to date with from now on (that’s if it isn’t dropped for a more Apple friendly option – view here).
I recently setup a lab that hosted a Windows 2003 R2 32-bit server with VMware VCenter 4.0U2 using a local SQL Express database. This was used for a home testing environment so I wasn’t too worried about any data loss that may occur. When VMware VCenter 4.1 was released I thought an upgrade was a must! As you’re most probably well aware VCenter 4.1 requires a 64-bit host so I setup second system that ran Windows 2008 R2 in preparation for the migration.
Before we begin this process I should point your attention to a document that I stumbled across when searching for various answers. It basically highlights a few errors that could occur if you’re performing this migration from a VC that has already been upgraded in some shape or form. Well worth checking out beforehand to see if it affects your setup.
VMware bundle a tool named datamigration with the VCenter 4.1 media that aids in circumstances such as this, i.e. migration of VC supported by SQL Express from a 32-bit host to a 64-bit host. The steps I performed are documented below.
1. Extract the datamigration.zip tool from the root of the VCenter media onto the root of your system drive (most likely C:)
2. Stop the following services:
3. Open a command prompt window and change the working directory to C:datamigration
4. Run the backup.bat script
5. Once the script has executed you’ll need to copy the newly populated datamigration folder to the root of the new server.
6. On the new server change to the working directory C:datamigration
7. Run the install.bat script
8. Follow the instructions for VCenter installation (you’ll need the VCenter media mounted)
You’ll also need to backup the SSL certificates. These can be found at:
Microsoft Windows 2003:
%ALLUSERSPROFILE%Application DataVMwareVMware VirtualCenter
Microsoft Windows 2008 Server:
%ALLUSERSPROFILE%VMWareVMware VirtualCenter
I found that although the above information was readily available on the VMware website, the latter steps were less clear. I came to the conclusion, with the aid of a VMware community posting or two, that the following seemed to be the recommended solution.
9. Remove the old VCenter from the domain
10. Shut down the old VCenter server
11. Issue the new VCenter server with the IP address that was previously used on the old server
12. Rename the new VCenter server to that of the old server (reboot)
13. Restore the SSL keys – as simple as to copy/paste from old location to new
NB. The migration of the VCenter server that uses a remote SQL database is very similar to this process, but you don’t need to bother with the datamigration tool (for obvious reasons), instead you’ll need to create the relevant ODBC connections.
After a final reboot I found that I couldn’t connect to the VCenter server using the vSphere client (I’d already updated to the latest version). I logged onto the server, opened eventvwr and found numerous events stating that the transaction log for database ***VCDB_NAME*** was full. I thought the easiest way to overcome this (remembering this is a test environment) was to install SQL Express Management Studio and alter the recovery type of this database to Simple. This seemed to do the trick and I’m now happily working away on a test environment hosted by VCenter 4.1.
I previously blogged about using WSAM on Juniper SAs to redirect traffic to a VMware View server. As mentioned, resource profiles require less configuration than the WSAM method. They’re also very useful if your company utilises other OS platforms such as Mac OSX or a variant of Linux, or if you just want a more fluid sign on due to the SSO (single sign on) capability.
You have to be mindful that AD (or LDAP) authentication needs to be used as either a primary or secondary authentication method.
Basic configuration as per below:
1) Select resource profiles > virtual desktops > new profile and enter the following details
a. Select the type of profile required (VMware View or Citrix XenDesktop)
b. Enter a meaningful name and description (if required)
c. Enter the server name or IP along with port number i.e. myview.mynetwork.local:443
d. Tick the use SSL box (especially if using View)
e. If the Juniper realm is set to use AD as its primary authentication method you’ll need to set the username field as <USERNAME> and the password field as <PASSWORD>
OR
If the Juniper realm is set to use AD as its secondary authentication method you’ll need to set the password as <PASSWORD@SECAUTHSERVER>
f. Enter the domain name
2) You’ll need to assign the virtual desktop profile to a role
3) Assign the profile a bookmark name
If a successful connection has been made to the View server you’ll notice that in a yellow box at the top of the page under user roles > **role name** > virtual desktop > sessions > **bookmark name**;
Retrieved Desktop list from server myview.mynetwork.local:443 successfully
If the connection was unsuccessful you’ll notice the error message below;
Warning: Unable to retrieve desktop list, please re-check the server configuration in the Profile
Error: [NOT_AUTHENTICATED] []
If you can’t get the connection working correctly from the Juniper SA to the VMware View server you can enter credentials manually for testing, as below:
1) Open resource profiles > virtual desktop > **profile name**
2) Enter the AD account username of a user that has access to the VMware View Portal
3) Select the password option and enter the AD password associated with the username previously entered
4) Enter the domain name
5) Select user roles > **role name** > virtual desktop > sessions > **bookmark name** and open the bookmark
6) Under the authentication SSO heading enter the credentials of the test user. Make sure you enter in domainusername format
7) Save changes and then open the bookmark name from (user roles > **role name** > virtual desktop > sessions > **bookmark name**) and you should see a successful connection message
This can obviously also be tested from actually logging into the Juniper device
I’ve been playing around with a Juniper SA appliance at home of recent times and have found the device packed full of features. Within this entry I’ll be concentrating on WSAM policies as these allow seamless integration with VMware View (tested with VDM 2.1, View 3 and View 4).
There are two methods that can be used when assigning a VMware View profile to the Juniper SA’s. If you have a newer (or updated firmware) SA model you’ll notice that there’s an option to create a Virtual Desktop Resource Profile. I’m going to show you an alternative, but just as useful, method.
The steps below will create a WSAM policy that will basically forward RDP traffic to the virtual desktops on the backend.
1) Create a new web application (resource profile > web > custom)
a. Enter a unique name for the profile
b. Enter the URL of the View server in the Base URL field, i.e. https://myview.mynetwork.local
c. Tick Autopolicy: Web Access Control – select or enter the URL of the view server (as previously defined) and set the action to allow
d. Tick Autopolicy: Rewriting Options and select No rewriting (use WSAM)
2) Assign the web application to a role (resource profiles > *select profile* > roles)
a. Select from the available roles
3) Create a new bookmark (resource profiles > *select profile* > bookmarks)
a. Enter a unique name
b. The URL field should be populated with the View server FQDN – add /index.jsp
c. I prefer the bookmark to open in a new window and to hide the address bar – select these options if you wish to do so
4) Create a new SAM application (roles > *select role* > SAM > applications > add > custom)
a. Enter a unique name for the profile
b. Enter the filename wsnm.exe
c. Enter the path as: C:Program FilesVMwareVMware ViewClientbin
5) Create another new SAM application (roles > *select role* > SAM > applications > add > custom)
a. Enter a unique name for the profile
b. Enter the filename wswc.exe
c. Enter the path as: C:Program FilesVMwareVMware ViewClientbin
The above assumes that VMware View has been installed into the default directory (this path will need altering if using with VDM 2.x)
6) Enable Windows SAM (WSAM) (roles > *select role* > SAM > applications > options) and check the following settings:
a. Windows SAM
b. Auto-launch Secure Application manager
c. Auto-upgrade Secure Application Manager
That’s all there is to it. WSAM and JSAM can be used for many more things than just redirecting View traffic. Even if the newer ‘pre-created’ policies are a little simpler to implement, it’s always nice to have an understanding of the capabilities the Juniper SA series has to offer.
These steps will show you how to create an NFS share on a Qnap NAS that can then be allocated as storage to an ESX server
1. Disable write cache (for EXT4) (System Administration > Hardware)
2. Enable NFS (Network Services > NFS Service)
3. Create a new share with the following properties
• Hide folder = YES
• Lock file (oplocks) = NO
4. Select the NFS access control option from the share just created. The access rights should be set with the following properties
• Access Right = No Limit (i.e. read and write)
• Allowed IP or domain name (see below)
i. * = allow access to ALL systems
OR
ii. Enter an IP or range of IPs allowed access to the NFS share – these can be separated by using a comma
NB the IP addresses used here specifically relate to the VMkernel port not the service console etc.
To add the NFS share to the ESX server configuration perform the following steps
5. Log into the VI Client, select ESX server > Configuration > Storage > Add Storage
6. Choose the Network File System option
7. Enter the details as requested, i.e. the Qnap IP address and shared folder path (the option to mount the share as read only is also available)
8. The NFS share will now appear in the list of available datastores
N.B to verify everything is working as per expected you can copy a file into the NFS share via the VI Client, and then use your system to navigate to the hidden share via serveriphidden_share_name.
I recently wanted to rename a vmdk on an ESX4 box. This wasn’t part of a cluster and there were no VC’s in the environment (hence the Storage vMotion trick couldn’t be used). The easiest and safest way to perform the rename is to SSH to the ESX box and use the following command:
vmkfstools -E
/vmfs/volumes/DATASTORE_NAME/VIRTUAL_MACHINE_FOLDER/VDMK_TO_RENAME.vmdk
/vmfs/volumes/DATASTORE_NAME/VIRTUAL_MACHINE_FOLDER/NEW_VMDK_NAME.vmdk
There are many other switches that can be used with the vmkfstools command. One of the more useful ones is -i used for cloning a vmdk. The -d switch can also be added to specify the type of disk (thick, thin, RDM etc).
The script below basically checks that a certain snapshot is in place before deleting an old snapshot.
In the case of this example, the script is checking if the snapshot ‘week 2 scheduled snapshot example-vm-001’ exists and if so deletes the previous snapshot named ‘week 1 scheduled snapshot example-vm-001’. If the check had failed and found that the snapshot didn’t exist the script would end.
C:WINDOWSsystem32windowspowershellv1.0powershell.exe -PSConsoleFile “C:Program FilesVMwareInfrastructureVIToolkitForWindowsvim.psc1” -NoExit -command “& Connect-VIServer -server localhost; if(get-snapshot -vm example-vm-001 -name ‘week 2 scheduled snapshot example-vm-001’) {remove-snapshot (get-snapshot -vm example-vm-001 -name ‘week 1 scheduled snapshot example-vm-001’) -confirm:$false}
Script breakdown:
1) C:WINDOWSsystem32windowspowershellv1.0powershell.exe -PSConsoleFile “C:Program FilesVMwareInfrastructureVIToolkitForWindowsvim.psc1” – Opens the vim.ps1 PowerShell script
2) “& Connect-VIServer -server localhost – Connects to the VC
3) get-snapshot -vm example-vm-001 -name ‘week 2 scheduled snapshot example-vm-001’) – Make sure this snapshot exists
4) {remove-snapshot (get-snapshot -vm example-vm-001 -name ‘week 1 scheduled snapshot example-vm-001’) – Delete snapshot named ‘week 1 scheduled snapshot example-vm-001’
5) confirm:$false – Don’t prompt
This can be used along with the scheduled tasks (to create snapshots) on a daily or even weekly basis. Particularly useful if you want to make sure that there’s always 1 recent snapshot available for a particular virtual machine.
I recently stumbled across RVTools. This is a freeware app that utilises the .NET framework and the VI SDK. Its main purpose is to probe ESX hosts, VC and virtual machines for stats and useful information. I’ve been using it on vSphere, but according to the developer it’s also compatible with VC 2.5, ESX3, ESX3i and ESX4i.
It’s a handy tool for many purposes, but I find it particularly useful for displaying info on the virtual machines where vmtools is out-dated (see screenshot below). The other feature I find myself using quite a bit is viewing the storage table. If you have many LUNs you’ll find this very useful as the fields can be quickly sorted to show capacity remaining (%, MB), and the number of live vms currently running on each LUN.
An added extra is the ability to export (csv) the data, so you can easily create a timeline/plan of storage needs and such like.
And of course the best bit, it’s free!
Test bed details
Qnap firmware version: 3.3.1 Build 0720T
vSphere: 4.1.0 build 260247
I recently purchased a Qnap TS-210 as I wanted to use the iSCSI feature with my home VMware setup. Installation of the device was straight forward. As soon as a hard disk is installed and the unit is powered on, you can use the bundled software to search for the NAS. You’re then taken through a wizard to set such things as IP, time zone, set admin credentials and update the firmware.
This was a pretty simple process and involved following the steps as below:
1) If running virtual machines on the device (as we intend to do) you’re advised to disable the write cache – This is done by deselecting the write cache check box under the System Administration > Hardware menu.
2) Select Disk Management > iSCSI and select the check box ‘Enable iSCSI Target Service’.
3) Again, under the Disk Management > iSCSI menu select the Target Management tab. A wizard will then begin asking which of the following you wish to setup:
As this is a new install you’ll need to create both an iSCSI Target and LUN so the 1st option should be selected.
4) You’ll be asked to provide a Target name and Target Alias. The name provided will form part of the iSCSI Target IQN i.e. iqn.2004-04.com.qnap:ts-210:iscsi.NAMEGIVEN.f02n6h
5) Now you can choose whether you wish to use CHAP authentication, and if so enter the credentials to use.
6) The final selection window will ask for the following details:
7) Finally you’ll be prompted to confirm the previous selections before clicking finish. If you have opted for the Instant Allocation LUN there will be a figure in % displaying the amount of processing that has completed.
NB. If a large LUN is being created this processing time can take quite a while.
1) Use the VMware vSphere/Infrastructure client to connect to the VC or an individual ESX box.
2) A VMkernel port will need to be setup before configuring the software iSCSI initiator. This will obviously have to be on the same segment as the Qnap.
3) The next step is to configure the software iSCSI initiator (configuration > storage adaptors > iSCSI software adaptor) then select properties > configure > click the enable check box and you’ll notice the iSCSI name automatically populates.
4) If you previously setup CHAP authentication on the Qnap you can enter those credentials under the general window.
5) To add the Qnap iSCSI target you’ll need to add (copy/paste) the Qnap iqn and Qnap server IP address under the ‘Add static target server’ tab. Click OK and then you’ll be prompted to rescan the HBA.
6) Finally select Storage > Add Storage > Disk/LUN and you’ll then see the LUN as created on the Qnap. Continue with the adding storage process as you would normally, i.e. give the LUN a name, select the block size and that’s it.
There you have it; VMware ESX using a LUN hosted on a sub £200 NAS. Very very neat!
