p2v, now MS SQL 2005 is very very slow, memory usage wrong

[cajx]

I did a p2v of our 64 bit MS SQL 2005 box. I've had good luck with p2v with non SQL servers, but after doing this the VM runs like a dog. So I reverted back to my physical box... it is also running like a dog!!! Help! Memory usage by SQL used to be around 15 Gigs, now it's staying under 2 Gigs. I see the VMware-converter-a.exe *32 is still running. I see a sqlWb.exe *32 is running (can't remember if this is normal).

In a bit of an emergecy, so any help is appreciated!

[Rockapot]

Stop the VMware-converter-a.exe process to regain performance of the physical machine, if this is consuming processor/mem resources.

As for the virtual server. Did you do the usual post P2V clean up actions?

Additionally if you are doing a P2V of SQL you should not be doing it in a hot clone fashion. If you do then atleast schedule and outage and stop the SQL services.

I would recomend you do a cold clone of any SQL servers.

Carl

[AndreTheGiant]

How do you revert your system back to physical?

PS: the converter service could be simple disable.

Or remove the program.

Andre

[cajx]

the converter is just using 50 MB, so that in itself isnt a big deal... just didnt know if it "worked magic" and made SQL slow. I did stop the two main sql services before doing p2v. I may have not done all clean up , but i have to get the original back to normal before i can worry with the vm

[cajx]

back to physical: I just renamed teh VM to something fake, then turned my old box back on. Active directory didnt have the name anymore, so i had to put it off domain, put it back on domain with correct name.

[Rockapot]

To be honest you should ensure that the post P2V checks are all done prior to exiting the change window to ensure that the VM is performing ok and does not have these types of issues.

Are there any event log entries on the physical server of interest?

Carl

[cajx]

Thanks all for the help. As for the physical server, it appears that once I turned off the VM "copy" of it, the problems went away. This is despite the fact that they had different IPs and different names... I'm not sure if it was an AD SID thing or some of the SQL server names that exist in the SQL tables. Will test more after hours. This still doesn't explain the reason the VM was so slow when it was the only box running, but I probably need to do more of the clean up.

[Rockapot]

Once the VM is cleaned up you will also need to size it accordingly depending on the workload. Sizing is mostly an educated guess activity in the absence of capacity planning tools and from past experience.

Carl

PS: Remember to aware points for helpfull or correct answers

[DSTAVERT]

I would have a look at SQL Best Practices. 64 bit applications would be much better on a 64 bit platform AKA ESXi 4.

[cajx]

That SQL best practices looks juicy... going to read it. We are using ESXi4 for now (will be using ESX 3.5 and then 4 in the near future though)... but am I to understand that ESXi4 handles 64 bit better then ESXi 3.5?