Ubuntu – safely increase the number of processors on a VM

To sum up:

• on your real server you can make 1700 table updates + 1700 commits in less than a second,
• on your virtual server you can make 1700 table updates + 1700 commits in 9 seconds,
• on your virtual server you can make 1700 table updates + 1 commit in less than a second.

So it seems to me that your problem can be redefined as "on a real server I can make 1700 commits in less than a second, but the performance drops tenfold on my virtual server".

What is the difference between 1700 table updates and 1700 commits? The table updates are fully cached and do not depend on disk I/O at all. With commits this is quite different. Per the very nature of transactional databases, the database engine has to be damn sure that the commit has been actually saved to disk (saved to a log file), before it even starts to commit the next transaction. So for every of those 1700 commits, it has to wait the entire I/O round-trip. To sum up, in your scenario the latency of I/O plays a very important role, and should be analyzed (do not mistake the latency with the I/O rate or throughput in bytes; these three are all totally different animals; they are always tuned separately).

It's a good plan to test your storage with IOMeter. It hangs at startup because it tries to fill your entire disk with its test file. Just wait until the file grows to considerable amount and re-start IOMeter, it will work properly with the "incomplete" test file.

Merely adding or removing vCPUs after installation of the guest OS is not an issue with any version of Linux or Windows that's recent enough to still be vendor supported. This warning dates back to the very early days of VMware and is mostly irrelevant now.

In the early days of Linux, though, the kernel had to be specifically compiled with SMP support, and occasionally UP kernels didn't like running on SMP/NUMA systems, or vice versa. Those days are long since mostly forgotten.

These days Linux kernels are almost always compiled with SMP/NUMA support by default and run fine even with one processor. This has been true for all of 2.6 and most or all of 2.4.

Windows has behaved similarly since Server 2003. I wasn't able to quickly find definitive information on the Internet about how 2000 and NT 4.0 behaved, though I seem to recall from distant memory that they may have had issues when switching from a single CPU to multiple CPU configuration.

If you plan to P2V a very ancient system, though, it's theoretically possible you might run into such issues.