Virtualising a physical system - which approach to take?

[JonRoderick]

I'd be interested to hear from people who have undertaken any complete physical to virtual application migrations.

It appears to me that we have the option to rationalise the system during the conversion process but this will add pain to the overall task.

Do people recommend just copying the physical system to a virtual one and then revisting the system at a later date or are there quick wins in looking at whether the physical architecture can be improved on in the virtual world.

Thanks

[ZMkenzie]

Use vmware converter, you can download the free edition from vmware.com, it will do all the job needed. I'd suggest you to reduce the disks size during the process to rationalize the space (SAN is expensive). The converter will do this for you.

Just this, everything else should run smooth. Just check if it's a good idea or not to virtualize a machine, usually heavy loaded machines (>60% cpu load) are not suitable for virtualization.

[MR-T]

I think the process of moving from Physical to Virtual is a big task on its own.

The best approach would be to P2V your existing servers first and then use that technology to test further changes.

So for example, you could P2V an application server and then take a clone of this in your ESX environment to test any application specific consolidation.

Does this make sense?

You've also got the chance to use snapshots in the VM's which you can't do in the physical so you've got a roll-back choice.

[esiebert7625]

Virtual servers have alot of advantages over physical ones. VMware converter is a good free product for virtualizing your physical servers. Using Converter you can re-size your server disks so you are not wasting unnecessary disk space on the VMware host server. Once a server has been converted to virtual you have alot more flexibility with what you can do with it compared to a physical server. In my case I moved all my physical servers to virtual using Converter and afterwards consolidated and re-configured the virtual servers. Of course if you plan ahead you can save yourself some work later.

Here's some links on Converter...

Server Migrations with Vmware Converter - http://www.vmware-tsx.com/download.php?asset_id=48

Converter tutorial - http://www.petri.co.il/virtual_convert_physical_machines_to_virtual_machines_with_vmware_converter.h...

Introducing the Next Generation of P2V: Vmware Converter 3.0 - http://download3.vmware.com/vmworld/2006/tac9453.pdf

Converter FAQ - http://www.vmware.com/products/converter/faqs.html

Converter Manual - http://www.vmware.com/pdf/VMware_Converter_manual.pdf

Converter Release Notes - http://www.vmware.com/support/converter/doc/releasenotes_conv3.html

Converter Data Sheet - http://www.vmware.com/pdf/converter_datasheet.pdf

Converter download - http://www.vmware.com/download/converter/

Fyi…if you find this post helpful, please award points using the Helpful/Correct buttons.

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

Thanks, Eric

Visit my website: http://vmware-land.com

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

[JonRoderick]

Thanks for the replies so far guys...

I'm thinking I didn't explain my question clearly enough.

Aside from the technical aspects of P2Ving a group of application servers (call them the 'system'), is it better to re-evaluate the system architecture at the P2V point or revisit it at a later date, once the virtual system has bedded in and the application team are all happy etc etc.

To be honest, the P2V technical stuff is the easy bit - it's all the other 'soft' stuff that I think will cause us the greatest headache.

Getting and ESX infrastructure up and running isn't even half the job!

Again, appreciate any replies

[JonRoderick]

Then again, maybe I didn't read your replies well enough...

So the general approach is to virtualise, sit back for a bit and then look at rationalising the system.

Wouldn't it be more difficult to persuade the application team to modify their system design after it has been bedded in and is working great (which it no doubt will!)?

Seems like I could just be delaying the pain!

[ZMkenzie]

If you virtualize your systems one by one your architecture wont change. The machines will be unchanged, same ip, some applications, services and so on. You just need to understand how much hardware you need to virtualize your systems, how much cpu they use and so on. Just that. You should just not care if they are physical or virtual, it's like migrating machines from a disk to another, nothing changes.

So, i'd suggest you to buy/take 1 big server, install esx, and move there less important machines, so you start to have confidence with the instrument and you start having an idea about resources used by your server. After that, buy a SAN and a lot of hardware to accomodate all the rest. You should carefully measure that.

Hope this helps.

Bye.

[MR-T]

I think I didn't understand what you were asking.

I thought you were trying to consolidate application and virtualise at the same time.

This is why I would split the 2 out.

If you're simply thinking of redesigning the setup, why not do this now.

[esiebert7625]

With planning you can take into account your new design as part of the conversion process. You'll definitely want to visualize how you want your new environment to look when it's all done. I'd start by making before and after diagrams and planning out the steps you'll need to take to get there. You will have alot more flexibility with virtual machines so if you need to reduce or increase certain hardware settings (cpu/memory/disk) you can easily do this at any time.

[JonRoderick]

Thanks for the help.

It sounds as though reviewing the architecture at the P2V point has definite benefits.

Cheers

[Ryan_Witschger]

If I am understanding you correctly, you are asking when to best re-evaluate resources given to to the machines. The answer to this all depends on your project plan as it can be done at any given time.

For instance, the company I work for jsut bought another smaller company. To move their data center of 40 servers we decided to virtualize them all and move them as one blade chassis. We didn't have any back ground of usage on the servers - memory/CPU/Disk. so we decided to virtualize with what they were currently running and evaluate later.

However, in our own datacenter when we go to virtualize a machine we take a baseline on it's usage and create the virtual machine around that to not waste any resources.

So the answer as I see it:

VMWare makes it easy to quickly add resources such as memory and number of processors. You have very little downtime and can manage the task from the comfort of your couch. If you do not know the current usage of the physical machine, then you should first measure the usage of the virtual machine before you make the desicion to reduce.

[mvoss18]

Reviewing the architecture when you perform the P2V is definitely a good thing to do if you have the time to plan. If your project just wishes to reduce the physical footprint and rapidly do P2Vs that's another option. You can rearchitect afterwards if you wish--it all comes down to your timelines.

We were doing P2V with print servers and I pushed to rearchitect the print queue configurations. My boss thought that was too much effort and just decided to P2V as is. In this case, redoing the architecture will take place after the P2V.