On the Subject of Bloat

VM’s take up space. They use resources like RAM and CPU cycles when they’re online, and they use up storage no matter if they’re online or not. As VM infrastructures get bigger and bigger, so does the amount of resources that they consume.

In the modern datacenter, this has contributed to a theory called bloat, where VM resources balloon larger and larger over time. In many cases, this bloat isn’t being caused by active resources, and that’s where problems can occur quickly.

As VM’s are provisioned and used, the active resources they take up are necessary for the VM system itself to function. You have 10 servers that each use about 50GB of disk, 2 processor cores and 4GB of RAM, etc. The problems start when those servers are no longer needed.

You upgrade to a new CRM system. The old CRM system’s VM’s are – of course – shut down after the migration. As usual for any updated system, the old system is kept dormant for a period of time, just in case you have to either go back to it, or retrieve data that didn’t make it through the migration process for some reason.

Now it’s six months later, and the old system is all but forgotten about. But the VM’s that made up that old system are still there. Since they’re not physical machines, and since they’re not using RAM and CPU power, it is all to easy to simply forget they exist and leave them on the VM hosts that they formerly ran on. That means that a set of storage is not useable, because it’s being held by the – now-non-functioning – CRM system VM’s.

As more applications go through this life-cycle, more dormant VM’s are left sitting on the VM hosts, eating up more and more space and other resources (VM network ports, etc).

So, a few times a year, go through all the dormant VM’s and make sure they really need to be on the VM systems at all. If they don’t, clear out the space (after taking a backup, of course) and free it up for other systems within your active pool of VM’s.

There will always be some dormant VM’s that need to stick around for various reasons, but any that do not need to remain on the VM hosts are doing nothing but sapping space and taking up time during maintenance runs.

Dealing with bloat effectively can mean the difference between having a smooth running system with plenty of space, and having to buy a new storage device because you ran out of room for no valid reason.

One of the Big Boys Reminds Us They’re Still Here

It’s true that many of us consider VMware and Microsoft and Citrix to be the parents of virtualization technology, but those of us who have been in the digital world for some time know that they’re standing on the shoulders of giants.

This week IBM announced that they would begin supporting Windows applications and instances within the zSeries mainframe platform.

Now, there isn’t a lot of information contained in the press release as to how they will do it, but if IBM follows form as they have in the past, it will be a Windows-capable card in a zSeries chassis. That means that they zSeries (which runs Z/OS) will be able to manage and at least partially control Windows servers that use system resources housed within the zSeries itself.

The mid-tier platform from IBM – the iSeries AS/400 systems – can already do this, using a hybrid virtualization approach. The physical hardware that the Windows OS installs to is a card that sits within an iSeries chassis, but all other resources are contained within and managed by the AS/400 platform itself in much the same was a physical network interfaces, volumes and other resources are presented to a hypervisor-based VM instance.

Since the release refers to the zSeries Windows capabilities as “hybrid,” it may very well mean we’ll see the same approach to OS virtualization on that platform as well.

It may not be the hypervisor systems we’re used to calling “virtual” these days, but IBM has been doing it for longer, and doing it with a greater degree of stability, than modern approaches.

Just goes to show that as soon as standards are developed, someone will come in an prove that one definition cannot cover an entire topic.