37 replies to this topic

[PGHammer]

remixedcat, on 02 December 2012 - 23:44, said:

has anyone here gotten esxi 5 to work within hyper-v on server 2012???

also hyper-v does make an awesome desktop hypervisor actually...

and I am able to run linux distros pretty easily... now on fedora I am unable to get the networking working correctly.

I can on ubuntu though.

The Ubuntu support is as solid as it gets (that is, in fact, a major shocker with Hyper-V) - which version of Fedora?

[PGHammer]

Kaedrin, on 03 December 2012 - 01:32, said:

The Hyper-V MMC is “ok” at best. It lacks a lot of features and polish of SCVMM. I really dislike using Hyper-V without SCVMM, but yes, for initial learning curve, anyone familiar with Microsoft products will have a pretty easy time with Hyper-V. Don’t get me wrong, the GUI is “good enough” I guess for folks running the version of Hyper-V included with Windows 8 Pro and Enterprise, or who don’t have complex enough server environments… but the Hyper-V MMC needs to be dumped and replaced with a lite version of SCVMM that shares the same GUI elements. There is absolutely nothing in common between the Hyper-V MMC and the SCVMM console except for the product being managed. I would not call the Hyper-V MMC a System Center snap in. System Center 2012 does not utilize any MMC consoles, nor does it look like them in any way (which is good, because the System Center GUI is much greater than any MMC snap in). They are separate entities, and in the case of the VM client connection window, SCVMM fails miserably compared to the Hyper-V client connection window. SCVMM can’t even paste to the VM this way.

Delegating Hyper-V to Administrators prior to Server 2012 was a wee complex. It was not obvious. It was in fact, highly annoying. SCVMM at least made that part of Hyper-V ignorable since it took over delegation control. Server 2012 now actually includes a Hyper-V Administrators group, which it frankly needed back in 2008 R1.

So far as inertia, unless VMware makes some major changes to their pricing schemes, it will probably grow quickly. The bottom line in is Microsoft’s favor right now, and that alone can drive decisions. So far as non-Microsoft VM support goes, Microsoft’s does support a lot of distributions by default these days, and the Hyper-V integration drivers are open source under GPL.

Frankly, the biggest failing Hyper-V and SCVMM combined have right now is smart card support to the VM. Microsoft really needs to address this issue directly within both consoles. RDP is not a "good enough" solution to the problem. There are a few industries that this limitation will directly hinder adoption of Hyper-V, and is likely its biggest failing in the 2012 product line.

Smartcard authentication (such as the DoD Common Access Card) has been an option in Windows Server since 2008R2, and has been an option on Windows desktops (a built-in option) since Windows 7 - the problem has been older versions of Windows and non-Windows clients (real OR virtual). The bigger problem is the client support (again, physical or virtual), as in how the credentials present themselves. SCVMM may have addressed this (Server Manger in Server 2012 certainly does, as it actually has settings for smartcard support for client-side authentication) - however, I have no need for SCVMM with a single server - not even for a multirole server.

[Kaedrin]

PGHammer, on 05 December 2012 - 20:35, said:

Smartcard authentication (such as the DoD Common Access Card) has been an option in Windows Server since 2008R2, and has been an option on Windows desktops (a built-in option) since Windows 7 - the problem has been older versions of Windows and non-Windows clients (real OR virtual). The bigger problem is the client support (again, physical or virtual), as in how the credentials present themselves. SCVMM may have addressed this (Server Manger in Server 2012 certainly does, as it actually has settings for smartcard support for client-side authentication) - however, I have no need for SCVMM with a single server - not even for a multirole server.

PIV smart card support came in with Vista/Server 2008 R2. This is when ECC(ECDSA/ECDH)/AES cryptography support was added. I can confirm that these work with the main SCVMM 2008 R2 and Hyper-V consoles in 2008 R2, but the smart card does not pass-thru the VM client connection for sign-on within the VM. Yes, SCVMM and Hyper-V will accept smart cards for forming the actual Virtual Machine Connection console, but that is not the same thing at all. This has not changed in Server 2012 or SCVMM 2012 and is the limitation I am referring to. If you can provide documentation to the contrary, please provide it, as I greatly want to fix this issue. From what I've heard directly from Microsoft employees however, is that RDP is the only workaround, which is not a "good enough" solution. Sometimes you have to sign in directly through the SCVMM/Hyper-V client consoles, and then you have to use a lesser admin account that is not set for two-factor sign on.

CAC smart card support has existed at least within Windows since XP/Server 2003. I've never used CAC based smart cards.

I have smart cards in production in some of my environments. So far as I’ve seen, passing credentials/certificates on to a VM through Hyper-V is 100% impossible without using RDP.

[+remixedcat]

PGHammer, on 05 December 2012 - 20:26, said:

The Ubuntu support is as solid as it gets (that is, in fact, a major shocker with Hyper-V) - which version of Fedora?

fedora 17

[Kaedrin]

remixedcat, on 02 December 2012 - 23:44, said:

and I am able to run linux distros pretty easily... now on fedora I am unable to get the networking working correctly.

If you don't have Linux Integrated Services installed on the VM, it's probably configured to use the high performance network adaper rather than the legacy network adapter. If you add the legacy adapter within your VM's settings I believe you'll have the issue resolved for now (the legacy adapter is limited to 100 megabit).

[+remixedcat]

Kaedrin, on 05 December 2012 - 23:39, said:

If you don't have Linux Integrated Services installed on the VM, it's probably configured to use the high performance network adaper rather than the legacy network adapter. If you add the legacy adapter within your VM's settings I believe you'll have the issue resolved for now (the legacy adapter is limited to 100 megabit).

I'll try that.... thanks.

[PGHammer]

cluberti, on 03 December 2012 - 01:04, said:

You aren't going to be able to get one Hypervisor product to work within another - only one can have control of the hypervisor, and it's not presented to VMs anyway so ESXi wouldn't see one to manage to begin with.

As to your second question, Fedora should work fine with the legacy adapter, but you aren't going to get it to work (easily) with the synthetic network adapter with distributions on the 3.x kernel tree already (see this for an example). If you need a distribution that uses RPMs and is from RedHat, you're better off using RedHat itself or CentOS, which are fully supported. If you want to try to recompile the 3.2 Integration Components from Microsoft to get things working, there are posts about this and Fedora 16 (which should be the same), but YMMV couldn't be more appropriate in that case.

Actually, you can run one hypervisor within another - I've run Hyper-V server *itself* in a VM on Server 2012 to show how low Hyper-V scales. What you *cannot* do (in the nested hypervisor) is host clients directly - however, you can *remotely* if the hypervisor supports connecting to remote hosts. So, could you run Xen or any other hypervisor inside of Hyper-V? Yes.

Besides, why couldn't you? Before Hyper-V exploded onto the radar, I ran Xen itself inside Oracle VirtualBox just to get experience with admin in Xen.

[PGHammer]

remixedcat, on 03 December 2012 - 01:48, said:

The only thing that is holding running esxi within hyper-v is the virtual network adapter. there is no driver for esxi made for the network adapter emulated by Hyper-V is the DEC 21140/Intel 82579V. There is an esxi customizer tool avalible on http://www.v-front.d...customizer.html that I've found and tried a few pre-packaged drivers and none work so far I'll keep trying every now and then.... I really hope that vmware provides the drivers becuase that is an actual physical network adapter that is widely popular and people had to pull teeth to get it working on a real physical server, as a result, or purchase another network interface card.... which is pretty messed up.

It's popular in the virtual space as well - I'm actually surprised that vmWare doesn't support this adapter (especially when Oracle and Microsoft both do).

This adapter - originally the DEC 21140, and part of the assets Intel acquired with DEC Semiconductor - is one of three PCI Ethernet adapters/families commonly emulated (the others being AMD's Am78x PCI Ethernet adapter and Intel's entire PRO100/1000 line of desktop and server adapters). The DEC and Intel Ethernet adapters have long (and I mean Very Long) retail usage histories as well - oddly enough, the AMD adapter is the only one I have no non-virtual history with.