Recommended solution for CPU supporting Hyper-V needed features

[JMLow54]

I have installed on my testing system an AMD FX(tm)-8320 8-core processor. Specifically AMD64 Family 21 Model 2 Stepping 0 CPU in an ASUS SaberTooth 990FX R2.0/GEN 3 mobo. It includes 32GB of matching Kingston Hyper-X DDR3.

I find myself in a position where Windows 10 Pro x64 Hyper-V virtual machine needs to be used for a client which is planning on diversifying to a off-site workforce. I have been tasked with determining a "best approach" to this new work place strategy. They have their own in-house systems build team - and I am asked to determine if VMWare must be used or if Windows is the best solution for setting a standard box to deploy. They desire Windows 10 Pro Hyper-V as they are a 'Windows shop'. They also want this prototype to be confidential as the strategy may not be adopted - thus they have reached out to me instead of their own in-house technical staff.

To that end, I find that my current CPU does not provide the needed feature set in support of Windows Hyper-V (according to CoreInfo from Microsoft). The client would like to remain with AMD as their base CPU product of choice.

I find that I have fallen short in the 'knowledge' area while identifying the proper AMD CPU to recommend. My CPU model, with its current feature set, does not appear to support the needed SVM/NP feature set for Hyper-V (been in place now for about 4 years.)

What is the recommendation of the community for the proper AMD CPU (needs to be 8-core if it exists as the client requires this level of power/speed) with the required feature set?

Thank you for your advice and guidance!

Jim

 

[ComputerSecurityGuy]

Your CPU does provide the needed feature set, AMD-V. However, this is usually disabled by default in the BIOS. So the solution should be just to enable the feature (often labeled "virtualization or AMD-V") in the BIOS, at which point all hypervisors should be more cooperative.

 

[JMLow54]

Thank you!

I shall confirm via BIOS review. I know it was activated for my version of VMWare Workstation v12.

It was just strange that as I was testing my rig for Hyper-V, that CoreInfo reported it was incompatible.

I'll proceed as advised, and install/activate MS answer to virtual machines.

Jim

 

[GhislainG]

Thank you!

I shall confirm via BIOS review. I know it was activated for my version of VMWare Workstation v12.

It was just strange that as I was testing my rig for Hyper-V, that CoreInfo reported it was incompatible.

I'll proceed as advised, and install/activate MS answer to virtual machines.

Jim

Once Hyper-V is activated, VMware Workstation may no longer work (it can't be installed on a system configured for Hyper-V). Having it installed may also have caused the unexpected CoreInfo results.

 

[JMLow54]

Thank you both for your guidance!

An update:
1) Hyper-V was able to be activated, and a test started w/o issue - this although VMWare was installed.
2) The network access configuration for Hyper-V was decidedly more complex and would not fit my client's needs or support capability.
3) The inability to define a USB connection (without a 'hack' as it was called) caused the overall prototyping to fail as the USB ability is a strategic requirement for the build.
4) Once the testing was over with, the recommended solution for the client shall be VMWare: a) easy to deploy using a standard CD/USB drive; b) Easy to maintain and swap between wired and wireless connections for the deployed image.

Both responses were very helpful, with the last observation posted also being seen during the prototype. While Hyper-V installs and executes w/o issue while VMWare is installed, the same cannot be said for VMWare. A message at launch indicates that the two approaches are incompatible and VMWare does not launch.

Thank you again!

The initial response shall be flagged as the overall answer, though the 2nd response was very helpful as well.

I really appreciate your time!

 

[GhislainG]

About #3, this is normal. Unlike VMware workstation, Hyper-V is a real hypervisor and that makes USB, serial and parallel ports unavailable to guest OS. VMware ESX is no different.

 

[JMLow54]

Thank you for the information. Yet, for this build, it is a strategic requirement. The prototyping done supports the ability to encrypt the USB drive (along with local Virtual Drives) and given the nature of the collaboration between associates these traits are vital.

The other aspect has been to test the isolation of the Virtual Machine from the Host. At this point, both are well suited for this purpose, with the provision that even the USB connection is as isolated and secure as possible.

Although the USB could be plugged into an OS that is not configured for the VM, and the person doing it may very well be authorized to the password, the key is that the transport via walk-up and/or US Mail permits the confidential data to remain as secure as the trust in the Associate. At some point, that trust has to be extended, providing the security measures and behavior anomaly detection processes are in place.

I can certainly understand where the hypervisor approach would grant additional security to an operating VM, it simply doesn't fit as cleanly in a distributed workforce which relies on collaborative activities across mediocre band-width connections.

Based on the findings, the primary net connection shall wind up being a USB connected WiFi connection to a locked down router owned by the company, and the primary connection via VPN, with the company's own proprietary/purchased encryption keys.

Without the additional layer of security offered by the Hypervisor layer, the best security engineers have endorsed such an arrangement. This especially since the volume of data worked by the associate in any given assignment consists of 5GB to 150GB. Not something to transmit easily to the workforce.

Thus the strategy implied in my original outline makes security a key operational feature.