1 vCPU for FT - does that include cores?

[neilchapman]

We have an application that runs our business about 16 hrs a day that utilizes MS SQL Server 2005 running on Windows Server 2003 (16-bit) SP2.  I am not able to upgrade to newer software.  The existing server is a Quad Xeon Intel machine.  In vSphere 5.1 we want it to run using FT in a new dual Host, dual SAN environment.

Since FT only supports a single vCPU does that mean single CPU and single core?  I'm concerned about the SQL Server moving from Quad CPU to Single CPU.

Also, I'm not too sure how to move this server into vSphere.  The c:\ is 45G and e:\ is 150G and the conversion time may be longer that our downtime window of 8 hours.

Will I have to change the HAL for WS 2003?

Any experience or wisdom would be appreciated!

[vmroyale]

Yes, 1 vCPU/1 core is it for FT.

What is the spec of the current and future CPU?

You might be able to seed some of the data on the SQL Server, but that depends. Converter could always be used for part of the P2V and standard file copy apps could be used to get the data. If you go this route, make sure to create an aligned disk for the new data drive as 2003 likely wasn't aligned properly.

The HAL should be changed to a uniproc, if you go this route. Once the P2V is complete and the clean up is done, power it off and take a snapshot. Then change the HAL. That way if it causes problems, you can quickly get back.

[neilchapman]

Current CPU

HP DL360 G5

Single Quad-Core 2.00 GHz Intel Xeon E5335 processors w/4G RAM

   ( I just realized this is a single processor 'quad core' machine.  Perhaps performance will not be an issue.)

New Host Machines (Qty 2)

Dell R620

Dual Six-Core 2.50 GHz Intel Xeon E5-2640 processors 15M Cache 1333 MHz Memory w/64G RAM

===

I'm not sure what you mean by "seed some of the data".

Thanks!

[vmroyale]

I'm not sure what you mean by "seed some of the data".

Converter could be used to convert the OS volume during the planned downtime. To save the time it would take to copy over the larger "data" drive as part of the P2V, you could (prior to the downtime) create a VMDK and present it to a helper VM. You could then use tools like robocopy/scopy/xcopy/etc to copy the data on the SQL drive to the helper VM. Then when the planned downtime comes, you run a differential copy using robocopy/scopy/xcopy/etc to pull over the changes. Finally, you present the "data" disk back to the P2V converted system. This approach can be faster, but with SQL a lot of it will depend on the size of the databases/logs. This approach can be faster, when you have a limited window of opportunity.

[Josh26]

It's currently running on a server with no redundancy.

I would suggest the availability of HA, which supports multiple cores, is probably a better sell than single core FT for your server.

PS I suspect that was a typo where you referred to 16-bit Windows. This would mean... Windows 3.1.

[neilchapman]

Yes - We'll definitely have the two Hosts HA.  The resiliancy requirement of the db requires FT.  It may have been better to create a SQL Cluster but with the SQL version EoL in April of 2013 it seemed like a support nightmare.

I've been thinking about your suggestions.  Is this summary correct or am I missing something?

1. Add backup w/differentials to Source machine
2. Load Converter on Source machine
3. Follow Converter Best Practices Pre Conversion
4. Prep data drive for presentation to new vm
   1. Create helper vm
   2. Create separate (aligned) vmdk for SQL data (E:) -Restore data and differentials to this drive but continue differentials on source
5. At start of downtime
   1. Finish last differential and restore to helper vm
   2. Conversion of C: - Cold - Align on SAN
   3. Follow converter best practices post conversion
   4. Take a snapshot
   5. Change HAL to Uniproc
   6. Present E: to new VM
6. Success

[RParker]

neilchapman wrote:

Since FT only supports a single vCPU does that mean single CPU and single core?  I'm concerned about the SQL Server moving from Quad CPU to Single CPU.

Any experience or wisdom would be appreciated!

Your concern is valid.   FT has a lot of potential.. and it's not fully baked yet.  VM Ware is still testing..

I have heard there are work arounds to make FT work with multi socket / core VM, but it's obviously not supported.

VM ware (at least the engineers I talked to) is well aware that FT is a great feature, many people are anxious to use it, but limiting to only 1 CPU defeats the purpose.  VM Ware is definately aware this limitation is a huge issue... I know people at VM ware that use it, and love it.. with multi core, it's just not ready for the masses.. they need to do a couple more changes before they can enable multi core in a VM.

VM Ware / ESX 6.0 will more than likely resolve this issue.. but that's another thread