It's certainly gone a long way, but I'll see it first before I'll believe it. Because I'm still wondering about:
- Proper / advanced network (VLAN, LAG, QoS etc.) and redundancy support;
- NFS NAS support for cheap / fake iSCSI fail-over support (the not-so-nice SMB solution);
- Proper BSD / Linux support;
- Overhead (Hyper-V server has always used more CPU / Memory compared to VMware in my experience);
1. Hyper-V has the ability to provide lots of extensibility at the vSwitch, and since it's Windows 2012 underneath running Windows drivers (with native teaming software), it can do those things as well if the driver supports them. Also, Windows itself has supported a lot of those networking technologies for a few versions now, it's only the redundancy support at the network layer that's totally new in 2012.
2. Hyper-V requires block-level storage, but anything presented over iSCSI or as SMB (including storage from Storage Spaces pools) can be used in Hyper-V. NFS isn't supported, but against SMB3 shares it doesn't really perform as well either, so you wouldn't really want to use it in production anyway.
3. If you're using a supported Linux OS (RedHat/CentOS, SUSE, or Ubuntu) you've got proper support with the latest ICs, and at the kernel-level as well. If you're looking for support beyond that, you probably won't get it until something changes with the maintainers of the other Linux or BSD distributions, or they pick up the hyperv drivers in their kernels, or both. Given some of this involves enterprise support by both Microsoft and the 3rd party distribution, that also holds back support of some distros. VMware doesn't really support those other distros either, and provides only driver support; Microsoft provides a more end-to-end support solution with their products, thus they generally only work with those that will partner with them and also have enterprise-level support. That limits the pool - it's great if you've ever used it, but it does limit the pool of non-Microsoft OSes "officially" supported.
4. Hyper-V on 2012 (and really 2008R2 SP1) isn't really heavy at all, and performance is about what I get from VMware servers as well. There's some benefit of using a guest partition as the "host" though, which is a much more robust way to get at performance data for both the hypervisor and the guest OS(es) from a single place (the "parent" guest VM).
I didn't really use 2008 Hyper-V in any sort of production role so I can't comment on that, but I see Xen, VMware, and Hyper-V in my travels as a virtualization consultant, and find that VMware and Hyper-V both perform about as well as the other on similar hardware. Xen has some advantages in purely CPU-driven workloads, but falters in I/O and memory performance compared to VMware and Hyper-V, making it less attractive for heavy enterprise workloads that aren't CPU-driven, and even those that are that also require good memory, network, or storage perf don't work as well on Xen as on VMware or Hyper-V server. Obviously this is just one man's experience over the last 7 years or so doing virtualization work, and worth about as much, but it's been pretty darned consistent. Hyper-V Server + Windows cluster + SCVMM in most workload scenarios is now "good enough" compared to other solutions, and is usually (not always, but usually) quite a bit cheaper to run. If your environment needs some of the more advanced features that can only be achieved by VMware, then it makes some sense to pay for VMware to run that environment or specific scenario, but I always tell my clients, especially those running platforms that are officially supported by Microsoft on Hyper-V (Windows, RedHat/CentOS, SuSE, Ubuntu), to evaluate what they really need, and what it costs to get there. I would never recommend a rip and replace of anything right now as the costs would be large, but not seriously evaluating and testing the options out there as you replace hardware, upgrade the OSes in virtual environments, etc. would be stupid. There's money on the table thanks to Microsoft (and to a lesser extent, Citrix), and no matter what you ultimately choose, it makes sense to see if there's money your virtualization environment could be paying back to you while still doing what you require it to do.