Windows 10: 10049 now requires 2gb memory

what problems did you have? I prefer vBox to VMware as it is always free. On a windows host I prefer Hyper-V for the dynamic memory allocation.

VMWare is better for running OSX guests but apart from that all work the same unless I'm missing something.

 

With vBox there were all kinds of gremlins. I don't even remember the details because it has bee years that I have not used it. VMware Player is free also, so that is no different. Right now I have 6 systems (Windows and Linux) running with VMware Player and they all run very good - and fast.

 

Not if your host is OSX - then you have to buy VMWare Fusion which is $80.

I'm not against it - it just isn't worth $80 to me over VirtualBox (which is always free and easy to script) or Hyper-V (which has better memory management if you run several VMs, is also free if you have a Windows host and shutdown/resumes automatically which I like).

I have a feeling that VMware is a little quicker than VirtualBox but it is less reliable testing 10 (possibly as they don't just use published APIs). VirtualBox and Hyper-V stick to what they should do and tend to be a bit more reliable and slower. This could be my imagination though - I've not attempted to test it.

 

OSX may be a special case. I never touch Apple products. I run Windows 8.1 and 10 and 4 Linux distros in VMware Player and never had the slightest problem. And it is fast. See here.

 

About virtual machines and RAM, one of the reasons I like and prefer Hyper-V is its Dynamic Memory feature. To put it short and simple, if you enable the Dynamic Memory, you need to give your vm three RAM values:

• Startup Memory > The amount of RAM assigned to vm whenever it is booted (#1 in screenshot below)
• Minimum Memory > The absolute minimum of RAM always assigned to vm (#3). Even if the memory demand would be smaller, vm will never use less than this given value
• Maximum Memory > The absolute maximum of RAM which can be assigned to vm (#4). Even if the memory demand would be greater, vm will never use more than this given value

Here's a screenshot of the Hyper-V Manager, showing the values at the moment for a Windows 10 Build 10049 vm, Dynamic Memory enabled (screenshot #2). The Assigned Memory (#5) shows how much the system has assigned to this vm at this very moment, the Memory Demand (#6) value showing how much Windows is demanding / requesting at this moment to smoothly run current tasks and processes:




Launching and closing apps and processes causes the demand to change, in which case Hyper-V assigns more or less RAM as needed within the set Minimum and Maximum.

 

Exactly. VirtualBox will use dynamic memory (depending on your host). So does VMware. So does every hypervisor or else you would never be able to start your machines.

According to @whs VirtualBox has gremlins and you have to be careful of them. Nasty little things. Like rats but on 2 legs I believe.

My problem for home use is VMware Fusion costs $80 and the alternative is free and unless it is better (which it isn't) why pay?

 

There is a big difference, the reason why I prefer Hyper-V over VirtualBox. I am sorry I was not more specific in my previous post.

In VirtualBox the Dynamic Memory feature, called Memory Ballooning, do not return the RAM freed from the vm due smaller demand back to the host. It remains reserved, host cannot use it, and VirtualBox can only assign it to other VirtualBox virtual machines. If your VirtualBox has 4 GB allocated on an 8 GB host, the host has only 4 GB available also when the vm frees let's say 2 GB. This 2 GB is only returned to host after this vm, and all other vms using the ballooning have been turned off.

In Hyper-V, the freed RAM is instantly returned to host. This, in my opinion, makes the Hyper-V Dynamic Feature much more usable and flexible.

In addition, the VirtualBox memory ballooning is only supported on 64-bit hosts.

BTW, of course you can run your virtual machines with static RAM. Enabling Dynamic Memory or in VirtualBox's case Memory Ballooning is not obligatory.