Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port Forwarding with VirtualBox on Windows #1333

Open
JonTheNiceGuy opened this issue Feb 3, 2020 · 3 comments
Open

Port Forwarding with VirtualBox on Windows #1333

JonTheNiceGuy opened this issue Feb 3, 2020 · 3 comments
Labels

Comments

@JonTheNiceGuy
Copy link

@JonTheNiceGuy JonTheNiceGuy commented Feb 3, 2020

I have installed MultiPass on a Windows system (Microsoft Windows [Version 10.0.17134.1130]), and configured it to use Virtualbox (multipass set local.driver=virtualbox). All good, so far!

Like others have noted, when using the VirtualBox backend, you don't get an IPv4 address which is fine, but I'm able to configure any port forwarding or bridging, this is because MultiPass on Windows uses the System account, so I can't start the virtualbox user interface, nor can I run any commands using the "Run as Administrator" or "Run as different user" as... well, you can't use the system account like that.

Some have suggested that you should use an SSH tunnel, but as I can't see what port Multipass is connecting to, I'm stuck there too! (Also, I can't work out where the SSH key would be for Multipass either! Hat-tip to #913)

With a Vagrant file I have on this machine, I can run vboxmanage showvminfo vmname and some of the lines I receive include:

NIC 1:                       MAC: 02827A7B5194, Attachment: NAT, Cable connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: deny, Bandwidth group: none
NIC 1 Rule(0):   name = ssh, protocol = tcp, host ip = 127.0.0.1, host port = 2222, guest ip = , guest port = 22

With this data, you'd be able to show that the interface is "NAT"'d, and that there's an SSH port forward available on host port 2222. I'm guessing that Multipass has this detail stored internally somewhere (so you can access primary, for example).

It would be helpful if instead of showing "IPv4" as N/A, instead it showed "NAT to localhost" and perhaps also indicated the port for SSH. Multipass info could also list where the SSH key is stored?

I'd also like to endorse #309 for something similar.

Until this is resolved, I'm unable to use Multipass with Virtualbox for anything other than the most simplistic tasks, and must resort to using Vagrant.

@Saviq

This comment has been minimized.

Copy link
Collaborator

@Saviq Saviq commented Feb 3, 2020

Hi @JonTheNiceGuy, thanks for a detailed write-up.

There's a balance that we try to maintain between features and usability, thinking hard before we introduce a feature inside Multipass. Most of our hypervisors create a virtual network segment, so port forwarding is not that as much of a requirement as it is for VirtualBox, which is at least part of why it never got done. But we recognize the need for it, we just need to design a good user experience around it.

The SSH port / key is an internal implementation detail that we would like to not expose to users (we want to replace it altogether in the long run), so I'd rather not add it to multipass info.

Would implementing port forwarding indeed solve your issue? If so, can you please say "Duplicate of #309" and close this issue?

@Saviq Saviq added the question label Feb 3, 2020
@Saviq

This comment has been minimized.

Copy link
Collaborator

@Saviq Saviq commented Feb 3, 2020

On another note, you can use psexec.exe -s -i VirtualBox.exe or psexec.exe -s VBoxManage.exe … to control the system user's VirtualBox instance.

@JonTheNiceGuy

This comment has been minimized.

Copy link
Author

@JonTheNiceGuy JonTheNiceGuy commented Feb 4, 2020

I don't think this is exactly a Duplicate - there are separate and fun issues around the privilege model within Windows (like the psexec thing). So, there are some documentation changes I'd like to see off the back of this - noting the psexec part for getting access to VirtualBox would be a big start 😄 I don't know if that's part of this ticket or a separate one.

I've now used psexec, and so when I run psexec -s -i 'cmd.exe' to get a shell that I can see "things" happening in - yep, I can configure the interface on the VM: vboxmanage modifyvm "primary" --nic2 bridged --bridgeadapter2 "DisplayLink Network Adapter NCM" but when I then run multipass start (from a "run as administrator" command prompt session), I get:

C:\WINDOWS\system32>multipass start
start failed: The following errors occurred:
primary: timed out waiting for response

Watching the Virtualbox application at the time this is run, it doesn't seem to start running the VM either. Even manually starting the VM, the "primary" machine seems to struggle to have it's shell opened with that timeout message. I think this is a separate issue, but no logs were showing as to why it was failing, so I don't know if I'd fat-fingered something, or if it was just one of "those things" about "primary".

I tried, instead, doing the same with a "launched" image (multipass launch which created "wired-amberjack", and then multipass stop wired-amberjack so I could do further config) - this time I was able to add an extra interface and bridge it (although, to be fair, it took some faffing around trying to figure out what Virtualbox classes as an "interface name" as it doesn't match the Alias from Windows, nor does it match the name from Get-NetAdaptor - you need to get the proper name from VirtualBox itself, or by running something like this: Get-NetAdapter -Physical | format-list -property "Name","DriverDescription" Yey!) - the exact command now is psexec -s -i "c:\program files\oracle\virtualbox\vboxmanage" modifyvm "primary" --nic2 bridged --bridgeadapter2 "DisplayLink Network Adapter NCM" (pick your adapter alias based on that get-netadapter command before, or by running virtualbox gui and see what your bridge options are)

I now get a VM with the second interface in a "down" state. I think, at this point, it's because I need to do something with a cloud-init to say "Yep, you can use the second interface", either that, or push something into /etc/netplan to say "DHCP is good for the second interface"... but that's not really something for an "easy to use tool" like this.

So, yes, while fundamentally this could be a duplicate of #309, if that's not going to be around for a while, it's worth documenting this work-around until 309 is available, and noting that it's a work around pending the completion of that.

I hope some of these notes above can help towards that documentation? If so, and you want me to create a PR based on those notes - point me to where I should do that, and I'll do what I can.

As an aside, and worth pushing as a comment to someone who's looking at it - I ended up using Multipass because the MicroK8S documentation recommends using Multipass, which I guess assumes that you're using Hyper-V, because if you're using the Virtualbox backend, you need these extra settings otherwise you're stuck with a K8S environment that isn't reachable from well, anything that isn't Multipass!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.