VMware Cloud Community
FaTony
Contributor
Contributor
Jump to solution

Change migrated VM harddisk vmdk fileName / datastore reference

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

0 Kudos
1 Solution

Accepted Solutions
LucD
Leadership
Leadership
Jump to solution

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

View solution in original post

0 Kudos
6 Replies
LucD
Leadership
Leadership
Jump to solution

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

0 Kudos
FaTony
Contributor
Contributor
Jump to solution

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

0 Kudos
LucD
Leadership
Leadership
Jump to solution

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

0 Kudos
FaTony
Contributor
Contributor
Jump to solution

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

0 Kudos
FaTony
Contributor
Contributor
Jump to solution

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

0 Kudos
LucD
Leadership
Leadership
Jump to solution

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

0 Kudos