Wasn't sure where to put this, Windows or Linux
August 30, 2018 at 8:34 pm #25364
I may have solved issue one. The network was painfully slow using NAT. Bridged seems to work much better. Which brings me to issue 2
I have Win 7 (fully, and legally licensed) in VB. Today, 5 updates (I only boot it to update it. Don’t even know why I have it, but C’est la Vie). Took 20 minutes, and that’s after the fix to number one.
I also have a Mint install in VB (simply because it was the Linux distro that finally got me to make the jump completely – and I still call in to their IRC from time to time to help newcomers along). Not updated for six – seven weeks, so update. 3 minutes.
What is with Windows update? I was watching network and CPU usage. Network finished (though there’s a crap load of network activity still going on), and the update process is hogging the CPU (8 threads of 16 handed over, and 8Gb of 16Gb available to the VM).
I have to wonder, what the hell is Windows doing???
EDIT: I forgot the part where Windows had to restart. Mint didn’t.
Arch Linux, on a Ryzen 7 1800X, 16 GB, 6 (yes - 6) HDs inc 2 SSDs, 4 RPi 3Bs + 1 RPi 4B - one as an NFS server with two more drives, PiHole (shut yours), Plex server, cloud server, and other random Pi stuff. Nice CoolerMaster case, NV GTX 1060 6GB, and a whopping 32" AOC 1440P monitor.
August 31, 2018 at 9:34 am #25389
Ed PParticipant@edpsForumite Points: 8,639
a) Windows will use any available memory, which means it tends to grab all its allowed on a VM machine.
b) VMs are i/o hogs, especially if they are using the paging/swap file.
c) Network activity on a Windows update is always high as every download is verified. Depending on your windows configuration it may also be spending network time looking to see if it can share the verified crud with another windows machine.
d) If you run two vms simultaneously you may well stretch your PCs i/o capabilities to walk speed (you can sometimes get deadlock situations especially if Debian updates are taking place – Mint etc do not always play well in this situation). Based on info that Dave acquired it appears that if you want to do this regularly you should have separate disks and disk controllers for each simultaneous vm guest.00
You must be logged in to reply to this topic.