PowerCLI: Reset CD-drives using PowerShell

As most of you know and probably experienced from time to time: when a Virtual Machine’s CD-drive is connected to an ISO-file on one of your Datastores or even connected to the physical drive of your ESX-host the migration due VMotion of a Virtual Machine will not work.

Normally this isn’t really a problem except if you put a ESX-host in Maintenance mode and Virtual Center will simply not tell you why the Maintenance mode process is hanging or even giving a time-out after 15 minutes for no obvious reason. Most of the times it’s a Virtual Machine which has a CD-drive connected to an ISO file. A waste of time if you ask me.

So to prevent this from happening I’ve written a simple PowerShell oneliner/script disconnect these CD-drives from the ISO-files or from the physical drives and set them to Client-drives which is ok for VMotion:

(Get-VM -Location:(Get-VMHost "your.esx.host")) | `
ForEach ( $_ ) { Get-CDDrive $_ | `
Where { $_.IsoPath.Length -gt 0 -OR $_.HostDevice.Length -gt 0 } | `
Set-CDDrive -NoMedia -Confirm:$False }

Instead of executing this just on one host you can also execute this for your entire cluster:

(Get-VM -Location:(Get-Cluster "Your Cluster Name")) | `
ForEach ( $_ ) { Get-CDDrive $_ | `
Where { $_.IsoPath.Length -gt 0 -OR $_.HostDevice.Length -gt 0 } | `
Set-CDDrive -NoMedia -Confirm:$False }

Or ofcourse, by Datacenter:

(Get-VM -Location:(Get-Datacenter "Your Datacenter Name")) | `
ForEach ( $_ ) { Get-CDDrive $_ | `
Where { $_.IsoPath.Length -gt 0 -OR $_.HostDevice.Length -gt 0 } | `
Set-CDDrive -NoMedia -Confirm:$False }

It’s as easy as that, now there will be no Virtual Machine interrupting your VMotions anymore and you can put your ESX hosts in maintenance mode without any problems ;)

Cheers!

Quick and simple VMware ESX Host Statistics

Just a small oneliner to display all the servers, their overall status, CPU and Memory usage in all your Datacenters (can be handy if you have multiple datacenters).

Get-Datacenter | Sort | Get-VMHost | Sort | Get-View |`
Select Name, OverallStatus, `
@{N="CPU Usage (GHz)";E={[math]::round(
$_.Summary.QuickStats.OverallCpuUsage/1024,2)}}, `
@{N="Memory Usage (GB)";E={[math]::round(
$_.Summary.QuickStats.OverallMemoryUsage/1024,2)}} 

And it will give you an output that looks like this:

image

You may not find it very useful like this, but you can also add a Where statement to this line to filter on several things. For example, you can decide you only want to see the servers that have yellow or red Overall Status due to high memory or CPU usage:

Get-Datacenter | Sort | Get-VMHost | Sort | Get-View | `
Select Name, OverallStatus, `
@{N="CPU Usage (GHz)";E={[math]::round(
$_.Summary.QuickStats.OverallCpuUsage/1024,2)}}, `
@{N="Memory Usage (GB)";E={[math]::round(
$_.Summary.QuickStats.OverallMemoryUsage/1024,2)}} | `
Where { $_.OverallStatus -ne "green" }

Which will give you something like this:

image

Ofcourse these onliners are cool and handy to use, but you can also use these oneliners to write a script around it to monitor your servers. I will post a script like that soon to show you different interpretations of this script.

HTTP DoS Vulnerability

This “vulnerability” is somewhat unavoidable. The thing is that this tool keeps on opening simple HTTP connections which is –even if the webserver limits the maximum number of connections- really unstoppable. As the quote from the Slowloris website explains pretty clearly too.

Also, the DoS tool (perl script) is freely downloadable.

Slowloris holds connections open by sending partial HTTP requests. It continues to send subsequent headers at regular intervals to keep the sockets from closing. In this way webservers can be quickly tied up. In particular, servers that have threading will tend to be vulnerable, by virtue of the fact that they attempt to limit the amount of threading they’ll allow. Slowloris must wait for all the sockets to become available before it’s successful at consuming them, so if it’s a high traffic website, it may take a while for the site to free up it’s sockets. So while you may be unable to see the website from your vantage point, others may still be able to see it until all sockets are freed by them and consumed by Slowloris. This is because other users of the system must finish their requests before the sockets become available for Slowloris to consume. If others re-initiate their connections in that brief time-period they’ll still be able to see the site. So it’s a bit of a race condition, but one that Slowloris will eventually always win – and sooner than later.

I’m not sure if there’s anything you can do to prevent an attack caused by this tool and I don’t think there is a solution to protect yourself from such.

As you might understand I advise you not to use this tool on public websites or such but only for educational purposes to see if you can find a way to protect yourself from it.
Also the attacks you do with this tool can be traced back to you cause the HTTP connections you create by using the tool will always be initiated from your own source IP address.

PowerGUI Script Editor – Empty Your Runspace

Here’s a useful tip for anyone who enjoys the handy debugger in the PowerGUI Script Editor during their intensive PowerShell scripting activities ;)

Variables

The most useful feature while debugging is the “Variables” window in the editor.

It allows you to see all the variables/objects that you declared and look inside them to see what data they contain.

 

 

 

The only problem is if you work in a script, making a lot of changes in the process, the Variables window will keep on filling up with all the variables that are used in the scripts even though some variables are not even used anymore.

This causes a mess in the Variables window so you kind of lose track of the things that actually matter and are worth keeping an eye on. So, I went looking in the Options (menu Tools > Options) and I found an option that resets the debug/variables windows (Runspace) every time you start a new debugging session. 
 
imageSimply select the “Reset PowerShell runspace each time debugging is started.” option, press OK and you will have a nice and tidy runspace (variables/debug window) from now on.