[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 24/04/16 17:17, Julian Hall wrote: > On 24/04/16 16:14, M. J. Everitt wrote: >> On 24/04/16 14:55, Julian Hall wrote: >> Sounds like a totally normal day with VirtualBox - only without the >> complexities of Snapshot'ing too (yeah, don't go there!). >> [Aside, you may wish to take a snapshot of your working VM anyway, so >> that in the event it has a paddy, you've got something to go back to!] >> >> Good write-up though :) +1 >> >> >> > Thanks :) > > I back up the whole system every Sunday, which includes the whole > VirtualBox setup in /home so in the case of a disaster I could just > extract it out of there. As you can tell I'm not intending to make heavy > use of it, just regular checks to see if any SatNav updates are available. > > Julian I'm a very heavy VBox user and can offer some hints to make life a bit easier (bit late for you admittedly as you've obviously got it working anyway): Install VBox from the Oracle provided repositories only at https://www.virtualbox.org/wiki/Linux_Downloads - don't use the distro provided versions. You'll definitely want the Extension pack as well - VBox will automatically offer to download and install the current version on first launch after an upgrade as well which is convenient. Store frequently/heavily used VMs on SSD or fast network storage for massive IO gains although standard HDDs are bearable - just - for low, occasional usage instances, which I guess describes this case. Windows guests frequently display visual glitches and artefacts even with the guest additions installed - change 3D acceleration to 2D only in settings to save your eyeballs. Select the bridged adaptor type to give your VM a "real" IP on your network to avoid potential issues with NAT configurations. Completely ignore messing with USB filters though, it's unnecessary - VBox VMs default to USB2 EHCI type and as long as you don't accidentally connect to USB3 ports on the host (which won't work without changing to USB3 XHCI in settings, which in turn will disable all your USB2 ports for the VM) everything will "just work". To streamline attaching USB devices, boot your VM and plug in your USB thing to the host at any point. It will attach to the host via usual plug and play (you'll see it in dmesg, thumbdrives will automount, etc). Once your VM is up, look for the row of icons in the bottom right of the window decoration around the VM - hover your mouse over the 4th icon in from the left to get the tooltip "indicates the activity of the USB devices: *no USB devices attached*". Right click on this and you'll get a list of USB devices currently on the host - select the appropriate device(s) by clicking and it will immediately detach from the host and attach to the VM. Try not to accidentally pass through your system mouse - or even worse, keyboard - to the VM, it's very annoying... The guest OS will do it's usual plug and play Windows thing here, just install your device drivers and tools as per usual once it's been initially detected (check eventvwr if Windows is being unhelpful). To safely detach when done, ejecting the USB device from within the Windows guest is usually enough to kick it out from the VM and to automatically reattach it back to the host, rarely you may need to find the USB menu in the VM window frame and deselect it there as well. That's it really - it couldn't be any simpler. Networking issues are usually solved by using bridged instead of NAT'd virtual adaptors (unless you know what you are doing and have specific requirements - DHCP requests from VMs bridged to a laptop's wifi card have issues for example). Whilst the VBox "Shared Folders" thing can be handy for quick and dirty fixes it's the one VBox feature that isn't reliable in my experience, especially if you mount large native linux filesystems RW to a Windows VM and it crashes. For me, the persistent "make permanent" and "automount" features never work and I'd rather do things normally in the VM anyway. So in this case, I would have opened a cmd shell on the Win7 VM and issued "net use z: \\NAS\SHARE /P" to permanently map the NAS share to z: on the VM. Alternatively and even easier, if you've enabled Devices > Drag and Drop > Bidrectional for the VM (again, must have the extension pack installed in host and guest) you can simply open a Thunar/Nemo/Dolphin/whatever window on your Linux desktop, open an Explorer window on your VM and drag and drop from one to the other seamlessly. It's not as fast for very large transfers as the Shared Folders feature or just setting up normal networking between host and guest but for quick and dirty it's fine. This never used to work at all but in recent releases it seems to have been bugfixed, which is nice. So, make sure your Shared Folder mapping of "Hera" via a local fstab mount and then through to the Windows VM isn't RW, 'cos you'll regret that one day. Better yet, remove it and map the network share direct as you originally suggested - you will be able to execute programs directly (permissions will no longer prevent it) via that route without copying locally as well. For reasons I don't fully understand, using Win8/10's ability to finally natively mount an ISO still won't work from a mapped share though when within a VM. If you selected the VBox default for your VM's disk size, it will almost inevitably be too small before long - I think 25Gb is the suggestion for most Windows guests. If your VM has 8Gb RAM allocated Windows will 'helpfully' snatch a matching 8Gb for your pagefile.sys and another matching 8Gb for hiberfil.sys, chewing straight through 16Gb even before the OS and millions of unrolled-up service patches (thanks MS...). If disk space runs out for your VM, power it down first and then do: VBoxManage modifyhd disk --resize 50000 /path/to/yourvm.vdi That will increase the virtual disk to 50Gb and then once you've booted the VM, expand it's NTFS filesystem into the new space via Disk Manager or diskpart as you prefer. Lastly, snapshotting is such a vitally useful and simple procedure with VBox I can't really understand why anybody wouldn't use it or run into issues either. Take the snapshot(s), name and number then sensibly and you have a hierarchal tree of past instances to manipulate at will. Sure, it's not as neat or as powerful as the implementation in KVM or ESXi but you can still create clones from snapshots or rewind for testing. What's not to like? Cheers -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq