Monitoring capabilities
VMs are allocated shared resources when they’re born, and then must live within the confines of those settings. When VM instances use their maximum allocation or are allowed to constantly plug into shared (oversubscribed) resources, administrators need to know so that the help desk doesn’t light up with complaints of apparent application inadequacy.
We used SC-VMM's instance monitoring capabilities to watch CPU, memory and disk use (how much and how frequently) to gauge its capabilities vs. VIC’s ability to monitor VM performance attributes. To make a long discussion short, they're nearly the same. Important VM characteristics are monitored in each. VIC comes out on top when it comes to watching if exceeding thresholds triggers an alarm. Thresholds aren’t monitored inside SC-VMM as this requires use of other products in the Systems Center family. VIC, however, allowed us to set thresholds in areas such as CPU utilization, where zero utilization meant that perhaps an application had crashed or hitting a ceiling meant the application was peaking.
Using VirtualCenter Infrastructure Client, you can set alarms based on conditions that we needed to know about such as when CPU, memory, network or disk usage goes above or below a certain threshold or when the machine state changes or there is no VM heartbeat. There are three colors for severity, green, yellow and red. Green means everything is fine, yellow is like a warning and red is severe. Once it is triggered, it was recorded in a log file. We could set how often it would trigger again either by frequency (in seconds) or tolerance (a certain percentage). We could also set an action to follow when a trigger is set off. These actions include sending an e-mail, sending a notification trap, running a script, powering on/off a VM, suspending a VM and resetting a VM.
While there are no alarm or trigger options built-in SC-VMM, there is a limited set of options that allowed us to start specific virtual machines as the server boots up. Or when the server shutdowns, Hyper-V can both save the state of an turn off the virtual machines.
Security could use some beef
We had issues with both hypervisors in terms of security in several areas. The first big issue is the fact that images that are used to build virtual guests aren’t serialized and/or authenticated in either platform. Should the image storage area be accessible, only file system time/date/modification meta data will be able to indicate that a virtual machine image has been either used or worse, tampered with.
As both hypervisors lack a native repository, images must be stored in an area chosen by the administrator and would desirably be authenticated through external methods, such as MD5 hashing, rudimentary checksums, or other ways that can validate image contents. VMware does embed an ID number into the image contents for enumeration, but not for authentication, purposes. As both ESX and Hyper-V produce images in formats that are easily mountable file systems, hackers with even rudimentary skills and file system access can tamper with images. This begs for at least a minimal image repository scheme that records authentication hashes or data to be included even in a basic bundle.
We also found that ESX doesn't police password strength in its strictly Windows-based VirtualCenter. If the passwords are weak, access can be garnered through dictionary password attacks.
Hyper-V when managed through SC-VMM is accessed through default or defined Active Directory passwords, which are by default strong and can be made stronger and/or with additional authentication schemes.
Third-party authentication devices are virtually ignored. Controlled access to both hypervisors is lacking, although, the Windows 2008 Server that runs underneath Hyper-V has some authentication mechanisms in place. Still, no direct authentication for either Hyper-V or ESX exists.
VMware added a basic firewall to surround itself by default when we installed it. The Windows Firewall components built into Windows Server 2008 ostensibly protect Hyper-V VM guests, but we didn’t assault either product to see if we could crack them. We could fingerprint the VM guests if ports were open to do so, and therein lies an unexplored attack vector.