I have a customer with an currently running environment with a VMFS 2.11 datastore. This datastore contains VMDKs for up to 6 servers. There are several datastores that are configured in this way, in total containing nearly 200 servers.
I intend to copy a servers' VMDK files to a VMFS3 datastore, and would like to know if there will be any performance issues to the existing servers due to this process.
If there are any performance issues, can you recommend a process other than taking snap clones of the datastores, which the customer is reluctant to do, to mitigate the performance impact on the other servers.
>> would like to know if there will be any performance issues to the existing servers due to this process.
I assume you mean on the ESX3/VMFS3 side of the transfer. It would depend upon:
a. how many copies are taking place simultaneously
b. the bandwidth of the storage you are reading from
c. the bandwith of the storage you are sending to
d. bandwidth being used by running VMs on target side
e. bandwidth of transport mechanism (LAN, SAN)
f. the total amount of data to be transfered
g. SLA or QOS agreements in place on these hosts? Will they be violated?
Too many variables for us to answer. You'll have to do some good old fashioned benchmarking and testing to know for sure.
my 2 cents
Existing VMFS2 datastore has been configured as 100GB LUNs, containing multiple VMDKs (production servers). They are going to be migrated to a single LUN per VM on the VI3 side, so no performance issue there.
if u r going for a full fledge migration to VI3 u have to go ahead with satisfying all the recomondations from VMWare. ..if u want i can give you the link which can assist u in migration...
if not plz make clear your needs..
Not going to touch the old vmfs2 datastore, just going to migrate the servers out that currently reside there, and want to know if there will be a performance degredation on the current production servers in the VMFS2 datastore, whilst this process is being performed.
are u going to use the dmotion route, u can copy running vms from a 2.x host to a 3.x host, there will be a overhead on the i/o for this but depending on what u are running it should be no problem.
No, VMotion will not be used.
We are going to shut down one of the servers in the VMFS2 datastore, cold migrate the associated vmdks for this server to the VMFS3 datastore, and then start up the server, upgrade VMware tools etc.
Will there be a performance impact to production servers still running in the VMFS2 datastore?
Yes there will be, u will be taking reads from the LUN, however will this impact the performance of the running vms ?? it depends on what their i/o requirements are.
why do you want to do it cold, dmotion works great and u can do it live so less downtime.
We don't want to VMotion, as this leaves the VMDKs in the original location.
We need to move the VMDKs for a server to their own LUNs running a VMFS3 datastore for DR purposes, so that they can fail over an individual server, rather than the group of servers currently running in the VMFS2 datastore.
>> Will there be a performance impact to production servers still running in the VMFS2 datastore?
Performance issues?? Still not sure what you define as performance issue. If you are worried about SCSI reservation errors and starving the VMs during migration, again that would require benchmark/testing scenario as everyones environment is different.
Add a REDO to a 2.5.x VM, and copy its base VMDK to the desired destination. While the copy is going on, tail -f /var/log/vmkernel, and see if any errors occur while copy in progress.
Now try it again, this time placing one of the 2.5.x VMs residing on the source LUN under load. No with VM busy and copy going on, tail the vmkernel log. Any errors?
Perform a known task in a source 2.5.x VM and time it. Now perform same task again, but with VMDK copy going on. Still same results?
Only YOU can guage the performance and capabilities of YOUR servers.
my 2 cents
I have done this as one migration method for several servers and not have noticed any performance problems. Most of these were small servers which did not take very long, a few were mid sized servers (20-40 GB) and those took close to an hour. Not knowing your environment, build a small test server on one of these luns you will be migrating from and run a test during the time frame when you would like to migrate these. Your other option is to do this during a maintenance window where people might expect unavailability or slower performance.
Like I said, I would not expect you to see any performance problems, but I do not know your environment, and I will not have to answer the questions if there are any, so you need to be comfortable. If all of these servers are very i/o intensive[/i], then I would lean toward moving the smallest one first during a maintenance window just to be on the safe side. Leave the most i/o intensive servers for the end.
P.S. You may want to do a clone rather than a cold migration. That way you have a backup copy on the old datastore "just in case". After we did our first migration we noticed that the old server was removed after the migration was over. Everything worked perfectly, and if there is an error it does not remove the original server, but its always good practice to have a backup or plan B.