Tag Archives: virtualization

Neat infographic on Gartner’s virtualization quadrant

Virtual Geek posted one of his colleague’s sent in an internal thread.

I’m not reposting the graphic here at this point but check it out. It’s a great visualization of the market players for each year from 2010 through 2014. Summary:

  • VMware: Looks like tight, precise grouping on a bulls-eye
  •  Microsoft: Nice slide to the right and up
  • Red Hat: Steady rise upwards and to the right (not sure why this isn’t higher but I’m biased)
  • Oracle: Does a little fishhook upwards but back
  • Parallels: Decent rise
  • Huawei: Shows up
  • Citrix: CRASH – at least that’s what I’d call it.



OnApp Account Registration Fun


Tonight I decided to dig into OnApp. The workflow this far hasn’t been the smoothest but it probably helps reduce the company’s administration overhead.

After validating one’s email, he is taken to profile page with an installation instructions link.


There seems to be two accounts that are created at registration, one for administration (admin.onapp.com) and one for documentation (docs.onapp.com). The admin account is setup after email validation but the JIRA account appears to be constrained by an account approval process the will provision or enable the account in the JIRA system.



I’ll look forward to completing the installation and setup so that I can see how OnApp stacks against its competition.





Stuck Windows Public Networks

Windows 7 offers three types of networks as managed within the Network and Sharing Center: Home, Work, Public. Each type allows for customization of security policies such as what services are allowed through the Windows Firewall.

While the Home and Work types are relatively straight forward, what is Public is not always so. Sure, I have a string of thirty Starbucks and other Wifi hotspots that are obviously Public (as I set them to be upon connection), but you may encounter Public networks defined within your system that you were never given the choice to select in which category it fell. This special case of Public in fact is a network to which you connect that does not have a defined default gateway attribute. Microsoft further decided that these “unknown” Public networks cannot be made “known” with a reassignment to another class such as Work. So what’s the best way to handle this situation should you encounter it?

There is no single answer to the best means of addressing this Windows quirk, but there are common sense approaches that will allow consistent and predictable results. I outline the here one such avenue.

One of my typical use cases is creating special networks for my clientele. For example, in the graphic above I needed to demonstrate accessing a public static NAT through a next-generation firewall from a system within the same zone and interface upon which the “public” server resided. As the demonstration system is running virtual servers which are multi-homed, firewalled with true Internet access via another interface, adding a generic default gateway is never an option. So how can you have your cake and eat it too?

The answer is simple, add a weighted gateway to the interface then assign the connection to the zone in which you want it. :-)

Windows Active Directory as Virtual Machines

There are several major considerations for running virtual domain controllers. While I support and recommend VDC use, some common sense precautions need be taken.

  • Ensure the basic virtual networking configuration for the VDC is within Windows Sites definitions and their appropriate subnets.
  • Confirm connectivity for full Microsoft DS IP-suite ports to the Virtual Hosts Farms. This means routing and firewalls should be in place and tested. Note that bridgeheads are applicable in more constrained environments but any type of autotopology support is usually preferable – especially with Windows 2003 and 2008.
  • If using DCs with Virtualization HA features such as VI3′s, make sure the above is true and safely test.
  • Don’t treat VDCs like regular Windows servers – they aren’t. You can risk serious issues if you think you can just fall back on a snapshot or a prior image file. MSDS like DNS uses a serial number of sorts (the USN). You don’t want to cause issues in one of the most important systems in your environment.
  • Exercise care when restoring with backup software whether Microsoft certified or not. Use the principle of doing the least required. Restoring a DC from even a trusted backup application still should be treated with gravity.

Microsoft themselves further recommends the following to prevent the domain’s Update Sequence Numbers (USN) being rolled back from causing issues (from Technet).

  • Do not take or use a snapshot of a domain controller virtual machine.
  • Do not copy the domain controller VHD file.
  • Do not export the virtual machine that is running a domain controller.
  • Do not restore a domain controller or attempt to roll back the contents of an Active Directory database by any other means than a supported backup solution, such as Windows Server Backup.

Now, really, all the above applies to _physical_ DCs as well (or for that matter, P2Ving, V2Ping, P2Ping, or V2Ving), but the point is that with the proliferation of Virtualization that it is much too easy to shoot yourself in the foot.

For more information, please see my Microsoft Systems Resource page.

VMware OS X Bug & Forest Fires

From VMware Forums: Avoid potential data loss due to Apple bug and “Optimize for Mac OS application performance” preference

After I made my last post about my Fusion VM issues, B.G. of VMware contacted me suggesting that I confirm my Fusion optimization settings. Unfortunately, it had nothing to do with it as I already had configured for Optimize for virtual machine disk performance. (Thanks anyhow again B.G.) I’m fortunate to have a decked out MacBook Pro (2.6 GHz Intel Core 2 Duo, 4GB 667 MHz DDR2 SDRAM and a 200GB disk (because size does matter): I planned this laptop explicitly to run OS X/Fusion (with all my sub-OSs), Ubuntu and Vista (GFI/Boot Camp).

Prior to posting here, I was at the VMware web site for an update for Fusion and/or Tools/openvm-tools that I might apply prior to updating Leopard. In any case, I’m about to do the Leopard 10.5.3 to 10.5.4 update that I’ve tested already and have three backups to protect against the worst case (and I’ve tested one of them – better than total trust, eh). I’m not too worried because my key files are replicated through more than just the three backups (to multiple offsite hosts).

New life from the remains of a scorched forest.

Sometimes I have a silly desire to want my systems to die in an update. Having witnessed, read about or fixed so many OS update failures in my life, it’s a bitter-sweet event that one can make the best of. Similar to the results of the forest fire I saw outside my family’s home in Pine, the “scorched OS” event is sad but awesome at the same time… the cycle… the chance to begin anew, fresh…

Mac VMware Fusion and Linux Machines Blip

Oddly, after updating to the newest VMware Fusion on my MacBook Pro, EVIL gremlins decided to attack my VMs. Little pests they can be.

For the record, I updated from Fusion 1.1.2 to 1.1.3 prior to completing 10.5.2 to 10.5.3 Leopard update which fixes a notorious , wicked bug (system lockups under intense disk usage). Of course running as many windows/tabs as for I am famous in my circles on my host and guests combined, frequently pegs my disk I/O. Afterall, isn’t that for what preemptive multitasking exists – to maximize your productivity and that of your system by combining workloads with safe, proportionate resource assumption.

For the uninitiated into VMware, it’s guests, the hosted Virtual Machines, best perform and function with a package called VMware Tools. The VMware Tools package handles some pretty core items such as connected state of the hardware (e.g., audio and network controller), time synchronization, and virtual disk management (e.g., shrinking). VMware makes excellent tools for their Windows hosts and satisfactory versions for non-Windows systems such as Linux and BSD. I’ll cease my foray into VMware here and get back to the point.

When one upgrades a VMware host, there is a period which the guests will be running the old VMware Tools on the new version of the host. Additionally, on non-Windows systems, you must compile the Tools packages yourself. I don’t like to rush to conclusions, but it would seem that this combination alone may not have played well together. As a result of a short run the following occured across my VM guests.

  • My CentOS virtual machine became non-responsive.
  • My Ubuntu virtual machine’s network PCI interrupt became permanently disabled.
  • My KNOPPIX virtual machine became non-responsive until reboot.

I rebooted the CentOS guest and needed to run massive filesystem repairs (ultimately, I chose to restore to a backup).

The Ubuntu machine is a long story but the way I resolved the issue was to add/hook into another set of network cards, leaving the original momentarily. The new controllers came up on alternate PCI addresses and work fine under the old and recompiled binaries.

KNOPPIX is just nice – it will always be one of my favs… I just rebooted it of course.

I hadn’t had my other VMs in use and need to rebuild their tools (BSD-based)… I build them on a different system like a good boy so I can install them straight off the bat.

All is well… this only reinforces the need to have regular (and tested) backups for more than just your data. Your time is worth it let alone the mitigation of risk.