virtualbox.org

VirtualBox Help is mute. I searched (here and in Google) and found only specific driver discussion. There appears to be no FAQ. I can't believe that this has not come up and given a 'sticky' pin.

Everyone, raise your hand if this sounds familiar.
You have a Windows CD. You have a new computer. You install Windows in the computer. What do you do next? You install the device drivers.
(You can put your hands down now.)

Enter VirtualBox.
You have a Windows CD. You have a new guest. You install Windows in the guest. What do you do next? Should you install the host device drivers in the guest?

I'm not talking about the guest extensions (...or am I?).

If you don't install the host drivers in the guest, that fact should be in the VirtualBox Help section dealing with installation of a guest OS. And this applies to Linux too.

Synopsis of Answer:
The choices for network adapter are to accommodate the guest OS, not the host's hardware. The VBox Help is not very clear about that. I was concerned that developing a guest on one (ancient) host and then transporting it to another (modern) host would fail because of the difference in the host's hardware. Apparently, that is not the case. That 'said', it's probably a good idea to reinstall the Guest Additions when the guest is installed into the new (different) host. - Mark.

You can't install OS specific device drivers in the guest. That is what the guest additions are for.
The guest is actually running on virtual devices and not what your host actually uses.

Thank you Perryg, but I believe that's only partially true. In my case, I'm using an 11-year old Toshiba laptop to prepare a guest that will eventually go into a 2-year old Dell desktop machine. The Dell has lots of non-standard-HAL device drivers. I suspect that the guest extension has tailored the guest to my (Tosh laptop) hardware, not the eventual target's hardware. What will I do when I put the guest in the target host? Will the guest extensions that are now in the guest be able to handle the 'new' hardware? Am I worrying about nothing?

Actually what I said is totally true. The guest will not use the hosts devices. It uses virtual devices and they are then ported to the host device via the COM/XPCOM. Even the keyboard and mouse use virtual device drivers.

Perryg. Thanks as ever ...you're the best!

Okay, if what you say is true, why am I given any choices for guest hardware?

That would be the host side device. I assume you are talking about the audio which can be different depending on what you actually have. The NIC is (host side) eth0, wlan0, host-only, or NAT and the (guest side) you choose which virtual adapter should be presented as again this is different depending on the guest. I prefer the VirtIO (paravirtualized adapter) because of the improved speed. Keep in mind that the VirtIO or Intel pro1000 in an XP guest you need to disable the Windows firewall/ICS or the network speed will suffer because of LSO segment writeoff.

The only exception would be a USB device which is present on the host and you want to use on the guest. Once presented to the guest the host can not use it as it is a one-to-one relationship. Still no host side specific drivers needed.

You can test all of this yourself. Backup the guest so when it goes south you can recover and add what ever you feel like and see what happens, if anything. I would suggest that you do not do this to the keyboard or mouse and they are a shared resource and if you create a USB filter, or install specific drivers the guest will not work.

Perryg wrote:That would be the host side device.

The following doesn't sound like host side...

VirtualBox Help wrote:6.1. Virtual networking hardware
For each card, you can individually select what kind of hardware will be presented to the virtual machine. VirtualBox can virtualize the following six types of networking hardware:

• AMD PCNet PCI II (Am79C970A);
  AMD PCNet FAST III (Am79C973, the default);
  Intel PRO/1000 MT Desktop (82540EM);
  Intel PRO/1000 T Server (82543GC);
  Intel PRO/1000 MT Server (82545EM);
  Paravirtualized network adapter (virtio-net).

...but I must admit that I find it difficult to figure out when VirtualBox Help is talking about the host, the client, and the VirtualBox application itself. I wish VirtualBox Help would establish a convention (color? italics? bolding?) to differentiate the subjects.

Perryg wrote:...I prefer the VirtIO (paravirtualized adapter) because of the improved speed. Keep in mind that the VirtIO or Intel pro1000 in an XP guest you need to disable the Windows firewall/ICS or the network speed will suffer because of LSO segment writeoff...

Duh? What?

Perhaps, if I outline the architecture I planned, you'd be kind enough to comment. What I planned was no firewall for the guest, firewall for the host, all port listeners blocked by the firewall (including the file & printer sharing ports), and file & printer sharing installed in both the host and the guest. My goal is to allow the host and the guest to share files & printers inside the firewall, but to be blocked by the firewall from sharing with the cloud. Note: my firewall is ZoneAlarm which blocks inbound and outbound. In this architecture I assume that if the host is firewalled, the guest is also firewalled (except for virtio-net). Is that correct?

Comments? Thanks - Mark.

In your second quote, those are the virtual adapters that you present to the guest. It is *not* the actual host adapter.

You can setup what ever you want as far as firewall is concerned. It is an issue with XP that if it is virtual and you use the virtio or intel 1000 the network speed will be reduced due to what I said earlier. You need to determine if the speed is good enough or if not then disable the XP guests firewall/ICS to pick up the network speed. By default IIRC the network adapter is set to PCnet III for an XP guest but that is only a 10/100 adapter which works well but I find really slow compared to today's faster NIC adapters.

The rest of what you write about is pretty much user choice. Do what you feel safe doing and see how it works for you. You really should play with it some and remember tweaking can be a good thing.

Oh one thing I will leave you with, is if you use snapshots for any reason, say to make sure an update does not kill your guest. After you find it is working, do yourself a favour and merge the snapshot so it returns to a flat file, and always backup before you do anything drastic, which actually negates the need for the snapshot in the first place. IMHO they are way too fragile and if one of them in the chain breaks so does the guest.

Let's look at the example you quote above. The list of adapters shows the adapters which VirtualBox can emulate. You choose the one which your OS is likely to be happy with. (This is automatically done for you if you select a particular OS from the dropdown list when you create the vm. It will select a device which has an "in-box" driver in the OS. I have never had to manually install a NIC driver in a vm to make it work). Windows will automatically load the device driver for this card. If you look in Device Manager in the guest OS you will see the driver loaded. Not that this is the driver for the emulated NIC, not the physical NIC in the host. The OS in the vm sees its own emulated device, not the physical device in the host machine.

While you are in Device Manager have a look at the drivers for the disk drives and the display adapter. You will see the VirtualBox drivers loaded by the guest additions (if you have intalled them) which Perry talked about. Again these are the emulated devices in the vm, not the physical devices. This is why the vm can be relocated to a different host. The drivers loaded are specific to the guest.

The guest additions are enhancements loaded into the the guest OS. They enable the OS to run better in a vm. All virtualization software solutions offer these enhancements to improve performance of the OS in a vm (VM Tools, Hyper-V integration components etc).

Regarding how you plan to network between host and guest, that will depend on the network settings for the guest. You will probably want to use the host only adapter (which links the NIC in the guest to an interface in the host). The only network connection of the guest is directly to the host. It has no other network access unless you enable it through the host OS. The host and guest have a network connection even if the host is not connected to any other network.

Thank you for your kind explanation. My original concern has gotten a little muddled. Perry & you have convinced me that the various choices for e-net are to accommodate the guest OS, not the host hardware. That was not entirely clear in the docs.
I'm preparing the guest in my ancient Toshiba laptop but it's destined for a modern Dell desktop. I'm trying to avoid any problems as the VM goes through 'immigration' when it arrives in it's new 'country'. Of particular concern to me is not the hypervisor's interface to the guest, it's the hypervisor's interface to the host. When it 'wakes up' in the new 'country' that has 'alien hardware', what will it do? How will it react? Having never made a VM before (except back in the days of VM-386) I'm trying to be prudent. When a guest is created, is its hypervisor (ring-0) code 'compiled' to match the host's hardware, or is it flexible enough that when it gets transplanted it will still work? There's hints both ways in the docs.

BillG wrote:...You will probably want to use the host only adapter (which links the NIC in the guest to an interface in the host). The only network connection of the guest is directly to the host. It has no other network access unless you enable it through the host OS...

Configure the host as a gateway? Hmmm... Put the guest and the host in a class-A LAN (i.e., 10.x.x.x) and then let the host connect to the Internet through the firewall via class-C LAN (i.e., 192.168.x.x)? Is that what you mean?

I think I just came up with a good idea. 'Listen' to this: How about creating a repository of Howto: Setups That Work right here in this forum? It would be a place where people can share working configurations. (It would probably cut down on my type of fumblings and would probably eventually cut down on the moderators' workload.) It would work like Sticky Solutions and would be pruned of discussion leading up to the Setup That Works by a moderator (or an appointee who participated in the solution). The various Howto: Setups That Work topics wouldn't even be specific to any particular host OS (though discussion leading to the particular solution could be host OS-specific or they could be treated as host OS-specific applications of the architecture). Do you see what I'm getting at? What do you think? (I'd be willing to work on such a repository.)

Perry. Bill. Thanks for your very generous help. I've got a lot to mull over. I appreciate your patience.