The ever growing disk consumption of Virtual Machines is a problem if you don't have a lot of disk space. So the question is: how can we tame this disk space eating monster?
You have to follow these steps in Hyper-V but for ESX it works the same way:
- Defragment the disk of your Virtual Machine. I use Defraggler (https://www.piriform.com/defraggler) which does a pretty good job but because it is sequential - disk by disk - it takes pretty long.
- Go to Windows Disk Management, right click on the disk in question and chose Shrink Volume the disk in the menu.
- Select the smallest size possible and let Windows do its work.
- When finished shut down your Virtual Machine and go to Edit disk and select Shrink (it appears only when you have unallocated disk space due to the shrink).
- After the Shrink is finished choose Compact in the Edit disk menu of Hyper V
- When that is finished choose Expand and reset the disk to its old value
- Start the VM and as soon as you're in there reset the disk to its previous size in Disk Management.
That should do the job.
This blog post is based on my experience with Windows and my desire to keep the Windows OS directory lean and mean for my Virtual Machines.
I noticed that over time my Windows directory has grown to enormous proportions on my Virtual Machines and using them on a laptop with limited disk space it makes me getting worried.
Looking around I found very quickly the one responsible: C:\Windows\Installer
Ha, I hear you say, that one does not exist. Oh, yes it does, but you have to type the name in the address bar of the explorer. See?
In fact this is a hidden system directory where Windows Installer dumps all the necessary files (.MSI) and the updates (.MSP).
Here I selected the files needed to install SQL Server 2014 up to CU6. Total size 1 GB and growing with every Cumulative Update. Grrrrr.
Next to these files you will find also tons of directories with GUID names and often you will find there only a small file with no extension, like this one:
Don't touch them because this is a little copyright trick of Microsoft: every application will use these files to show their icons on the desktop. If you delete them you will see those rotten standard Windows Icons and you have no idea where the nice ones are gone unless you enter into the registry and search for the program, find the GUID etc etc.
In my situation this directory contained like 20 GB on .MSI and .MSP files and because I was really in need for space I though what the heck, Windows is self repairing, let's dump all this shit away.
Well that was the idea.
It worked for the point that I regained a lot of space from the system disk of my VM but then I wanted to install SQL Server 2014 CU6 it got messy, but I learned a lot and also that the system Microsoft invented is crap. I will explain why.
First point is that the Windows Installer repairs nothing if it is not in the C:\Windows\Installer directory. You have to do that yourself! Even if the file is included in the installer package the Windows Installer tells you with a big error: DO IT YOURSELF FRIEND! and it stops as you can see here:
Of cause the message is rather cryptic but I figured it out:
Windows Installer copies on demand or standard all the installation files to the Windows Installer directory and to prevent that files that have the same name but another version get overwritten Microsoft invented a "clever" (really) mechanism that gives the file a new name that nobody can understand.
So in this example sql_engine_core_shared.msi becomes 16b911.msi. Clever, he?
And if there is an update the update is called sql_engine_core_shared.msp becomes 16bde9c4.msp.
Wow, that seems even more clever. No it isn't. How do you know that these two files are related? You don't but Windows does. Check it out in the registry. Then you receive another update and again the file is called sql_engine_core_shared.msp becomes 11bde4b.msp.
You see the problem now? The Windows installer directory grows and grows and we all know how many updates there are coming every month.
And it gets even worse. Even the developers at Microsoft get lost. I was restoring these files 1 by 1 and .msi +.msp files and I had to start the installer 36 times to make it forgive what I did and make it run again. Thank you, thank you.
But because I am human and smart and the Windows Installer is none of that, I noticed I had to copy a file twice with a different encrypted name. He? Yip, sometimes the Windows Installer gets lost in its crappy business and just copy some installation files twice. Who will notice? Nobody but me, because I had to restore them 1 by 1.
Take a look:
Both files with encrypted names have the same size and the same date and actually come from the same DVD. So not only the Windows Installer eats up your disk, it also does it like you want your Windows directory to grow as much as possible. Because it is hidden, nobody notice.
The whole Windows Installer construction is pretty bad and should be completely revised. The idea of a correct behaving application is that all its files are grouped in the therefore authorised directories and even Microsoft applications have to comply (usually they don't because you know).
I remember Bill Gates telling me during a presentation that Windows applications need to clean up their whereabouts after they get de-installed on the desktop. I asked the question: "What about the server? Should the Windows applications not do the same there?". Bill never answered but send me a present.
The best way to deal with the same name but different version is actually making a backup in a the application folder with a version number. No encrypted names, so if something bad happened administrators can manually repair the problem. Now everything is packed together and if an application is deleted and there are still files left it will be visible and it can be corrected. The same with the excessive growth of an application because it copies all its install files to the Programs directory. Now this become visible and it can be corrected.
The Windows Installer directory is only a new possibility for hackers to take control of an application or a system. You just have to add malicious code in the package, find the file and replace it with the given encryptic name and damage the product to run it.
The installer will ask administrative permissions and hoppa the code is executed. We just have to wait for the hack.
