Nov 17 2008 6:31PM GMT
Posted by: Edward L. Haletky
Security,
Virtualization,
VMware,
Virtualization security,
VMware ESX,
VI3,
VMware scripting,
VMware ESX 3.5,
VMware ESXi,
Virtual machine security,
Edward L. Haletky
Virtualization security depends on more than securing the virtualization host and hypervisor. It depends on everything that touches your virtualization host, directly or indirectly, also being secure.
Let us take a quick look at the daily operations you may perform within your virtual infrastructure.
- Create/Move/Modify virtual machines (VMs)
- Backup/replicate VMs
- View performance and other data about hosts and VMs
- Install/Reinstall/Update hosts
- Add or remove administrative users from VMs and hosts
- Monitor your VMs and hosts
- etc.
The list is quite endless. Each one of these actions will affect security or be affected by security.
Ease of use, ease of administration is sometimes paramount. This is the age-old debate of security over usability. Do not knock holes in your firewalls, instead, use existing secure protocols to improve the experience. One I use is OpenVPN to access my administrative network workstation using pre-shared keys for encryption. The extra step of starting up the VPN is trivial with the service provided, this gives me secure access to the management network over which the tools can be run.
Affected by Security
There will be at least one more step involved in use of daily tools then you would normally use. Mainly some way to ensure your access to the management tools is secured from sniffing by your non-administrative network. Or the use of different procedures to ensure you have proper auditing in place.
One tool I use is a simple expect script called expectsudo which will allow me to run remote commands on my VMware ESX hosts while retaining logging of all access. To use this tool you must first install the expect RPM onto your host. Then setup sudo to allow access to the appropriate commands.
#!/usr/bin/expect --
set pass [lindex $argv 0]
set timeout 5
spawn /usr/bin/sudo [lrange $argv 1 end]
expect "Password: {send "$passr"; exp_continue
sleep 1
In the above script the first argument will be the password to use. This script can not be run remotely using any form of SSH. For example:
ssh user@hostname expectsudo password esxcfg-vswitch -l
The only drawback to this script is the need to have the password available, instead you can setup pre-shared keys for SSH and setup Sudo to allow the user to issue certain commands without requiring a password. This form of single sign on relies on the security of the management workstation in use.
Security of your VMware Infrastructure relies on the security of all the management workstations and servers in use. Not just on the hardening of the VMware ESX host.
Sep 11 2008 4:00PM GMT
Posted by: Rick Vanover
Virtualization,
Rick Vanover,
VMware scripting
In my opinion, VKernel’s SearchMyVM virtual appliance (VA) has to be one of the most useful free virtualization management tools. I have found myself using it quite frequently to get information about my environment. I mentioned its release over on SearchServerVirtualization, and here I want to share some common queries I’ve used that you may want to hold onto for frequent use, and how they can help you:
vm.cdroms.connected=true
vm.toolsStatus=toolsNotInstalled,toolsNotRunning,toolsOld
cluster.haFailoverLevel
cluster.drsEnabled
vm.hostName:servername
from the VKernel website.
Aug 11 2008 1:59PM GMT
Posted by: Schley Andrew Kutz
Virtualization,
VMware ESX,
VMware pricing,
VI3,
Andrew Kutz,
VMware scripting
Although VMware’s ESXi hypervisor is free under the VMware Infrastructure (VI) base license, it’s not without limitations.
Only some of the application programming interface (API) method calls that are typically shipped with the VI SDK are available. It’s impossible, for example, to power on and off a virtual machine directly with Java or C#, the VI Toolkit (for Windows), the VI Perl Toolkit, or any other scripting toolkit or programming language that leverages the VI SDK. Full functionality is restricted to the VI client. I believe that this is VMware’s attempt to prevent third parties from developing management solutions for ESXi and selling them at lower cost than VMware’s VirtualCenter.
Despite these restrictions, I recently discovered a workaround that allows full access to the API. The method to circumvent VMware’s lockdowns will not be discussed here because it is unintentional and violates section 3.3 part 4 of the ESXi EULA:
You may not … create, develop, license, install, use, or deploy third party software or services to circumvent, enable, modify or provide access, permissions or rights which violate the technical restrictions of the Software.
VMware has been notified and is currently working on a patch to resolve this issue. Remember that in the interim, this method or any other means used to gain full access to the API in the free version of ESXi violates the EULA and should not be used.
That said, it’s still pretty cool 
Jan 17 2008 4:07PM GMT
Posted by: Schley Andrew Kutz
Andrew Kutz,
VMware scripting
Have you ever wondered why VMware’s VI client is Windows only? The most obvious reason is that it is written in C# using the .NET framework. However, the client could easily be written in Python or Java or some other OS agnostic language. So why Windows only? There are in fact two reasons the VI client is Windows only, let’s take a look at them.
“I’ll be your Huckleberry”
VMware apparently uses a C library called “TomSawyer” to handle the task of graphing performance output. Digging into a disassembled VI client, you can see where the Interop assembly is used and what it is used for. Using the Microsoft OLE/COM viewer to peer directly into TomSawyer’s library certain functions and strings like “GridColumnObject” and “TSEFlowChartType” give away the library’s purpose. I cannot think of a reason to marshal a library that graphs datasets unless VMware thought .NET was not up to the task of plotting data. However, the performance graphs displayed in a VI client take so long to initialize anyway that I do not think anyone one have noticed. As Barney on HIMYM says, “JIT up!”
QuickMKS
Sorry, I did not have a witty title for this section The other reason that the VI client is Windows only appears to be the library that it uses for the console view. The MKS (mouse, keyboard, sound) library is what the VI client marshals when it creates the console connection directly to the VM. Notice the absence of a V? I do too. Although the library’s name does not explicitly state that it is responsible for video, the functions inside of it, FullScreen, SetFullScreen, SetGuestSize, etc., seem to indicate that it *is* the responsible library.
Anything else?
TomSawyer can certainly be ported to run natively in .NET or another language (it does already in fact have a Java version), but QuickMKS may be a bit more difficult. It almost certainly relies on native OS calls that are most likely quite difficult to get working on other systems. However, if VMware would be so kind to send the source code my way, I’d sure like to try!
