It would be really useful to have packer connect to a remote hyper-v host/cluster to provision virtual machines (like the vmware builder already does).
I think that this could be done relatively easily either by
adding the "-ComputerName" parameter to the various cmdlets that are called to build the VM
using invoke-command (with the relevant connection parameters) instead of running the powershell scripts locally. An added bonus to this would be that it would enable the Linux version of packer to provision against hyper-v by using the Linux version of powershell.
@giordyb we are working on tackling encoding in Powershell and returning results from Powershell when running elevated prompt. The awkwardness is that the only way to run a real elevated prompt is via a scheduled task. We have a few bugs in this area.
Invoke-Command means you run into the double hop problem. https://blogs.msdn.microsoft.com/knowledgecast/2007/01/31/the-double-hop-problem/
Yes it's possible to configure more then 1 hop, but not in a way that is easy and generic (and security acceptable)
@taliesins I'm not quite sure I understand why the double-hop problem would apply in this case:
I have a windows 10 host in the same domain as the hyper-v host. I am authenticated to the domain and my user is in the hyper-v administrator's group.
Whatever cmdlet you are currently running locally to create and manage the VM can be wrapped in a invoke-command.
Unfortunately my GO skills are very poor, but I was able to do a quick fork and test this out with pretty good results, it actually compiles and creates a VM remotely and if any of the commands give an error the process stops (which makes me think that the exit codes are being passed back correctly).
I know it's a crude hack but at least it seems to be working...please let me know what you think!
This is something I desperately want, I started working on this, but taking a different tact, namely running powershell over ssh: https://github.com/mletterle/packer-builder-hyperv-ssh
It's a big (almost working) hack at the moment, with a lot of copied implementation from the built-in plugin... but you should get the idea.
The ultimate goal is to run against a SCVMM server using a linux control box so that ansible can do the provisioning.
Eventually, it may be possible to use Powershell Core (pwsh) using SSH remoting as well. It would be nice if the common powershell code could be written in such a way as to be transport agnostic... I have some ideas, but am in need of a working (not pretty) implementation at the moment.
Anyway, thank you for the great project, this has been a fun introduction to golang :)
Thanks for sharing your approach! Let us know when you get it polished up :)
@mletterle PR?
@phaseOne I've had other obligations at work, so my implementation has languished a bit. Will probably get back to it though since it's something I really need/want.
@mletterle Did you manage to make any progress on this. It would be awesome to have the ability to run packer on a different machine than the Hyper-V host
@pvandervelde Not since, no. Priorities haven't allowed me to unfortunately :( It's in my backlog though, so there's always a chance.
Could you estimate a timeframe? Not being able to run packer on machines with not enough memory is very annoying, especially if those machines literally have access to a hyper-v core server in their local hyper-v manager.
Any progress on this? Would ultimately love to run Packer inside a Docker container against a remote Win 10 machine running Hyper-V.
Most helpful comment
This is something I desperately want, I started working on this, but taking a different tact, namely running powershell over ssh: https://github.com/mletterle/packer-builder-hyperv-ssh
It's a big (almost working) hack at the moment, with a lot of copied implementation from the built-in plugin... but you should get the idea.
The ultimate goal is to run against a SCVMM server using a linux control box so that ansible can do the provisioning.
Eventually, it may be possible to use Powershell Core (pwsh) using SSH remoting as well. It would be nice if the common powershell code could be written in such a way as to be transport agnostic... I have some ideas, but am in need of a working (not pretty) implementation at the moment.
Anyway, thank you for the great project, this has been a fun introduction to golang :)