Posts Tagged ‘vSphere4’


Full Error:

File <unspecified filename> is larger than the maximum size supported by datastore ‘<unspecified datastore>

I’ve been coming up against this issue for the last few days whilst installing some backup software for one of our customers. It’s highly frustrating and I couldn’t figure out why this was even happening. The data stores that this particular VM was running on had plenty of free disk space, and none of the disks exceeded the file size maximum for the block size on those disks.

What I didn’t know was, quite simply, that a VM cannot snapshot if it’s configuration file is stored on a data store with a smaller block size than one of it’s virtual hard disks. Now, I presume, that this is only the case if the virtual disk size is larger than the supported size of a file on the configuration files data store.

So, if you come accross this problem, just storage vMotion the configuration file to a data store with a larger block size, or at least to a datastore with the same size block size as your largest virtual disks’ data store. Run another snapshot, and “Hey Presto!” it should snapshot correctly.



Hopefully you’ve all read Part One of this series, where I provide examples of gathering information from vCenter mainly for VM’s in order to recreate your environment from scratch, just in case you have a major vCenter database corruption or the like. If you have, sorry part two has taken so long!
Part Two will show how to export information regarding your ESX(i) hosts, including networking information, so that this part of your setup is also easy to recreate. I should note here, that I’ll be trying to export VSS information, as well as Service Console and VM Kernel port configuration, and get this all exported into CSV files.
So… Here goes…!
Exporting physcial NIC info for the vDS switch
This is a pretty simple script that uses the get-vmhostpnic function from the Distributed Switch module in I mentioned in part one (Thanks again Luc Dekens :¬)).
import-module distributedswitch

write-host "Getting vDS pNIC Info"

$vdshostfilename = "C:\vdshostinfo.csv"
$pnics = get-cluster "<em>ClusterName</em>" | get-vmhost | get-vmhostpnic
foreach ($pnic in $pnics) {
if ($pnic.Switch -eq "<em>dVS-Name</em>") {
$strpnic = $strpnic + $pnic.pnic + "," + $pnic.VMhost + "," + $pnic.Switch + "`n"
}
}
#Writes to CSV file
out-file -filepath $vdshostfilename -inputobject $strpnic -encoding ASCII

Simply change “ClusterName” to match that of your cluster, and change “dVS-Name” to match that of your dVS (vDS – whichever). Then the info exported will contain the physical nic info for your distributed switch.

Next it’s time for simply getting a list of hosts in the cluster, I know, it’s nothing major, but at least it’s in a CSV I can import later, and it makes life much easier!!!

$cluster="ClusterName"
$hostfilename = "c:\filename.csv"
write-host "Getting Host List"
$hosts = get-cluster $cluster | get-vmhost
foreach ($vmhost in $hosts) {
$outhost = $outhost + $vmhost.Name + "`n"
}

out-file -filepath $hostfilename -inputobject $outhost -encoding ASCII

Simply put, gather a list of hosts in the cluster called “ClusterName” and output their names to “c:\filename.csv”

OK, so now that we have that info, all I need to gather is a list of Standard Switches and their port groups, including IP information to make life easy… So, here goes:

$vssoutfile = "vssoutfile.csv"
$cluster = "Cluster Name"
$vmhosts = get-cluster $cluster | get-vmhost

$vssout = "Host Name, VSS Name, VSS Pnic, VSS PG" + "`n"
foreach ($vmhost in $vmhosts) {
$vmhostname = $vmhost.name
$switches = get-virtualswitch $vmhost
foreach ($switch in $switches) {
$vssname = $switch.name
$Nic = $switch.nic
$pgs = get-virtualportgroup -virtualswitch $switch
foreach ($pg in $pgs) {
$pgname = $pg.name
$vssout = $vssout + "$vmhostname" + "," + `
        "$vssname" + "," + "$Nic" + "," + `
        "$pgName" + "`n"
}
}
}

out-file -filepath $vssoutfile -inputobject $vssout -encoding ASCII
Now we just need the host IP’s. At the moment, I can find this info for VM Kernel ports on ESX hosts, but I can get service console information, and the vmkernel IP in ESXi hosts (it’s pulled from the same PowerCLI script, so that’s this one here:

$hostipoutfile = "hostip.csv"
$cluster = "Cluster Name"
$output = "Host Name" + "," + "IP Addresses" + "`n"

$vmhosts = get-cluster $cluster | get-vmhost
foreach ($vmhost in $vmhosts) {
$vmhostname = $vmhost.name
$ips = Get-VMHost $vmhostname | `
     Select @{N="ConsoleIP";E={(Get-VMHostNetwork $_).VirtualNic | `
     ForEach{$_.IP}}}
$ipaddrs = $ips.ConsoleIP
$output = $output + "$vmhostname" + "," + "$ipaddrs" + "`n"
}

out-file -filepath $hostipoutfile -inputobject $output -encoding ASCII

Now, I’m slowly working on this project in my spare time at work (it’s actually for work but not as important as everything else I’m doing!), so part 3 is probably going to be some time away, and that’ll show you how to import all this info back into vCenter to reconfigure your hosts… bear with me, I’ll get this written :)



I came across this one earlier today, and I must say, I was surprised that this option is available to users without administrative rights to vCenter/ESX or the Virtual Machine… but it would appear that the VMTools application that appears by default in the notification area for any user logged onto the virtual machine allows ANY user to perform any actions within that app… including disconnecting devices such as IDE controllers, but more importantly for TS/XenApp servers… the network card.

There are simple ways to block this though, but it takes some effort, especially if you have lots of TS/XenApp servers!

So, there are 3 things you can do to help:

1. Hide the VMware Tools icon in the system tray.
2. Restrict access to the Control Panel applet.
3. Restrict access to the VMWareTray.exe application

I’ll talk you through each one:

Hiding the VMware Tools icon:

This unfortunately isn’t as simple as opening the tools application, and unchecking the “Show VMware Tools in the taskbar” box… this action only applies to the user performing it… not for the whole system, so, we have to manually edit the registry to get this to take effect for all users… Now, don’t forget, editing the registry without knowing what you’re doing can be very dangerous, always backup your system first…

1. Open regedit.exe
2. Browse to the following key:

HKEY_LOCAL_MACHINESoftwareVMware, Inc.VMware Tools

3. Edit the “ShowTray” subkey and change the value to a zero, click OK.

When you log back into the server, the VMware Tools icon shouldn’t display in the notification area.

Restrict Access to the Control Panel Applet:

You have several options here, this can be done as a local policy (meaning no one including the administrator can access the applet) or via a Group Policy which can be filtered to specific users, these instructions are for Windows 2008 R2, but will be very similar for Server 2003 and Server 2008 R1.

1. Open an MMC and either add the Local Policy or Group Policy Management consoles.
2. If using a Group Policy create a new policy and link it to the OU as required.
3. Browse to the following area in the policy:

User ConfigurationAdministrative TemplatesControl Panel

4. Open the “Hide Specified Control Panel items” setting.
5. Click “Enabled”, then click “Show”.
6. In the “Value” field type “VMware Tools” (no quotes). Click OK.
7. Click OK again and close the policy.
8. Reboot the server to test that the Applet is no longer accessible.

Restrict access to the executable:

Even with all of this, the user could (if you don’t restrict access to local disks) find the executable and run it, which will open the GUI for VMware Tools… shame really! So, the other options are to set the file permissions to block the user’s group from accessing these files, or at least allow administrators, domain admins, etc. and the user account that runs the VMware Tools service, and block all other users. Personally, I always hide the local disk from the users, so this part isn’t an issue for me, but there are admins out there that perhaps aren’t as “strict” as me!

And that’s it, one blocked application and no users disconnecting NIC’s and CD ROM’s etc. whilst the server is in use!