I have VirtualBox installed in my OpenSUSE pc. The guest OS is Windows 10. My PC (PC-A) is connected to a network (say, HomeNetwork) to which another PC (PC-B) running windows 10 is connected. PC-B has a shared folder which I would like to access inside my guest OS. Is this possible? If so, how can this be done?
For the case of Oracle VirtualBox, the secret to the various networking modes is documented here: <https://www.virtualbox.org/manual/UserManual.html#networkingmodes>.
AFAIK the default VirtualBox networking mode is “Network Address Translation (NAT)”. To access files located in your LAN you have to choose another networking mode – I tend to use “Bridged networking” for a private (home) LAN.
When more than one VM is configured for the same virtual network,
Then any machine in that network can connect to any other machine in that network.
Even the HostOS can participate in the virtual network although generally speaking would have to be based on IP addresses (the exception would be if you implemented external DNS supporting your LAN).
That would be true no matter what kind of virtual network (NAT, bridging, Host-only).
And, to implement this you can set up any normal type of network functionality like a network file share, network services, etc just as if all were physical machines.
The type of network becomes important only if a machine is trying to access a machine in a different network.
If you wish to make part of your HostOS file system accessible to a Guest, then there can also be a special file system pass-through, but the exact way to do this would depend on your virtualization technology. The Virtualbox documentation for setting up this is at the following
https://www.virtualbox.org/manual/ch04.html#sharedfolders
TSU
Thank you for the detailed info and the links. I chose to use the normal VirtualBox folder sharing which is enabled by the guest additions to access the files on the host OS. For the other PCs in the network, switching to bridged adapter did it, plus selecting Allow all in Promiscuous Mode. I am not sure if this has security implications though.
Not really – the Redmond OS in the VirtualBox will, from a network point-of-view, behave the same as if it was really running directly on hardware directly connected to the LAN. The VirtualBox folks point out that, WLAN interfaces cannot support promiscuous mode at all.
Same problem: Bridged network connection is broken after resuming from sleep.
Workaround:
- Close the VM (saving machine state)
- Re-open the VM
- Then on guest run systemctl restart network.service
I suspect that, sleeping or hibernating Virtual Machines is not a good idea:The main problem is: how does the Virtual Machine know that, the host is sleeping or hibernating? A Virtual Machine has to assume that, it’s always running unless, it, itself, begins to sleep or hibernate.
First,
It should be noted that Virtualbox “NAT” is uniquely different than NAT in all other virtualization…
In Virtualbox, all Guests that are configured with “NAT” share the HostOS IP address… This means that although they have access to the Public Networks (including the Internet), they don’t have a unique identity so cannot communicate with each other. To be configured like NAT in all other virtualization, “NAT network” should be configured. With this configuration, each Guest is assigned a different private IP address.
As for hibernating/suspending/sleeping from within the Guest…
That is generally bad practice in all virtualization and can result in corrupt data files (a good way to ruin your VM for good).
If you want to not shut down your Guest completely, then use the <virtualization> controls to suspend the machine, and then it can be started up again safely later. Again, do not suspend or hibernate your Guests from within the OS as you would if you were running on bare metal.
Promiscuous mode should not make any difference at all.
Firstly, particularly for wlan devices it’s generally not supported. If you had a reason to do this, you have to implement a different kind of network connection, generally non-virtualized.
You have to understand what promiscuous mode is… It doesn’t enable a network adapter to physically listen to any more packets than in non-promiscuous mode, it only means that the OS (possibly at the datalink layer) will actively listen and evaluate all packets including packets destined for a different address. Normally in non-promiscuous mode packets not addressed to the machine are ignored to save computing cycles.
Assuming that, ‘microhoc’ wants to suspend or hibernate the VM’s host machine, does this mean that,
- 'microhoc
’ has to first suspend the VM by means of <virtualization> controls and then, - suspend or hibernate the VM’s host machine?
Once virtualization has suspended the machine, it’s not likely that the machine can be modified until resumed.
So,
It’s best to only use the virtualization suspend control and not use the Guest’s own OS hibernate/suspend/sleep function at all.
TSU