SQL Server Upgrade - A new Approach for Upgrading
Since one of the primary tenets of SQL Server, transactional consistency, is difficult to get right when performing a clone operation, I'd recommend against using a clone to perform an upgrade in the way you suggest.  A clone of the underlying machine while the SQL Server service is running and accepting client connections might result in the clone containing invalid data.  If you can create a clone of the machine while the SQL Server service is turned off, your proposed solution might be a viable method of performing an upgrade.  Having said that, I'd tend towards not using a VM/SAN clone since the potential for it to go badly wrong is pretty high.  As any DBA worth their money will tell you, unnecessary risk is unacceptable.

Having said that, using a DNS alias is an excellent way of abstracting away the machine name from a server, and is what Windows Failover Clustering uses to direct clients to the active node in a clustered SQL Server installation.

The high-level steps to effect an upgrade where you have a DNS alias in place look like:


Ensure the DNS alias has a short TTL value that will allow clients to "see" changes to the IP address pointed at by the alias quickly enough to connect to the new machine in the desired period of time.  I'd consider 1 minute.
Create a new machine, or VM, with the latest version of Windows and SQL Server as desired.  
Backup the databases on the old server, then restore them to the new server.  
Test all software/website/applications against the new server to ensure compatibility.
Once testing is complete, and you're happy with the new server, disable user-connections to the old server to ensure no one makes updates that won't be seen on the new server.
Take a final backup of the databases on the old server, then restore those databases to the new server.
Modify the DNS alias to point to the new server's IP address.


At this point client applications should be able to use the new server without any changes required at the client end.

The steps above assume you have an upgrade window long enough for you to perform a backup-and-restore of the databases involved in the upgrade process.  If you have no upgrade window, i.e. you require 99.999% uptime, you'll need to consider using mirroring, log shipping, or failover clustering to minimize downtime during the cutover to the new machine.