VMware Cloud Community
HelgeL
Enthusiast
Enthusiast
Jump to solution

Can I storage vMotion two vm's with shared disks?

I have one ESX 3.0.2 server with local storage and two ESX 3.5 servers with fibre channel SAN. Two VM's share several disks and run on the macine with only local storage. Can i use storage vMotion to move these to one of the 3.5 servers and over to the SAN?

If not; can I migrate the servers (when they are shut down) to the SAN and 3.5 servers without breaking the links to the shared disks?

Reply
0 Kudos
1 Solution

Accepted Solutions
bulletprooffool
Champion
Champion
Jump to solution

If you shut the VMs and migrate them, you should be able to access the disks - as the sVmotion will update the pointers in the vmx file.

If you do migrate and lose access to the disk, all you'll need to do is open the.vmx file for each VM and update the path specified for each disk, not too difficult to fix at all. - If you don't fancy that, you can simply remove and re-add the disk in the VM properties

One day I will virtualise myself . . .

View solution in original post

Reply
0 Kudos
7 Replies
AWo
Immortal
Immortal
Jump to solution

I have one ESX 3.0.2 server with local storage and two ESX 3.5 servers with fibre channel SAN. Two VM's share several disks and run on the macine with only local storage. Can i use storage vMotion to move these to one of the 3.5 servers and over to the SAN?

Should work...

If not; can I migrate the servers (when they are shut down) to the SAN and 3.5 servers

Works.

without breaking the links to the shared disks?

Hmmm, two guests owning one .vmdk? It might be necessary to move the shared disk with one guest and when you move the second guest to point to the new location of the disk again if they end up on different datastores. If the two guests are on the same datastore the relative paths pointing to the .vmdks should still work.


AWo

VCP / VMware vEXPERT 2009

      • I rent firewood out ***

vExpert 2009/10/11 [:o]===[o:] [: ]o=o[ :] = Save forests! rent firewood! =
bulletprooffool
Champion
Champion
Jump to solution

If you shut the VMs and migrate them, you should be able to access the disks - as the sVmotion will update the pointers in the vmx file.

If you do migrate and lose access to the disk, all you'll need to do is open the.vmx file for each VM and update the path specified for each disk, not too difficult to fix at all. - If you don't fancy that, you can simply remove and re-add the disk in the VM properties

One day I will virtualise myself . . .
Reply
0 Kudos
Gerrit_Lehr
Commander
Commander
Jump to solution

I'd not risk it and migrate the VMs together when they are both offline.

Kind Regards,

Gerrit Lehr

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

Kind regards, Gerrit Lehr If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".
Reply
0 Kudos
HelgeL
Enthusiast
Enthusiast
Jump to solution

I shut down both VM's before migrating. To get both VM's to the SAN I had to first copy the "master" VM (the one with all the HDD's) to a temp dir before I migrated it to the SAN. Then copy the temp back to the original folder. Then I could migrate the "slave" VM (The one with links to the master HDD's) to the SAN. I now have a working master and a slave with its own copy of the HDD's. I'm planing to modify the .vmx file to point them to the master disks today.

I tried to move the master first, and then the slave without the temp copying, but that resulted in an error when I migrated the slave stating that it could not access the files on the master.

Migrating the slave first and then the master gave the same result as my final solution for the slave, but the master could not access it's shared HDD's

A little additional question about changing the .vmx file:

When In tested this on two dummy macines and changed the .vmx file to reflect the real location of the .vmdk files for the slave after the migration, the vCenter did not reflect the change. If i checked the "Disk File" setting in Virtual Machine Properties it still comes up as if it is stored with the VM. Is there a way to get the vCenter to update it's info? And does it really matter for the VM that it shows it wrong? Or have I misunderstood and there are more settings in the .vmx file than

"scsi 1.0:.fileName="<folderlocation>/<shared master HDD>.vmdk" that needs to be edited?

Reply
0 Kudos
Gerrit_Lehr
Commander
Commander
Jump to solution

You will either have to remove and readd the VM to ther inventory to see the changes in VCenter or you can use vimsh from the service console:

First Run vimsh -ne "vmsvc/getallvms" | grep <yourvm> to get the VMID of your VM (first number in the line)

Then run vimsh -ne "vmsvc/reload<VMID>" and after a few seconds the VM should be updated in VCenter / VICLient.

Kind Regards,

Gerrit Lehr

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

Kind regards, Gerrit Lehr If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".
HelgeL
Enthusiast
Enthusiast
Jump to solution

First Run vimsh -ne "vmsvc/getallvms" | grep <yourvm> to get the VMID of your VM (first number in the line)

Running this command doesn't give me a VMID. The output:

File : [[storage2_raid0]]ldsvmrac1/ldsvmrac1.vmx

Reply
0 Kudos
HelgeL
Enthusiast
Enthusiast
Jump to solution

I removed the VM from the system and added it again. Worked lika a charm.

Thanks everyone

Reply
0 Kudos