Depending on the type of virtualization, 5% overhead is pretty much best case scenario. With full paravirtualization, you can achieve such overhead on IO-light workloads quite easily. With hardware-assisted virtualization (technology used by VMWare), it is possible to achieve such a low overhead on IO-light workloads on an hypervisor with few VM. With full virtualization (no CPU extensions), 5% overhead is pretty much a dream.
Keep in mind this can depend on very many factors. Virtualization tends to add a significant amount of latency between disks and the guest OS. This will increase IO wait and therefore load averages while keeping CPU usage rather low. If your storage is on the lower side of the IOPS scale, this will have a very big impact. If you are using network storage, this will almost always add latency due to having to access a network for each IO instead of just accessing an internal bus.
Virtualization can also add extra network latency if you use special network configuration modules such as virtual switches but this usually is not very significant.
Virtualization tends to add many extra interrupts which are required to switch from a VM to another. Depending on the scheduler of the hypervisor, this can be significant. There isn't much you can do about this since it is just due to the nature of virtualization. But it is something to keep in mind as a justification to lower performance.
Due to the single-threaded nature of your application, having more cores will yield no significant performance improvement. Both CPUs have similar frequencies but you will notice the X5650 has a slower frequency without "Turbo Boost". You may want to check that feature is compatible/enabled with your setup.
33% overhead on IO intensive workload is, I find, not so bad. Try separating the storage for your two VMs and see if it helps.
Full disclosure: I'm not running vCenter. I have run other software packages with SQL Express, however.
You can run SQL Express maintenance jobs as scheduled tasks with batch and sqlcmd, like:
sqlcmd -E -SServer\instance -Q "EXECUTE [VIM_VCDB].[dbo].[cleanup_events_tasks_proc]"
Another article I found (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1020904) suggested using a script which could be invoked like:
sqlcmd -E -SServer\instance -i "C:\Program Files\VMware\Infrastructure\VirtualCenter Server\cleanup_events_mssql.sql"
Edited in response to your edit: Limiting the size of your t-log can break really big transactions, including shrinks and large deletes. If VCenter itself rather than an Agent job is running the deletes, that could be your problem. And considering that the default is Express, it makes sense that they wouldn't depend on (unsupported in Express) agent jobs.
Best Answer
In the Windows VMware vSphere Client program --
Select your Datacenter, cluster or host.
Select the Virtual Machines tab.
Right click an empty area of the window and select "Export List".
Type a file name and click the "Save" button.
Done.
Note that the default file type when exporting the list is htm/html but you can change it to xls or csv (among others).