Help me step off the ledge (future proofing, ECC, narrow ILM and sketchy retailers)

Discussion in 'General Hardware' started by tynopik, Nov 5, 2012.

  1. mfenn

    mfenn Elite Member <br> Currently on <BR> Moderator Sabb
    Super Moderator

    Joined:
    Jan 17, 2010
    Messages:
    22,403
    Likes Received:
    1
    When you say "activate" are you talking about the VM's retriggering Windows activation? If so, there is a very easy solution to this. Just assign the VM's a fixed MAC address (this is doable through the GUI or by editing the .vmx directly). A properly configured VMWare VM should be able to be moved around dozens of times per hour and never notice a thing, incidentally this is a big part of how VMWare's cloud offerings work.

    Addressing the larger question, it sounds like the biggest issue you have with moving systems is the software side of things, not hardware. IMHO, trying to build a hardware solution to a software problem is never going to work out in the long run.

    What I recommend you do is to install a very lightweight bare metal OS and run EVERYTHING in a VM. You don't do anything 3D graphics intensive, so it should work out nicely from a performance point of view. The bare metal OS could be Windows, but Linux would be better since a properly configured Linux install can be moved around between hardware with no issues whatsoever.

    Whatever you do, after you get your bare metal OS and virtualization software installed, make an image. This system should never change beyond normal security updates (all real work happens in a VM), so if things go tits-up in a big way, you just spend 20 minutes reimaging and you're back in business.

    Finally, upgrade VMWare Workstation to the latest version. It has come a long way in 5 years.
     
  2. tynopik

    tynopik Diamond Member

    Joined:
    Aug 10, 2004
    Messages:
    4,139
    Likes Received:
    80
    I was under the impression that the CPU bled through to the VM also and triggered issues if there was a significant arch change (ie core 2 to sandy bridge)

    I am somewhat confused as to why running a VM in a VM would improve things if the VM is isolated from the host in the first place, but then I don't really know much about the capabilities of VMWare, I just know enough to create some VMs and run them. Any recommended tutorials on this?

    I have noticed that disk accesses seem a bit . . . slow, so I'm hesitant to run my main system under vmware. Running off an ssd certainly improved things, but even still it doesn't seem particularly speedy. Or maybe it's just trying to run Visual Studio in a VM with 2GB of ram?

    I am currently on 6.5.5 so not even 2 years back . . .
     
  3. mfenn

    mfenn Elite Member <br> Currently on <BR> Moderator Sabb
    Super Moderator

    Joined:
    Jan 17, 2010
    Messages:
    22,403
    Likes Received:
    1
    That can have an affect, but it only matters if you go backwards (Sandy Bridge to Core 2), and even then a simple reboot of the VM will hide the now non-existent features from the VM.

    If you are really paranoid, you can use VMWare EVC to specifically mask off certain features, thus making your Sandy Bridge CPU look like a (very fast) Core 2. That's not really necessary unless you're in a data center environment with live VM migrations though (yes, you can even move a VM from one physical machine to another without ever turning off the VM).

    I didn't mean to imply that you would run a VM within a VM (though this is certainly possible with newer VMWare). What I meant was that you don't install any software on the bare-metal OS other than VMWare and then run everything else in a VM. Your current VMs would be virtualized the same as they currently are, you would just move your typical desktop usage into another VM. So your desktop workload would become a peer of the other VM workloads, not their host.

    Newer VMWare with the proper paravirtualization drivers installed in the guest has next to no I/O overhead. I'm betting that you're just swapping like crazy in your Visual Studio VM by only giving it 2GB of RAM.

    VMWare is very very good about managing host memory, so don't be afraid to be liberal with the amount of memory you give to VMs. Just because you have (say) 8GB allocated to a VM doesn't mean it will actually consume 8GB of host memory all the time. VMWare actively looks for unused pages of guest memory and purges them from host memory. If you have several similar guests running, it will also look for memory pages that are the same between them and only store one copy in host memory, further reducing utilization.

    VMWare Workstation 6.5 is quite old, it came out in September of 08, so over four years ago. You can't go by the date of the latest bugfix release for 6.5 because those don't add any features, they just big problems (mostly security issues). The newest version is 9.0