VMware migration

Hi Experts,
Need to identify servers that will be a good candidate for virtualization(VMware)?
I have some database servers too but I would like to do them in later part of the migration, most of the applications are web based / IIS based, there are few file servers and print servers too.

Each server runs in dual core two-socket cpu server and will be moving to quad core dual socket blade server (consolidation).

How can I calculate the resource for each server?
How can I confirm if they are good for virtualization or not?
Anything else you would like to recommend?
Any suggestion moving database servers to virtualization?

Thank you in advance.
ThushyaAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

mkriszCommented:
Here is a complete video about how to do that. You just have to watch it.
http://www.vladan.fr/how-to-convert-a-physical-server-using-vmware-converter/
0
coolsport00Commented:
"Thushya", the simple answer is, there is no *bad* candidate for virtualizing physical servers, regardless of 'type' (Web, IIS, DB, etc.). So, in determining which ones are best candidates, they all really are. You can go to VMware's site and download a 60-day trial of vSphere (ESX4), and it comes with all the features (again, for trial purposes). With it, there's a "Guided Consolidation" plug-in to help you determine the physical servers to virtualize. Getting dual, quad-core socket CPU servers is certainly a good start. That should house all servers you want to virtualize. How many physical servers are you wanting to P2V? What are your thoughts on that, or your org goals?

For your DB, I would place that on a SAN, the connect it to your DB VM through what's called RDM (raw device mapping). It's basically just a 'pointer' file the ESX uses to 'see' the data on a SAN infrastructure. If you are wanting to use VMware's features (HA, DRS, & VMotion), you will need to get a SAN or some kind of shared storage infrastructure as those features require it.

As far as RAM...beef up your servers as best you can. It's a good investment, although really, RAM is cheap anymore.

Hope that helps.

Regards,
~coolsport00
0
ThushyaAuthor Commented:
mkrisz,
It is not about to how to convert them, its about calculate the resource needed and to validate an existing server if it is a good one to consider for virtualization, there is no come back.

any way thanks for the link.
0
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

coolsport00Commented:
"Thushya", the Guided Consolidation tool within vCenter will provide that data for you. You can read more about it on pg. 89 of the Basic Admin Guide for vSphere:
http://www.vmware.com/pdf/vsphere4/r40/vsp_40_admin_guide.pdf

~coolsport00
0
ThushyaAuthor Commented:
Thanks coolsport,
Do i need to specify RDM for database or its just a good practice ?
0
coolsport00Commented:
Well...it's good practice to keep as much data on a SAN as possible. That way you can just connect the data to your VM and continue backing it up with your traditional b/u methods; performance is better using RDMs as well. Plus, it's good for failover since usually you're using RAID configuration within a SAN.

~coolsport00
0
Matthew EnglandTechnology ConsultantCommented:
== How can I calculate the resource for each server? ==
First thing you'll want to do... If you do not already have performance metrics for your systems, is to start capturing it. How you do this is up to you, either using built in tools such as perfmon, or using an enterprise monitoring system. At the most basic level, what you want to see is your averge CPU utilization, memory utilization & network utilization over a period of not less than a week. You'll also want to capture disk I/O, and make a table of all your servers, with listing their attached storage drives, including their total & used capacities.

To size the memory allocation, the virtual machine memory size should be slightly larger than the average system memory usage. Watch for VM paging and increase the size if needed, but refrain from increasing memory in excess, as this will also increase the required overhead memory required for a host system.

As for processor allocation, for most systems, a single virtual processor will be sufficient unless your physical system is consistently utilizing more than about 25% Again, a second can be added if needed.

Consult the vendor documentation for the OS/Application you're planning to virtualize. Ensure it's supported & verify the minimum requirements. Some vendors will provide specific baselines for Virtual environments, such as this document with Exchange, which also references several Microsoft articles.
http://www.vmware.com/files/pdf/solutions/design_size_examples_exchange.pdf

I rarely use Resource Limits, but if you need to, such as for your database systems, or larger Exchange systems, this document will be helpful:
http://www.vmware.com/pdf/vsphere4/r40/vsp_40_resource_mgmt.pdf
http://www.vmware.com/files/pdf/solutions/design_size_examples_exchange.pdf

For resource allocation, I prefer to start low. You can always add virtual memory & CPU's & expand virtual disks, but it's much more difficult to reduce them later if you find that you over allocated. One of the exceptions to this rule is with Oracle databases.

== How can I confirm if they are good for virtualization or not? ==
Would it be correct in assuming you're planning to use VMWare Converter for the conversion?
It sounds like you're mostly talking about Windows servers, which don't appear to be too old, so you should be relatively safe, although there really is no surefire way to determine if the machine will start up properly after conversion, except to just do it and see. The most common issues you'll see are pertaining to drivers (especially the NIC), and you'll likely need to plan to re-configure the NIC if you're not using DHCP, so ensure you have the IP's, NetMasks, Gateways & DNS documented and handy.

You'll want to reference the VMWare compatibility guides:
http://www.vmware.com/resources/compatibility/search.php
This will give you a system by system picture of what to plan for, and help you to determine if a system is acceptable for conversion or if you'll want to rebuild it.

== Anything else you would like to recommend? ==
Fault tolerance... One of the most common mistakes I see at client sites, is they virtualize all their servers, (a good thing), but they're running them off local SATA disks or if they have a SAN, it's a single fibre channel switch or single disk controller. Under stand the implications of a failure of any single component & how that will affect your systems. Test it. Know how to recover before you need to.

SnapShots... Use them sparingly. Snap shots are great, especially when needing to apply patches, but they should never be left running for an extended period & there's rarely any reason to have more than one on a production system. All too often I'm called in to fix performance issues and I find production systems running for months with one or more snapshots. Snapshots degrade system performance over time, and ultimately will need to be committed. The longer they run, the longer it will take to commit them, and when they take too long administrators get impatient and thing the systems hung. It's also a poor use of disk space.

Configure windows (Storage/Disk Manager) to use Dynamic Disks. (Right click on the disk and select Convert to Dynamic) This will allow you to expand the VMDK in VMWare, then go in to windows and dynamically expand the partition without having to take the server offline.

== Any suggestion moving database servers to virtualization? ==
What platform and database application are you running? If these are system support databases, such as supporting internal applications like SMS/SCCM, Ops Manager, Remedy, etc, I would suggest to go ahead an plan to virtualize them along with your other systems. If these are high transaction systems, or HA configurations, more planning will be required to successfully virtualize them, if desired. There's no problem leaving these till later. (Unless there's a technical or business driver for doing so now.) Start with the easier systems, prove your virtual environment is efficient and reliable, and allow your self and other admins to get comfortable working in it. Then you can plan to virtualize the databases as a phase two.

I know that this is a little bit generic, but I hope you find it to be helpful all the same. When you're planning for virtualizing existing systems, especially larger or heavily used ones the process can be a bit tedious, but just remember you can always grow. Monitor the systems closely after they're virtualized. If you see consistent heavy resource utilization, make a plan to adjust resources, or vMotion, the system on to a different blade.

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ThushyaAuthor Commented:
thx
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
VMware

From novice to tech pro — start learning today.