Go Back   AnandTech Forums > Hardware and Technology > General Hardware

Forums
· Hardware and Technology
· CPUs and Overclocking
· Motherboards
· Video Cards and Graphics
· Memory and Storage
· Power Supplies
· Cases & Cooling
· SFF, Notebooks, Pre-Built/Barebones PCs
· Networking
· Peripherals
· General Hardware
· Highly Technical
· Computer Help
· Home Theater PCs
· Consumer Electronics
· Digital and Video Cameras
· Mobile Devices & Gadgets
· Audio/Video & Home Theater
· Software
· Software for Windows
· All Things Apple
· *nix Software
· Operating Systems
· Programming
· PC Gaming
· Console Gaming
· Distributed Computing
· Security
· Social
· Off Topic
· Politics and News
· Discussion Club
· Love and Relationships
· The Garage
· Health and Fitness
· Merchandise and Shopping
· For Sale/Trade
· Hot Deals with Free Stuff/Contests
· Black Friday 2013
· Forum Issues
· Technical Forum Issues
· Personal Forum Issues
· Suggestion Box
· Moderator Resources
· Moderator Discussions
   

Reply
 
Thread Tools
Old 11-07-2012, 08:39 PM   #26
mfenn
Elite Member
Moderator
General Hardware
 
mfenn's Avatar
 
Join Date: Jan 2010
Posts: 20,634
Default

Quote:
Originally Posted by tynopik View Post
doesn't matter, after having been moved around as much as these have been, changing the cpu arch out from under them is enough to trigger it
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.
mfenn is offline   Reply With Quote
Old 11-08-2012, 02:43 AM   #27
tynopik
Platinum Member
 
Join Date: Aug 2004
Posts: 2,454
Default

Quote:
Originally Posted by mfenn View Post
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.
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)

Quote:
Originally Posted by mfenn View Post
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.
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?

Quote:
Originally Posted by mfenn View Post
Finally, upgrade VMWare Workstation to the latest version. It has come a long way in 5 years.
I am currently on 6.5.5 so not even 2 years back . . .
tynopik is offline   Reply With Quote
Old 11-08-2012, 07:13 PM   #28
mfenn
Elite Member
Moderator
General Hardware
 
mfenn's Avatar
 
Join Date: Jan 2010
Posts: 20,634
Default

Quote:
Originally Posted by tynopik View Post
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)
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).

Quote:
Originally Posted by tynopik View Post
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 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.

Quote:
Originally Posted by tynopik View Post
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?
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.

Quote:
Originally Posted by tynopik View Post
I am currently on 6.5.5 so not even 2 years back . . .
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
mfenn is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 04:23 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.