Converting & Running Exchange 2007 under ESX 3.5

Hi all,

I'm looking at migrating our exchange 2007 environment to a VM, however have a few questions first and any feedback would be appreciated!

Has anyone had experience both running ES2007 within a virtual machine, and if so, did you build the server 'from scratch' or did you convert an existing physical machine?

My biggest problem at the moment is that whilst I need to run Exchange 2007 virtually, I also need to turn the server it's currently running on into an ESX host.

Should I create a new exchange server within a brand new VM and migrate the content across to it, or convert? We've also just installed an iSCSI storage array & would like to store the exchange databases on there, rather than within the VM itself.

Any help appreciated!


Tags (2)
0 Kudos
7 Replies


With your scenario you are best off creating the Exchange VM from scratch. Then assigning the storage from the iSCSI array directly to the VM. It's a much cleaner migration than P2V. This way you virtualize and move the storage in a much simpler scenario. Just make sure you allocate enough RAM to the exchange 2007 server.

0 Kudos

Lurks through these links it should give you plenty of details for P2V process and how you can do it right with Exchange 2007 as well.


Boot.ini file -

Guide to P2V 2.x -

Server Migrations with Vmware Converter -

Vmware P2V Assistant Best Practices -

Converter tutorial -

Introducing the Next Generation of P2V: Vmware Converter 3.0 -

VMware Converter Best Practices (VMworld 2007) -

Converter FAQ -

Import of physical machine fails -

Ultimate P2V -

EZ P2V -

VMware P2V and Virtual Machine Importer -

What machines should not be converted -

Remove non-present devices from converted system - and

Updating devices in the new virtual machine -


|http://www.vmware.com/support/p2v21/doc/updatedevices7.htmlLinux]Linux conversion -

Linux conversion -

Virtualize a Linux Server with VmWare Converter 3.0.1 -

Linux P2V -

Migrate 2.5.x VM with Converter and no VC - and

Change HAL from multi to uni -

Converter snapshot during hot migration -

P2V Product Comparison -

Post P2V Clean-up procedures -

Converting VM back to Physical Server -

Virtual Machine to Physical Machine Migration -

Best practices for troubleshooting VMware Converter - New - 5/1/08

Using VMware Converter for P2V migration (Pt. 1) - New - 5/1/08

Conducting hot P2V migrations with VMware Converter (Pt. 2) - New - 5/1/08

Troubleshooting failed VMware Converter P2V migrations (Pt. 3) - New - 5/1/08

For more go to www.vmware-land.com for details.

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!


Stefan Nguyen

iGeek Systems Inc.

VMware, Citrix, Microsoft Consultant

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!! Regards, Stefan Nguyen VMware vExpert 2009 iGeek Systems Inc. VMware vExpert, VCP 3 & 4, VSP, VTSP, CCA, CCEA, CCNA, MCSA, EMCSE, EMCISA
0 Kudos

Hi David, I just recently built a DR scenario for Exchange 2007 using CCR. With physical on production end and virtual on DR end. Using ESX 3.5, VC 2.5, and an iSCSI SAN at DR site and FC SAN at prod site. EXchange databases and log files on SAN.

Things to note are -

  • again agree with above about building servers from scratch - cleaner and simpler

  • SAN - used RAID 1+0 for db on own array with many spindles, then LUN, and then 1 datastore - for performance

  • SAN - used RAID 1 for log files on own array, then LUN, and then 1 datastore - for performance

  • SAN - used RAID 5 for Exchange server C drive on LUN with other VMs

  • CPU allocated - 2 (dependant upon number of users and mailbox size) - no limits or reservations set (again configured to suit my virtual environment)

  • RAM allocated - 4GB (dependant upon number of users and mailbox size) - no limits or reservations set (again configured to suit my virtual environment)

  • use this Exchange Storage Sizing Calculator for guide - http://msexchangeteam.com/files/12/attachments/entry438481.aspx


0 Kudos

I am getting ready to put exchange on my esx configuration using an iscsi san. I was wondering if i should put the data and log files into vmdks or use a software initiator to connect to the iscsi san from within the Windows virtual machine? all of my systems have hardware initiators on them right now.. Ive never messed with the software initiator from within vmware - so Im not sure even how that would be configured!

0 Kudos

You'll need to allocate storage from somewhere to the virtual machine before the guest operating system can see that it has new disk. The storage you present to the guest can be from local drives, an iSCSI device or other sort of SAN, as well as NAS and DAS.

I understand that what your talking about is presenting the iSCSI device to you VM directly and using the guest operating system software iSCSI initiator - which in theory might work. But where are you storing your guests C drive? On local storage formatted as VMFS? Or on some other SAN device? I'm not sure of the implications (read: performance of disk in VM) if you were to present the iSCSI storage directly to the VM. I have all of my VM vmdk files on the iSCSI storage in different arrays for performance.

Here's the VMware guide to configuring ESX for use with ISCSI storage - http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_iscsi_san_cfg.pdf


0 Kudos


I was going to store the guest C drive on the iSCSI storage so that we can swap the VM between hosts if need be, although hopefully we won't have to... the idea is to run ESX on the box and have exchange the only VM on it. The boot partition's not the problem - it's where to locate the exchange databases.

Would it be recommended to mount one of the LUNs (which is formatted as NTFS and attached to a fileserver) into the VM and use it as a normal disk, or would it be better to use a different vmdk on the same iSCSI storage as the VM host?

0 Kudos

Ok so the question is - whether to present the LUN to the ESX server or the guest OS of the VM. Again in theory it seems possible to present the LUN to the VM. What I know about iSCSI software initiators is that the CPU is used to handle the iSCSI commands. So what this amounts to is that if you present the LUN to the ESX servers (using the iSCSI software intiator) then it's the ESX server/s CPU that will be doing the processing and not the VM. And if you present the LUN to the VM then it's the VM's CPU that will processing the iSCSI commands, which will impact upon the performance of the VM.

As it stands I've never heard of presenting the iSCSI devices directly to the VMs - which doesn't mean that it can't or shouldn't be done.

Secondly, I'd be warey of putting the database and log VMDK files on the same LUN as the C drive VMDK file. Microsoft have 'best practise' for storage with Exchange - http://technet.microsoft.com/en-us/library/bb124518.aspx . And if you're using RDM disks the entiore LUN is present as one disk to the VM. It's then up to you as to how you partition the disk on the guest OS level. Here's VMware's findings on the difference on IO between using VMDK and RDM disks.... http://www.vmware.com/files/pdf/performance_char_vmfs_rdm.pdf

Hope that helps