XenDesktop: Migrating dedicated catalog to another datastore

If you are looking to move your virtual machines to another datastore chances are you have already come across this Citrix article: How to Migrate Dedicated Catalog to Another Datastore.

Last week I have unsuccessfully attempted to follow it and thought I would clarify a couple of ambiguous points in the guide and it’s indented application.

First of all I need to point out that if you intend to move your base image file this guide isn’t going to do it for you. While you are asked to copy the base image to the new datastore it doesn’t tell you to delete it from the old location. This is because all the delta disks you move will still be referencing the original base image file location. So if you are hoping to decommission  some old storage and need everything to move, Citrix recommend you convert the linked clones to full clones – you can achieve this by a simple storage migration in vSphere. You can then remove them from the catalog and add again as existing. There is an inevitable increased storage requirement which is what you were probably trying to avoid in the first place but it is the safest and most reliable way of doing this.

You could also look at editing the vmdk configuration files of your moved VMs and setting parentFileNameHint to the new file path – I will delve deeper into this in a future post.

If the Citrix guide still fits the bill for you here are the parts that I found slightly unclear. Some of them may seem obvious but as I things weren’t working out for me I was questioning every step.

Step 5:

Copy vmdk to new storage.

VMware PowerCli command:

Copy-DatastoreItem 'vmstore:\vc-servername\source_datastore\ contosow7-baseDisk-datastore-11\*' 'vmstore:\vc-servername\dest_datastore\ contosow7-baseDisk-datastore-11\' -Force

After copy has been completed, base disk will be converted to thick format; diff disk will remain thin-provisioned.

What Citrix want you to do here is to copy all your machine’s deltas and the base image file over to the new datastore. The command above assumes they are all within the same folder (contosow7-baseDisk-datastore-11) but depending on how you have the files organised you might need to copy the base image file separately. You will also likely have your vmx and other configuration files in the same location and these will be copied over at the same time. These won’t be used for anything as when you recreate the machines a new folder will be create for each one. In effect there will a be some doubling up but nothing to worry about as the storage use will be negligible. You can also manually copy the files using the vSphere client and the effect will be the same.

Step 6:

Back up the base and diff disk folder defined in the filename column of the contoso_disk.csv file. Delete the machines to be migrated through the desktop studio console and choose the options to “Remove the accounts from the Catalog but do not remove them from Active Directory”.

You should already have  a copy of all this on your new datastore but you might want to backup within the same datastore to reduce the restore time if required. When you delete the machines from the catalog the diff disks will be deleted but the base image will remain intact anyway.

Step 7:

Create new machines with existing disks. (Import.csv) file is used with the columns shown in the following table.

VMName LastConnectionUser OldDiskPath NewDiskPath
contosow7AAA contoso\user1 [source_datastore] contosow7-baseDisk-datastore-11/contosow7-baseDisk-datastore-217-000005.vmdk [dest_datastore] contosow7-baseDisk-datastore-11/contosow7-baseDisk-datastore-217-000005.vmdk

VMware PowerCli command:
Import-Csv importcsv.csv -UseCulture | %{
$vm = New-VM -Name $_.VMName -VMHost 20.10.102.12 -MemoryMB 2048 -NumCpu 2 -GuestId “windows7_64Guest” -NetworkName “VLAN 123”  -Datastore “Dest_Datastore” -DiskPath $_.NewDiskPath
}

The OldDiskPath isn’t used during the machine creation at all so you don’t need to worry about it too much. The NewDiskPath is the path for the machine’s delta – not the base image file.

Hope this helps to avoid at least some of the confusion.

Advertisements

Did you know?

Well I didn’t. More specifically I didn’t know that Server 2008 behaves quite differently to 2003 when it comes to choosing a source IP address on a server with multiple IP addresses on the same interface.

Previously on Server 2003 the source address would be the primary address on the interface in question. This address would also register in DNS. Server 2008 and higher uses the address which has the most bits in common with the default gateway. This is worked out in binary and I won’t bore you with the details. To make this a little bit easier on us Microsoft have released a hotfix which introduces the SkipAsSource flag. To use it you have to remove the IP addresses and re-add them using the netsh command.

For example:

netsh Int IPv4 Add Address <Interface Name> <IP Address> SkipAsSource=True

To check that the command worked as expected run:

Netsh int ipv4 show ipaddresses level=verbose

You should see something like this:

skipassource

In case you can’t see the Skip as Source setting you still need the install the hotfix above.

You would hope that you’re done at this stage but there are some issues with this hotfix and you will need to install two more:

 

KB2554859: The “skipassource” flag of IP addresses is cleared after you use the GUI to change IP settings of a network adapter in Windows 7 or in Windows Server 2008 R2

KB2551090: IIS Manager does not display IP addresses that are assigned to the network adapter together with the skipassource flag

This does the trick and gives you control over which addresses are registered in DNS and used as source.

References:

https://blogs.technet.microsoft.com/networking/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer/

http://blogs.technet.com/b/rmilne/archive/2012/02/08/fine-grained-control-when-registering-multiple-ips.aspx#pi63079=2