What works better for you & why: parallels using a real partition or a virtual hdd?

You're quite correct about gaining the 'separate disk advantage' if Boot Camp and OS X are on different drives. I was targeting the most common usage scenario, which has 'em both on one drive. It sounds like you have pretty much a best-case scenario.

 

how much are the 7200rpm 2.5 inch drives? do they have quite a bit more of a premium over comparable sized hdd's? Im thinking of buying a mac mini case (can get them from ebay) modding it so that I;ve also got an esata plug on the back of it and then putting in 7200 rpm 2.5' hdd along with an external 10000rpm 3.5' hdd (connected via esata)

 

I don't view it as losing half of my RAM, since I've equipped the mini with enough to keep both OS X and XP happy. I've learned over the years that if I'm going to be running a virtualized OS that I'd better buy enough RAM up front. ;-)

Although the Parallels VM emulates a single core CPU, the VM still benefits greatly from running on a dual core machine. Parallels is essentially just another multithreaded Mac app. from OS X's point of view. All threads of execution are ultimately controlled by the OS X kernel. I suppose that Parallels might request an affinity for one core or the other in order to improve L2 cache hits, but affinity is just that - a request. I'm not even sure if the Darwin kernel supports processor affinity (anyone?). I know Windows does.

So, just to summarize. Yes, you do effectively divvy up RAM when running a VM, but CPU cores aren't affected in nearly the same way.

Because of this, both OS X and XP are simultaneously running at pretty much peak performance. Also, consider the fact that the CPU spends most of its time doing nothing or very little.

 

I use both, but very seldom use the BC partition under Parallels. I'm on my 3rd install under boot camp due to problems, and I just have no wish to install a 4th time. My virtual drive is fixed in size as I thought that might speed things up a bit (i.e. Parallels would never need to spend time expanding the drive), but I really haven't noticed much of a difference.

 

I'll gladly fore go the extra speed of a real partition for the flexibility of a VM HDD file that I can move from mac to mac and easily backup.

 

Is there really a speed gain from using a separate partition (on the SAME physical drive) vs. using a virtual HDD file?

I've been following this thread, but haven't found a definitive answer to the OP's original question. Obviously, if the partition is on a DIFFERENT physical drive, performance will be better -- but then, if you have a separate physical drive available, you can always move the virtual HDD file to that drive, so that distinction is irrelevant.

The really interesting question is, what are the performance differences between the following three scenarios, given identical drive usage under both Mac and Windows, and given that the user has everything on a SINGLE physical hard drive:

1. User has a 20GB separate Windows partition on the same drive
2. User has a 20GB fixed-size drive image under Parallels
3. User has an expanding drive image under Parallels

My naive feeling is that there wouldn't be that much difference in terms of disk access, at least between 1 and 2, but there may be reasons why a physical partition is better, even when it's on the same physical hard drive. Does anyone have info on whether there's actually a significant difference?

cheers,
jamie

 

No, there won't be any performance increase by running a VM from a separate partition on the same physical disk which hosts OS X. Physical access to the disk is a serial process. Only one chunk of data can be read or written at a time (this isn't the case w/SCSI drives, but those don't come into play here).

As for your scenarios 1, 2 & 3, I'd expect them to all perform pretty much equally. I'd also expect the expanding disk scenario to degrade the fastest because there's no way (that I'm aware of) to simultaneously defrag both the virtual disk's internal file structure and the .hdd on the host file system (relative to the physical disk sectors, I mean).

 

I know what you mean, I've learned the hard way and have now decided to reverse my decision of going with parallels using bootcamp. It's proven to be quite unreliable for me thus far. I shall be trying a virtual hdd (fixed size), still on a separate hdd, but on the 1st partition (HFSX) instead of the 2nd (NTFS) partition.

cheers,
jed

 

It looks as though the kernel does have that capability within mach's scheduler
http://www.maths.mq.edu.au/~steffen/talks/DarwinMachKernel.pdf

As to how exactly they've chosen to implement their calls is still a matter for contention, and one I'm sure they'd not be keen to cover in great detail.

But a layman's explanation would be great to hear from any of the team, guys?

 

For anyone whom wants to persist with bootcamp configs, this could prove to be an invaluable thread.

http://forum.parallels.com/thread8361.html


Now if you excuse me I'm going to play with virtual hdd's for while instead!

 

Ah, thx for the info re: Mach & affinity.

I second the motion for feedback from Parallels regarding how they emulate their virtual CPU. It'd be useful for those of us who just can't stop tweaking our environments. I realize that 'emulate' may not be the right term in a world where virtualization is supported in hardware...

 

yes but emulation's got more street cred (been round the block) and sounds more techy if you ask me ;-) Parallels guys, can you please do a couple of blackboard drawings?? ;-P

 

I'm not sure that I completely agree... I have not benchmarked this so I'm not talking from a point of knowledge however if you think about it, it makes sense there would be some extra overhead from using a VM file. Here is why:

If you were using a partition when Windows XP wanted a file it would simply request the file, the OS would as you say serially command the disk to read that set of tracks/sectors into the buffer and the file would be available.

When your "disk" is in a VM there must be an extra translation layer that intercepts the disk IO request and computes and performs a disk seek within the VM file. That translation has to take a small amount of time. Add that up over 10,000 disk operations and you will accumulate some time.

The question would be if this same intercept layer is functioning even when you have installed Parallels and Windows XP into a BootCamp partition. It may be and therefore there would be little benefit of doing that over a VM file if that was the case. I simply do not know. However I do know that Windows XP simple feels snapper when run directly in boot camp, IE not under Parallels. I would not say it is MUCH quicker but it is somewhat quicker.

That was the basis of my comment that I would fore go that "quicker feeling" for the ease and redundancy I gain from a Parallels VM. This morning as I wrote this post I copied my VM file off to an external HD. I do this about ever other day or before I plan to install anything new into WinXP.

I wish I had the space to do a rotating backup on my portable external disk, but it's only 100gb so at 20gb WinXP image really only fits 4 times then I have to start deleting things. Now if I could find a firewire 500gb portagle in this size I'd LOVE it!!!

Anyway that's my 2 cents on the speed thing. I think it is very minor how much this "intercept layer" adds but over the long run it is probably a little slower.

M

 

My use of Windows under a Mac is only to do things that are necessary and cannot be done natively on a Mac. For example, updating the firmware in a Garmin GPS must be done under Windows because Garmin only provides these updates packaged as a Windows executable file or requires a proprietary USB card reader that only has Windows drivers.

I use Apple computers precisely because they are Apple computers running OS X. I don't want or need a Windows machine running on Apple hardware as that would totally defeat the whole idea of using Macs in the first place. Therefore, running Windows in BootCamp is a non-issue for me. There is no way that I'm going to let Windows control the Apple hardware and expose my entire machine to the security, performance and reliability issues of Windows.

There are many sound reasons to run Windows as a virtual machine. Foremost is that OS X is still in control and Windows running under Parallels is just another application. Secondly, once I have a good installation of a Windows virtual machine, I can easily back up the virtual machine folder. I can then install new software under Windows or change the Windows OS with an easy way of restoring the entire virtual machine if things don't go right. With Windows being Windows, this is almost guaranteed to happen.

I've also found that Windows 2000 Professional runs quite well under Parallels. It has USB support, does not have the activation issues of XP or Vista, requires considerably less virtual hdd space and runs faster. I'm not quite clear on why people are battling all of the problems with XP and Vista. Trying to create a Parallels virtual machine from a BootCamp partition, migrating from a DVD image of a real PC's hard drive and all the other innovative ways that have been devised to complicate this whole business of running Windows on a Mac.

For me, doing a clean install from an original Windows 2000 CD into a new Parallels virtual machine works just fine. No problems whatsoever and I can start up Windows, do what needs to be done under it and then shut it down. I guess that the lesson in all this is that we should not forget the reason that we're Mac users in the first place.

 

I guess I'm inclined to agree. As you point out, there's got to be some sort of internal mapping going on, which can't be free, performance-wise. My gut feeling is that the overhead doesn't account for much of a performance hit, but since I have no benchmark data to back that up, I can't count it as anything more than my opinion. ;-)

What I'd really like to see is both disk I/O and 'real world app performance' benchmarks on a modern machine with Parallels configured in four ways: 1) running from a Boot Camp partition on the OS X disk, 2) running as a fixed-size VM on the OS X disk, 3) running as an expanding VM on the OS X disk and 4) running as a fixed-size VM on a Firewire-connected fast external drive. Based upon this data, we'd be able to guesstimate anticipated performance from additional scenarios.

I imagine that virtualization vendors have accumulated information like this internally. It'd be very useful if they'd share it with the community. Any one of us could do it ourselves, but it'd chew up a nice chunk of time...

 

That would be nice if we could see how much slower, if any at all, the intercept layer makes things. Parallels? Any chance on publishing some data on performance?

 

I hear ya re: emulation. ;-)

This has turned out to be a really interesting thread, huh?

BTW - I was checking out the docs for VMWare's new Workstation 6 (for Win/Lin, not Mac) earlier today and I noticed that they let you create dual-CPU VMs on single-CPU hosts, although they certainly don't recommend doing so. That rules out processor affinity in their product. Of course, Parallels may be doing something entirely different. I just thought this would be an interesting piece of info for those of us who are trying to understand how things are working under the hood.

 

I'd be tempted to do this myself if I could get my hands on a 'real-world' app benchmarking suite for less than the price of one of my limbs. It'd be a bit of work, but it would also answer some basic questions that I've wondered about for several years. I have a copy of PCMark, but it's dated. No promises, but I just might run a few test scenarios one of these days. If I do, I'll be sure to post the results here.

 

I use both. 80% of the time I am on VMs. But 20% of the time I boot to bootcamp and windoz directly. I have a very powerful scanning program that requires a lot of clipboard access to preload the data, and this conflicts with how parallels uses the clipboard, so I cannot use parallels when running my scanning hardware/software.

It would be NICE if parallels allowed me to manage the clipboard memory and adjust it manually for larger data packets. But until then, I need full access to the hardware in windows. VMs are not quite ready for prime time yet.

 

I prefer a real partition so I can access the files with the virtual machine switched off.