VMWare Workstation SCSI vs SATA Performance

During the many years that I have used VMWare Workstation, I have noticed that there are periodically times where the disk momentarily stops responding and the virtual machines lock up. After the disk has churned for some time, the guest becomes responsive. This may happen several times throughout the day.

I am running a PC with the following specs:

• CPU - Intel Core I7 - 3rd Generation
• RAM - 32 GB
• OS Disk - 256 SATA SSD
• Virtual Machine Disk - 512 SATA SSD
• Operating System - Windows 10
• Hypervisor - VMWare Workstation 12

Today, I decided to try changing out my SCSI virtual disks to SATA virtual disks. I manually modified the .VMX files with the necessary changes.  Much to my surprise, the disk performance increased.

I was previously using the LSI SCSI controller for my virtual disks. But, the periodic freeze behavior was occurring quite often. It was getting so bad that I decided to search the Internet for a solution. My attempt at switching to SATA was a blind stab in the dark.

Having switched to my virtual disks to use the SATA controller, instead of the LSI SCSI controller, I haven't seen as much freezing - almost none. For whatever reason, the higher performing controller was causing my virtual machines to lock up for seconds at a time. The result is that I am achieving far better performance with the SATA controller.

Building Delphi VCL Packages From the Command-line Using PowerShell and MSBuild - Part 3

This is a continuation of part 2.

MSBuild Parameters

Now that MSBuild is successfully compiled my project, the following questions came up in my mind:

• Does Delphi call DCC or MSBuild?
• What parameters can I pass in?

To answer the first question, I loaded Delphi and compiled the VCL package. I paid careful attention to the output. The screen appeared as follows:

Based on the highlighted output in the previous screenshot, I came to three conclusions:

1. Delphi built the .dproj file, so the IDE must launch MSBuild to compile the project.
2. Delphi built the project in Debug mode, so there must be an MSBuild parameter to specify the build configuration.
3. Delphi built the project for the Win32 platform, so there must be an MSBuild parameter to specify the platform.

My next step was to open the .dproj file and look at what MSBuild parameters were available in there. I thought the following seemed important:

<PropertyGroup Condition="('$(Platform)'=='Win64'...
...
<PropertyGroup Condition="'$(Config)'=='Release'...
...
<Import Condition="Exists('$(BDS)\Bin\CodeGear.Delphi.Targets')" Project="$(BDS)\Bin\CodeGear.Delphi.Targets"/>

This looked promising!  Based on these three XML snippets, I came to three more conclusions:

1. The MSBuild parameter for specifying the build configuration is called Config.
2. The MSBuild parameter for specifying the build platform is called Platform.
3. Embarcadero ships a default target file, located under $(BDS)\Bin\CodeGear.Delphi.Targets.

To test out my conclusions, I decided to manually try to reproduce what the IDE had done from the command line. I entered the following:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe ZLibEx_XE2.dproj /p:Config=Debug /p:Platform=Win32

It compiled successfully. Then, I replaced Win32 with Win64.  Sure enough, it failed due to the ZLibEx obj files being 32-bit. I had only one question left:

• How could I override where to put the DCU files?

I could not find anything in the .dproj file. The only other option I could think of was to open the CodeGear.Delphi.Targets file. Sure enough, there it was:

<DCC_ObjOutput Condition = " '$(DCC_ObjOutput)' == ''">$(DCC_DcuOutput)</DCC_ObjOutput>

That was the answer I needed. The parameter I was looking for was DCC_DcuOutput. So, for my final test, I ran:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe ZLibEx_XE2.dproj /p:Config=Debug /p:Platform=Win32 /p:DCC_DcuOutput=C:\Temp\DCU

Sure enough, my DCU files ended up under C:\Temp\DCU. Perfect! By that point, I was ready to start my PowerShell module.

Building Delphi VCL Packages From the Command-line Using PowerShell and MSBuild - Part 2

This is part 2 of the series, continuing from part 1.

MSBuild Prerequisites

MSBuild is installed along with the .NET framework, so I knew it was already on my computer.

The next thing I needed to do was to figure out how to compile a project using MSBuild. So, I started by opening a command-prompt, navigating to my ZLibEx package, and running:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe ZLibEx_XE2.dproj

It failed with the following error:

C:\VCL\ZLibEx\ZLibEx_XE2.dproj : error MSB4040: There is no target in the project.

Of course, there probably needed to be some environment variables defined.  So, I looked at the shortcut properties for the RAD Studio Command Prompt shortcut on my start menu. It ran a .bat file that registers some environment variables that were located at:

C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\bin\rsvars.bat

Next, I cracked open that .bat file to see what the magic vars were. I thought the following lines looked important:

@SET BDS=C:\Program Files (x86)\Embarcadero\RAD Studio\9.0
@SET BDSCOMMONDIR=C:\Users\Public\Documents\RAD Studio\9.0
@SET FrameworkDir=C:\Windows\Microsoft.NET\Framework\v3.5
@SET FrameworkVersion=v3.5

 So, I pasted each one of those in at my command prompt. I then ran my initial command one more time:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe ZLibEx_XE2.dproj

It compiled successfully!

Part 3

Building Delphi VCL Packages From the Command-line Using PowerShell and MSBuild - Part 1

Introduction

Three years ago, feeling concerned about the future of Delphi, I left my Delphi position in favor of a C# position. I soon found myself working in a Configuration Management / DevOps / Internal Tools Developer role. During this time, I was required to master MSBuild technologies. One of my responsibilities was to automate the build and deployment of thousands of projects on a daily basis.  Needless to say, I learned the ins and outs of MSBuild.

A little over a year ago, I opened up Delphi. It brought back memories of my 11-year long career in Delphi. Some of them were good. Some of them were bad.

One of the worst memories it brought back was that of installing VCL packages. To be able to open up one of my Delphi projects, I remembered that I would first have to manually compile and install over 15 VCL packages. Some of those consisted of multiple VCL projects.

I remembered this used to take my over 16 hours to complete in the past. Being a DevOps professional at my new full-time job, I wanted to tackle this he right way. I was going to automate the installation of my VCL packages from the command-line.

Being very familiar with PowerShell, I decided to build a PowerShell module that was capable of automatically building my VCL dependencies from the command-line. My first attempt was to use the DCC.exe compiler. After sixteen hours of labor and discovering undocumented "features" the hard way, I finally managed to compile my entire VCL.

Thinking I had done something amazing, I shared the project with my former team. Being the Delphi control-freaks they are, I could tell the thought of doing anything related to code in an automated fashion was very difficult to accept! But, I was persistent. Before long, one of them even set up a Jenkins server. I was impressed. It was around that time that I enrolled in school.

Now, here I am a year later, revisiting Delphi. I first decided to check on my script. I ran it with the latest source. It failed to compile!  It was failing because somebody had added a CodeSite dependency to one of my VCL packages.

Exploring around the file system to find a solution to my dilemma, I happened to open a .dproj file.  Lo and behold, it was an MSBuild project! I had been working in Delphi for 11 years, and did not even know what MSBuild was! Now I had a new objective: Update my PowerShell scripts to compile my VCL packages in Delphi using MSBuild instead of DCC32 and DCC64. I will report my progress in future parts of this series.

Part 2

Using WD TV Live in an Active Directory Domain

I am running an Active Directory domain using Windows Server 2012.  After investing in a new WD TV Live I was disappointed to discover I was unable to access the shares on any computers within the domain.  Eventually, I encountered a solution.  It opens a huge security hole, but at least it works:

Follow these instructions to share on Windows7

(1) Run Local Security Policy applet under Administrative Tools. If you don't see administrative tools, enable it under the properties of the Start menu

(2) Under local policies -> User Rights Assignment

When you see Deny access to the computer from the network, REMOVE user guest.

(3) Under Local Policies -> User Rights Assignment, find Access this computer from the network -> add EVERYONE' and ANONYMOUS LOGON'

(4) Under local policies -> Security Options -> find Accounts: Limit local account use of blank passwords. Change the setting to disabled.

(5) Under local policies -> Security Options -> Network Access: Shares that can be accessed anonymously -> type in the name of your shares

(6) Enable the guest account; set the guest password to blank

(7) Check the share permissions on your share and make sure it has EVERYONE read

(8) Check the file permissions on the files in your share and make sure it has EVERYONE read

Windows 8 Hyper-V vs VMWare Workstation 9

Server Build

I have been an avid user of VMWare Workstation 9 for many years.  It has been an indispensable tool in my line of work.  It really is best of the class for the workstation line of products.  In fact, it now powers the majority of computers used by my family.

Last year after a video card failure and replacement, my wife and I decided we wanted to do away with the four desktops in our home and narrow it down to one single desktop.  I was very excited to hear that she was on board, since she generally cringes when I mention purchasing computer equipment.  Feeling giddy as a boy at Christmas time, I began research the Internet for the best CPUs, motherboards, hard disks, etc.  After a bit of research I managed to build a really nice system for $950 that included a 128gb SSD drive, a 3 TB enterprise hard disk built for video monitoring systems, an I7-3770K processor, and 16gb RAM, and a nice ASUS motherboard to go with it.

It was around that time that Windows 8 was being released to manufacturers.  Wanting to test it out before I purchased it, I snagged a copy through my MSDN account and installed it on my new hardware.  It installed smoothly and worked flawlessly with my ASUS motherboard.  Once I had my operating system all set up, I had a decision to make regarding my virtualization platform:  VMWare Workstation 9 or Hyper-V?

The fact that I recently upgraded my VMWare Workstation license to 9 was the determining factor.  I installed VMWare Workstation.  Now, I just needed a way to run virtual machines in the background.  It was not at first obvious, but VMWare Workstation 9 supports this out-of-the-box.

Shared Virtual Machines

Sitting in the Library browser on the left side of the VMWare Workstation main screen is a feature called "Shared VMs."  A shared virtual machine has the following features:

• It can run in the background
• It can automatically start up with the system
• It can automatically shut down with the system

It loses the following features:

• Copy and paste
• Drag-and-drop
• 3D graphic support
• Sound card support

Virtual Machines

After a bit of trial and error, I was able to figure out how shared vms work.  I then proceeded to set up my domain controller as a guest virtual machine.  Once the domain controller was up and running, I actually joined the host to the domain.  I questioned whether this would work very well.  But, with the domain controller starting up automatically with the system, this worked out very nicely.

Throughout the next few months, I then proceeded to set up eight or so more virtual machines that were used by various family members for various tasks.  The majority of them were my development lab.  I like to dedicate a virtual machine to each major project I work on.

Challenges

As time went on, I noticed that the virtual machines would periodically slow way down to do heavy disk I/O.  I would be in the middle of working on a virtual machine, and then it would start running very slowly.  It happened frequently enough, that I begin to grow frustrated.  Soon, I learned one cause of this was Windows Update.

Periodically, the virtual machines required a little extra RAM than what I had allotted for them to use.  This was especially true for Windows Update.  Since the RAM was not available, they would start thrashing the hard disk as RAM would be stored in the page file.

On top of this, the VMWare Workstation console would randomly lock-up on me as I was using it.  When that happened, I used Task Manager to end task the console.  This worked two to three times.  By the third time, I could no longer connect.  It would just time out.  The only fix I found for this was to restart the host.

Hyper-V

At last, in an effort to gain performance, I decided to ditch VMware in favor of Hyper-V.  I converted my virtual machines to Hyper-V.  The process was very drawn out and took an entire weekend.  Once they were converted, I set up some of them to start automatically with the host.

Boy was there a difference in performance!  I could now run six virtual machines at a time without any noticeable performance decrease.  All six of them had near instantaneous response speeds.  The RAM would increase or decrease automatically for each virtual machine, depending on the needs of that machine.

Challenges

Things were going so well that, at last, I decided to delete my old VMWare virtual machine images.  It was about that time that my wife decided to watch a Blu-Ray movie on the host.  PowerDVD reported to her that our graphic hardware was not sufficient to play the movie.  Scratching my head in confusion, it finally occurred to me that the only change in configuration was that I had installed Hyper-V.

VMware Wins Again

Curious, I removed Hyper-V from the computer and restarted.  PowerDVD was happy to the play the movie.  So, I started benchmarking various programs with Hyper-V enabled/disabled.  It turns out that performance decreases drastically when a host is turned into a Hyper-V server.  Knowing that my wife would insist that the Blu-Ray player worked, I than began the slow and painful process of converting my virtual machines back to VMWare.

Linux Links

Start KVM at startup: http://www.cyberciti.biz/faq/rhel-centos-linux-kvm-virtualization-start-virtual-machine-guest/