Tweet
Tom:
As I understand it, the rationale for choosing the Host_only networking option to communicate between the virtual machine (Ubuntu + LocalAppInventor) and the host machine was that it allows the application to be accessed via a consistent IP and port (192.168.56.35:8888) on all hosts without affecting the existing networks. A side effect of choosing this option is that the VM is visible only to the host on which it is running, but I don't know if that were a desideratum.
I think this choice was quite reasonable and fully expected it would "just work", as it has on all the hosts I've installed to, which include 5 Linux Mint 17.1/17.2 systems and 1 each Windows 7 and 8 systems. The difficulties some Windows users are experiencing are perplexing to me, but I no longer know the inner workings of MS Windows well enough to conjecture what's happening to them.
Here's a modest proposal: Use the "Port Forwarding with NAT Networking" option instead.
This option mimics the port forwarding feature of network routers, in this case the "router" being VirtualBox. The VM has access to the outside world but is invisible from outside (including from the host) as with the default NAT option, except that once port 8888 is set as a forwarded port, calls to port 8888 on the host machine are forwarded automagically to port 8888 on the VM.
I have just experimented successfully with this option on both a Linux Mint 17.1 host and on a Windows 8.1 host.
Experimental Scenario:
1. Reconfigure the VirtualBox network to have no Host-only networks. This means it will default to supporting NAT networking only.
2. Before starting the LocalAppInventor VM, use the Settings tab in VirtualBox to make the following changes to the VM's Network Settings:
3. Start the VM. It comes up as before, but after initialization, the bottom bar displays "IP Address: missing network adapter App Inventor: OK Build Server: OK"
4. From a web browser on the host, go to the URL "localhost:8888" (of course the hostname or the host IP works instead of "localhost"). The"MIT App Inventor 2" page opens, I log in, and that's the end of my story.
Note 1: On the Windows host, the first time I start the VM, Windows Firewall pops up to warn me about access to networks. I choose to access just home and work networks and drove on.
Note 2: I can also now access the App Inventor from other computers on the same LAN using this "master" host's URL http://<hostname or host IP>:8888. Whether this is desirable is not for me to say. Network settings on the host could be changed if needed to block this "external" access.
Note 3: I presume the "missing network adapter" message could be fixed up but I don't want to dig through your code. A best practice might be to define a static IP for the VM, but I didn't have time to explore that before composing this message.
Note 4: the hosts I experimented with already worked fine with the Host_only networking option, so it's possible this proposal could also fail on the affected Windows hosts. I am optimistic that it will work but as Ronald Reagan famously said "Trust but verify!"
Thanks for all the hard work you and your fellow FTC supporters have put into this software effort. It is *very* impressive.
Regards,
Kent
Mentor to FTC Team 7519 and by extension to its sister Team 7518
As I understand it, the rationale for choosing the Host_only networking option to communicate between the virtual machine (Ubuntu + LocalAppInventor) and the host machine was that it allows the application to be accessed via a consistent IP and port (192.168.56.35:8888) on all hosts without affecting the existing networks. A side effect of choosing this option is that the VM is visible only to the host on which it is running, but I don't know if that were a desideratum.
I think this choice was quite reasonable and fully expected it would "just work", as it has on all the hosts I've installed to, which include 5 Linux Mint 17.1/17.2 systems and 1 each Windows 7 and 8 systems. The difficulties some Windows users are experiencing are perplexing to me, but I no longer know the inner workings of MS Windows well enough to conjecture what's happening to them.
Here's a modest proposal: Use the "Port Forwarding with NAT Networking" option instead.
This option mimics the port forwarding feature of network routers, in this case the "router" being VirtualBox. The VM has access to the outside world but is invisible from outside (including from the host) as with the default NAT option, except that once port 8888 is set as a forwarded port, calls to port 8888 on the host machine are forwarded automagically to port 8888 on the VM.
I have just experimented successfully with this option on both a Linux Mint 17.1 host and on a Windows 8.1 host.
Experimental Scenario:
1. Reconfigure the VirtualBox network to have no Host-only networks. This means it will default to supporting NAT networking only.
2. Before starting the LocalAppInventor VM, use the Settings tab in VirtualBox to make the following changes to the VM's Network Settings:
a. Keep adapter 1 attached to NAT, but, in the Advanced selections, click on PORT FORWARDING and add a rule with Name: [I choose LocalAppInventor but it's arbitrary], Protocol: TCP, Host IP: <blank>, Host Port: 8888, Guest IP: <blank>, Guest Port: 8888
b. Disable adapter 2.
b. Disable adapter 2.
3. Start the VM. It comes up as before, but after initialization, the bottom bar displays "IP Address: missing network adapter App Inventor: OK Build Server: OK"
4. From a web browser on the host, go to the URL "localhost:8888" (of course the hostname or the host IP works instead of "localhost"). The"MIT App Inventor 2" page opens, I log in, and that's the end of my story.
Note 1: On the Windows host, the first time I start the VM, Windows Firewall pops up to warn me about access to networks. I choose to access just home and work networks and drove on.
Note 2: I can also now access the App Inventor from other computers on the same LAN using this "master" host's URL http://<hostname or host IP>:8888. Whether this is desirable is not for me to say. Network settings on the host could be changed if needed to block this "external" access.
Note 3: I presume the "missing network adapter" message could be fixed up but I don't want to dig through your code. A best practice might be to define a static IP for the VM, but I didn't have time to explore that before composing this message.
Note 4: the hosts I experimented with already worked fine with the Host_only networking option, so it's possible this proposal could also fail on the affected Windows hosts. I am optimistic that it will work but as Ronald Reagan famously said "Trust but verify!"
Thanks for all the hard work you and your fellow FTC supporters have put into this software effort. It is *very* impressive.
Regards,
Kent
Mentor to FTC Team 7519 and by extension to its sister Team 7518
Comment