What I would do is to benchmark the performance before and after the changes. There should be a performance gain after tempdb is moved to another drive. Use DMVs like sys.dm_io_virtual_file_stats to see the read and write wait times for the DB files.
Use the perfmon physical disk counters: Avg. Disk sec/Read, Avg. Disk sec/Write, Disk Reads/sec, Disk Writes/sec. The change in these metrics will let you know if the disks are physically separate or are just the same disks which are logically separated.
Want a third party disk benchmarking tool for your disks, so that the SAN admins cannot accuse SQL server of its results? Use SQLIO. Although there is SQL in the name, this tool does not require SQL server to run and is not related to SQL server.
This is a good question, and I look forward to see the other answers.
In your question you say "one LUN assigned to a SQL Server VM" - what you want is one LUN assigned to the hypervisor machine that can have multiple virtual machine disks for the SQL Server stored on it. This allows the VM to use a much larger number of threads to access the disk.
In order to get the best queue depth out of VMware, specifically, you'll need to use as many separate virtual controllers, and drives as possible. Make sure you use the para-virtualized controller, if at all possible. Refer to this blog from VMware.
I'd put tempdb on 2 controllers (with 4 files, spread over the two controllers/LUNs).
I'd put data on a controller, and tempdb on a controller.
Virtual controllers have their own queues (just like hardware); typically at most 32. Pretty clearly, 32 is not a lot, so having more controllers actually increases the effective queue depth.
Clearly, if you're going after performance, there are also a lot of other settings, such as CPU and Memory reservations.
The standard warning applies here; do what you have tested as being the best solution for your system. Since we have no idea about your actual load, I/O requirements, etc, etc, it's pretty hard for us to give you a hard-and-fast rule to follow for every installation.
VMware whitepaper on pushing I/O performance is here (warning, PDF).
Best Answer
You have to specify the same local storage paths on both nodes for the TempDB in order for the nodes to fail over properly.