SQL: Clustered SQL Server move PtoV

A P2V requires the original server be shut down after it is copied so the VM can start up in its place, so no the users cannot stay connected.

Can your users tolerate a small connection interrupt, like a failover?  If so then it can be done with minimal interruption.

The way I migrated my last cluster was to use P2V to create a clone and add it as an additional node to the cluster.

Beartlaoi,
Yes, the users may be offline for a short period of time.

We would ultimately want to shut-down and retire the cluster server.
Also, on the hardware level; should I be expecting possible snafu on hardware conversions? I know that this is not a perfect world and anything can happen, but, did you experience any?
thx

The storage is a SAN.
I personally do not deal with the networking and the storage devices, but, had a chat with the manager of the technical side and I was informed that it the storage used is a SAN and what he was suggesting is that to take a node of the cluster down, ptov that one, shutdown the cluster server, rename / IP change on the vm and see how things go, and, take it from there.
I would personally create a VM with the same OS, install the same version of SQL on the newly built VM, restore the DBs onto the new vm and call it a day..
we will see what happens.

If you are using SAN then you do not have to restore the DB, the same SAN LUN will be presented to the VM, its a shared disk.
Creating a new VM from scratch is the cleanest and sometimes the quickest option if you have that OS as a fully developed template.
P2V requires a lot of uninstall of hardware specific stuff (especially for HP) then of course install of VM tools.
Another concept to plan for when creating a mixed cluster between physical and VM is the heartbeat.  If you are just using a crossover cable for your heartbeat you will need to replace that with a switch so that you can plug the ESX hosts into it and have the heartbeat VLAN available to the VMs.
When they say SAN are they talking Fiber Channel or iSCSI?  They are handled differently in VMWare.

Good morning Beartlaoi,
FYI
I am reading up on some best practices for SQL on vm in general:
http://www.vmware.com/files/pdf/solutions/SQL_Server_on_VMware-Best_Practices_Guide.pdf

Also, looking at my list of "task" for each DB if I had to take the other route, meaning, install OS and attach or restore DB(s).

I am going to share your paragraphs with the operations manager of the IT side and we are planning on doing the VM move practice on not tomorrow but the next Friday.
And of course keep you posted.
1-16-2014-7-35-08-AM.png

Beartlaoi
FYI
we are going to perform a test on this upcoming Friday
thx for all help

Thank you Beartlaoi