Hi All
I'm in the process of migrating a large number of VMs between physical datacenters (using SAN mirroring as the migration method).
The problem I've run into is that the OS and Data vmdk's are located on different datastores for each VM. When we break the mirror and register the VMX at the new location, the VMX file references the old path to the VMDK files (ie: the old datastore at the source datacenter). Only the VMDK files located in the same folder as the VMX file appear correctly in the vSphere client - the others appears with size of '0 GB' - as vSphere can't find the referenced vmdk files.
I don't want to update the VMX files manually, obviously as that's why I'm here. 🙂 But I've struggled to find a solution to updating the harddisk vmdk fileName using PowerCLI.
Do I need to resort to pure PowerShell and update the vmx file this way?
I've read all the blogs on updating vmx files - but they all demonstrate updating the 'extraconfig' extension data. eg:
http://blogs.vmware.com/vipowershell/2008/09/changing-vmx-fi.html
This extraconfig does not include the lines in the VMX file which specify the vmdk fileName. eg:
scsi0:1.fileName = "/vmfs/volumes/abcdefgh-503544b2-e46c-d41234567890/myVmName/myVmName_1.vmdk"
Ideally I would have liked to use the set-harddisk command - sadly this actually tries to move the non-existent vmdk to the new datastore I specify - rather than just update the datastore reference.
I'm hoping someone here can tell me an efficent solution - without having to read in vmx files and modify them using PowerShell.
Oh, and I've already written a script to output the list of VMDK files attached to each VM (on the source datacenter before deregistering the migrated VMs) - so I have my CSV input ready to use with a workable solution.
Any help much appreciated!
Thanks
FaTony
If you have the list with the VMDK at the source, and you know how to translate these paths to the new location, you should be able to use the Remove-Harddisk and New-Harddisk cmdlets.
Did you already try that ?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
If you have the list with the VMDK at the source, and you know how to translate these paths to the new location, you should be able to use the Remove-Harddisk and New-Harddisk cmdlets.
Did you already try that ?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Hi LucD
First responder as usual - you're a true treasure to this community!
Well the good thing is the datastores are named identical at both source and destination - so that part is easy.
I've thought about using those commands, but was hoping for something less intrusive. However, LucD has spoken - so I will try this way now.
... From just a beginner to a pro - You'll need a montage - Always fade out in a montage...
That works! Just tried it out. However I'm going to have to do some mucking about with the SCSI controller assignments and SCSI IDs - or at least check these don't change.
Thanks again!
Cheers
FaTony
Thanks :smileygrin:
Watch out with the SCSI IDs !
There have been threads that raised that point as well, the basic trick is to save the SCSI ID number as well in the VMDK path export you did.
Then use that SCSI ID to organise the order in which you do the New-Harddisk cmdlet.
The ID assignments are normally done by vSphere in a sequential order.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Yip, that's my plan now. I had already exported the controllerBusNumber and harddiskUnitNumber (forms the x:x SCSI id) in my CSV - so I'm ready to rock.
Thanks again for your advice.
Cheers
FaTony
An update for those who are interested:
I have used the remove-harrddisk and new-harddisk cmdlets to do my VMDK filename changes, as suggested by LucD.
However, I believe I've run into a PowerCLI bug!
When you create a new harddisk on a new scsi controller (the second SCSI controller in these examples), eg:
New-Harddisk -VM bruce -Datastore mybigdatastore -Capacity 1024 | New-ScsiController -Type paravirtual -Confirm:$false
The SCSI ID assigned starts at Harddisk BusNumber '1'. The first disk should start at '0'. So we get the first SCSI ID of 'SCSI (1:1)' rather than 'SCSI (1:0)'.
This bug is further backed up by the behaviour of Set-Harddisk; when you create a new disk and assign to the new controller, eg:
New-Harddisk -VM bruce -Datastore mybigdatastore -Capacity 1024 | Set-Harddisk -Controller "SCSI contoller 1" -Confirm:$false
The harddisk BusNumber assigned is '0'!! So now the second disk added to the controller has a SCSI ID of 'SCSI (1:0)'!
If order matters, which it does in my case - we're not always using lvm's for instance, then the above behaviour makes assiging the same SCSI IDs at the new datacenter very painful (on mass).
I'll be logging a ticket with VMware Support. Though happy for someone to tell me that counting start at '1' or '0' depending on how you hold... the keyboard. 🙂
Enjoy
FaTony
That looks indeed like a "feature" :smileygrin:
As a temporary bypass you could use my Add-HD function from Adding an existing hard disk
That starts with device ID 0.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference