Hyper-V can't attach NAS-hosted VHD file: "Failed to add device...the user name or password is incorrect"

Question

_{Thursday, January 17, 2019 6:24 PM}

Consider the following scenario:

Customer stores secondary backups of their Hyper-V VMs in the Acronis cloud backup service, as a fallback in case the primary offsite backup system fails or the buildings burn down or something.  They want to perform test restores to validate this approach, which essentially means downloading VHD files from Acronis's service to a Synology NAS, creating new VMs on a hypervisor, and attaching the downloaded VHD files to them.  The files still live on the NAS, not the hypervisor, because the files are very large and the hypervisor's own SSD storage is very expensive.

The 'portability' of these VHD files has never been an issue; we've always been able to copy them between hypervisors and run them.  However, this is the first time we're attempting to run a VM that has its VHD file on a NAS vs. direct-attached storage on the hypervisor itself.  The NAS share hosting the VHD files is mapped as a network drive on the hypervisor, which runs Server 2016 Standard.

When I attempt to attach a VHD file that's on the NAS to a new VM, I get the following error:

We've tried the following: 

--mounting a NAS-hosted VHD file using the hypervisor's Disk Management snap-in, to verify that we can see data there (works fine)

--as mentioned by this Brian Posey article, granting "Everyone" full control of the file temporarily, just to see if we can attach it to a VM (same error). Before anyone yells at me about security, this hypervisor and NAS are on a separate air-gapped network, and we undid the change immediately.

--using the icacls fix suggested in the same article (same error)

--copying one of the NAS-hosted VHDs to the hypervisor's own direct-attached storage, and attaching it to a VM.  (works fine!)

Neither the NAS nor the hypervisor are joined to an AD domain, so we're using passthrough authentication (same local admin account on both hypervisor and NAS).  Accessing the NAS's share via the hypervisor, we have no issues browsing subfolders, creating test .txt files, or changing permissions on test files, suggesting it's not a permissions or authentication problem.

What should we be trying next?  Thanks for your help!

All replies (4)

_{Thursday, January 17, 2019 6:46 PM ✅Answered}

Neither the NAS nor the hypervisor are joined to an AD domain, so we're using passthrough authentication (same local admin account on both hypervisor and NAS). 

That's not pass-through authentication. Authentication methods with the word "pass" literally mean a passing of credentials. This is two different sets of user credentials from two distinct security contexts that just happen to use the same user name and password. Additionally, they only apply to user accounts, whereas Hyper-V requires host authentication. That is impossible in workgroup mode.

Accessing the NAS's share via the hypervisor, we have no issues browsing subfolders, creating test .txt files, or changing permissions on test files, suggesting it's not a permissions or authentication problem.

That activity, and mounting VHDs in disk management, are not hypervisor functions. Those are Explorer functions. Explorer does not require host authentication.

Hosting VHDs on SMB for Hyper-V access requires genuine host authentication using Kerberos. You will need a domain and delegation. Even if you have that, I do not have the personal knowledge to know if a Synology meets the requirements for Kerberos host authentication.

Eric Siron
Altaro Hyper-V Blog
I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.

_{Thursday, January 17, 2019 7:58 PM ✅Answered}

I don't see a path using nested virtualization that doesn't eventually loop back to the same problem AND add a lot of unwanted complexity. Once you have that environment built, you still can't connect the non-domain-joined host to it because it can't authenticate.

Windows 10 has the same basic problem, plus you move onto some really shaky ground on licensing.

In either case, even if you manage to successfully deal with all of the problems, you will have a configuration and maintenance nightmare that I would run, not walk, away from.

If you have some method of direct- or network-attaching the NAS so that it looks like local block storage to the Hyper-V host, I would explore that. It might allow you to block off a region and expose it with iSCSI, for instance. I think that would be the path of least resistance.

If you can't do that, then I'm afraid you're going to have to challenge the status quo. If they want domain separation, then you could drop in a small domain controller that lives on the local SSD of a host and only services the Hyper-V host and the SAN. If you've got a spare virtualization right, you're only out ~30GB of drive space and ~600MB memory. It's a functional solution, with the main problem being that such things almost invariably end up with a domain trust. A poorly architected trust relationship is worse than just joining everyone to the same domain.

Eric Siron
Altaro Hyper-V Blog
I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.

_{Thursday, January 17, 2019 7:18 PM}

Thanks for the detailed reply, Eric.  Apologies for misusing that term; it's always nice to have an opportunity to improve my understanding. 

Ordinarily, joining a hypervisor and the Synology NAS to an AD domain wouldn't be an issue (the NAS supports it), but for policy and logistical reasons that's not possible in this case.  Joining the NAS to a domain would be fine, though I'll have to check further about Kerberos host authentication, but doing that with a hypervisor in this case isn't allowed.  I don't make the policies here, so that's above my pay grade unfortunately.

However, I'm wondering if you think nested virtualization might be a way around this.  Provided the hypervisor and guest are Server 2016 or later, couldn't I create a second hypervisor in a guest OS, join that guest to the domain, join the NAS to the domain, and we're off to the races? 

The other option that occurred to me would be to use a domain-joined Win 10 PC's "client Hyper-V" feature to perform the backup restore tests.  Management's policy about domain-joining hypervisors wouldn't apply in this case, for reasons that aren't worth going into.

What are your thoughts?  Thanks!

_{Friday, January 18, 2019 6:17 AM}

Hi,

Thanks for your reply!

I did some research about your error, the following link may help you, just for your reference:

https://community.spiceworks.com/topic/505366-cannot-add-virtual-hard-drive-to-unitrends-vm-hyper-v

Good luck to you!

Best Regards,

Daniel

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].