Shared Read-Only LUN migration

[ktwebb68]

Interesting problem here. Been migrating VM's from our 2.X environment to Vi3. Installing fresh 3.02 and running VC 2.01. I have been using ESX migrator and have been relatively pleased with how it's been going and the pace.

I am getting down to Windows Cluster VM's and talking the App owners/developers into breaking the windows cluster and just going with HA as redundancy is the primary reason we've been running the VM's in a windows cluster. Don't want to do RDM or windows clustering in Vi3. Anyway, one of the last servers I have to move is a file and print box with very large LUN's. 1.6TB from a Nexsan AtaBeast patched into the fabric. And there are alot of them. 8 to be precise. Not all with data on them. I believe only 4 actually have data we'd need to move but there are ALOT of resources mapped to these drives.

My question is, what is the most graceful way to migrate those over to the new environment? So far I've been getting new storage presented to the Vi3 blades and just doing the copy with ESX Migrator. Not going to be able to do that here. It's just an FnP so I could just load a fresh copy of windows, remove the LUNS not being used in the old env, present them in the new and run a restore from backups. That's one way. I was hoping there might be an easier way and am just not coming up with anything. Probably right in front of me but I am going over scenarios and all have their gotchas so far. Any ideas? n Is there a way to upgrade the Read Only VMFS2 LUN's to VMFS3 LUNS by doing an upgrade of the ESX OS instead of a fresh install and migrating the VM's? Will that work do you think?

[Texiwill]

Hello,

The upgrade method is as follows for Clusters

\- Backup ALL data within the VMs.

It is STRONGLY recommended that you move all Shared VMDKs to RDMs. RDMs work much better for clustering in VI3.

\- Shutdown all VMs using shared access mode.

\- Disconnect shared VMDKs/RDMs from VM.

\- Move Boot drives to local storage on VI3. (Yes they belong on local storage not SAN or any other form of remote storage.)

\- Change access mode of VMFS-2 from shared to public

\- Perform migration of VMFS-2 to VMFS-3

\- Reconnect shared VMDKs/RDMs to VMs (again it is much better to use RDMs)

\- Boot VMs and fix anything else that is needed to be fixed at the OS level Microsoft.

I am not sure why you do not want to use RDMs. For a 1.6TB fileserver, I would use RDMs for the data portions and VMDK for the boot volume. Actually I use Virtual mode RDMs for anything greater than or equal to 250GB.

Also using RDMs allows you to make clusters using physical and virtual machines and up to 8 physical or virtual machines can be part of the cluster with RDMs.

Best regards,

Edward

[ktwebb68]

Thanks for the input but we're booting from SAN for ESX. No local storage and the windows cluster will be broken as mentioned. Not doing RDM. We'll keep the it as is. I am just looking for a graceful way to do it. I would think the upgrade of the Host OS will work. I imagine the virtual hardware upgrade process to VMFS3 will take forever though.

[Texiwill]

Hello,

Boot from SAN and MSCS is mutually exclusive however NLB is not. Not sure HOW you got it to work in ESX v2. It should not work and generally does not work inside VI3. But more power to you if you did. Since you are breaking MSCS then your worries are over.

You need to change all shared access mode VMFS-2s to public access mode. Shared access mode is not the same as a shared VMFS-2. There is a lot of confusion about this. 'access mode' is a VMFS-2 property. shared VMFS is just a VMFS shared between multiple hosts. So actually I am not quite sure which you are talking about.

Still your steps are:

\- Back up VMs

\- shutdown VMs

\- change 'shared access mode' VMFS-2 to be 'public access mode' VMFS-2

\- Migrate VMFS-2 to VMFS-3

\- Break your clusters, etc.

Best regards,

Edward

[ktwebb68]

The 2.X environment was installed on local storage.

Access mode is shared and shows read only shared in the MUI. We can take that back to Public. But if I do go this route I will probably break the cluster before I do anything else. And can't really "Migrate" Wish I could. If I had the space to migrate 8 1.6TB LUNs this would be easy. I'd use ESX Migrator. But I don't so I'll have to upgrade the existing volumes, which is really the quandry here and am considering just doing an upgrade in place. Just don't know if I want to deal with that.

[Texiwill]

Hello,

Yes, you definitely have a quandry. Shared Access Mode VMFS-2 will not upgrade to VMFS-3 until they are switched to public. In doing so you break your clusters.

Since you are planning on moving from local storage to boot from SAN devices, you can not do clustering anyways, Boot From SAN and MSCS is mutual exclusive.

If it was me, I would make complete backups and plan out how you are going to break the clusters... Boot From SAN gives great usage but clustering is not really supported. I would instead use VMWare HA.

I would decide which VMs would stay which would not be needed anymore as they are the second node of a cluster. DIsconnect any shared VMDKs/RDMs from the second node VMs and rename these VMs so you know they are safe to eventually delete.

I would then after I Have a safe backup and scheduled my downtime of the VMs. shutdown all the remaining VMs and do an upgrade in place of the LUNs.

Once back I would then make a note of the VMDK/RDM name of the quorum drive. Delete it from the VM. Then boot the VM disabling cluster services completely. Upgrade VMware Tools.

Now the fun part, you made a note of the Quorum VMDK to delete, delete it by hand, and also delete from disk the second node of the cluster. If you did everything correctly all the shared drives will still be attached the first VM and not be deleted when you did the delete from disk. Alternatively you can delete the second node VM from VC and then by hand delete the files associated with it from disk.

You will have to repeat for each cluster. So if it was me, I would clone a cluster and practice to make sure all the steps were fully understood.

Your upgrade to Boot From SAN requires you to break your clusters anyways. Your removal of shared access mode VMFS will force the clusters to break. Plan carefully and make a full system backup and you should be fine.

Best regards,

Edward

[ktwebb68]

All that is covered. I was looking for alternatives and you did answer one question that I had, which was can the VMFS volumes be upgraded in shared mode. Thanks.