Some virtual OS questions

[RayLopez99]

I am using VirtualBox by Oracle. works fine. But questions:

1) if you 'take a snapshot' do you need to physically backup your VM VirtualBox virtual folder as well? I don't think so. I've restored from a snapshot no problem, so why bother with backing up a virtual folder (other than to be extra safe)?

2) how much slower is a program when running under a virtual OS as opposed to the real OS? Assume the same OS (Windows 7). Reason: I compile complicated programs and do notice there's a performance hit when compiling the same program in Visual Studio when in the virtual OS. But I can't quantify it, other than it seems somewhat slower. Anybody else notice this?

RL

 

[Paul]

I am using VirtualBox by Oracle. works fine. But questions:

1) if you 'take a snapshot' do you need to physically backup your VM VirtualBox virtual folder as well? I don't think so. I've restored from a snapshot no problem, so why bother with backing up a virtual folder (other than to be extra safe)?

2) how much slower is a program when running under a virtual OS as opposed to the real OS? Assume the same OS (Windows 7). Reason: I compile complicated programs and do notice there's a performance hit when compiling the same program in Visual Studio when in the virtual OS. But I can't quantify it, other than it seems somewhat slower. Anybody else notice this?

RL

Maybe I can answer (2).

a) Using SuperPI as a benchmark, I can get 90% of the performance
of one core of my processor, when running in a Virtual Machine.
That's X86 guest instructions, running on an X86 host, so no
instruction translation of note is involved. Things running in Ring3
shouldn't need any assistance (except when virtual I/O is called for
and that is emulated). But compute-bound performance, staying in L1 or
L2, can get to the 90% level. The rest might be scheduler overheads and
context switching once in a while.

Using other tools in the past, running X86 on Mac or X86 on Sparc,
you might get anywhere between 1% to 10% of the CPU core, in terms
of performance. Even when translated instruction sets are cached,
just the emulation process itself is slow (ten instructions in
the native instruction set, to do the work of one instruction in the
foreign instruction set).

But if the virtual machine and the host use the same instruction set,
things can work very well indeed.

b) OK, you're compiling. You should be aware that disk I/O can be
painfully slow. Disk I/O doesn't run anywhere near native speed.

For a laugh, you could install HDTune, and see if it'll run in
a guest or not. Then see what kind of results it gets.

Same can happen with network operation. The host may be able to
access another computer at 117MB/sec, but a guest OS in a VM
gets around 1MB/sec. Now, that's slow. Especially when using
network shares, as a means to access information in some host
somewhere.

Virtually any storage I/O method that matters in there, is slow.
Many times, I've had to walk away from the computer, and prepare
a meal, while I'm waiting for some large file transfer to complete.

*******

With regard to your first question, I think VirtualBox has a manual,
which is more than can be said for some VM software. You should
browse that first. I've also read a riveting document that discussed
time keeping in the virtual environment, and how the time of day is
kept up to date. This would be important for a person compiling, because
if the date stamps applied to recently written files are wrong, your
compiler won't selectively update executables properly.

A virtual machine can be "frozen" and written out. That involves
something similar to hibernation, in that the virtual machine
memory is written to a disk file on the host. If you use the little
"X" in the upper right hand corner of a VM window, and select "power
off", that would do a dirty shutdown, similar to turning off the power
on a real PC in mid-session. If you select "shutdown" from within the
OS, that's an orderly controlled shutdown, and no hibernation type
file need be written in that case. The file system is stored on one
or more .vhd files or equivalent.

I have one set of VM files, which consists of just the .vhd stuff.
If that VM is corrupted by malware or some experiment goes bad,
I simply toss the existing .vhd files, and copy the "clean" set
into the appropriate place. That's an example of using a backup
copy, to clean up a mess.

I hardly ever archive the current bloated .vhd files from
virtual machines. I've lost a couple VMs due to corruption,
and the lesson I've learned from that, is it is best to do a full
shutdown on a VM from inside, rather than "hibernating" the thing
over and over again. In the past, that's lead to a disaster.
I have a couple Linux VMs at around the 30GB size, and it's just
too much work to archive a thing like that. Some of the other
VMs are a bit smaller, and if there was something valuable in there,
it might be more practical to back up. Most of my VMs aren't for
serious work, and are throw-aways. If they die, I won't be too
upset.

I would at least keep your source files for your software development,
somewhere other than inside that .vhd. Maybe ZIP up the source
tree once in a while, and copy it back to the host side for backup.
The rest of the environment can probably be bolted back together if
it broke.

Paul

 

[RayLopez99]

On Monday, October 8, 2012 4:58:58 AM UTC+3, Paul wrote:

Thanks Paul. Good advice in here. Indeed, I notice that taking multiple snapshots will "bloat" your virtual folder. I think what is happening is that essentially VM VirtualBox is simply doing an XCopy of sorts within the virtual folder. Something you can do yourself to an external USB drive and not make your VM folder bloated. So I try and keep the 'snapshots' down tojust one at most.

As for HD Tune, I downloaded the program, and have 15 days to test it out. I will run whatever tests they have, but if you have a 'favorite' test therein to check I/O bottlenecks let me know.

RL

 

[Paul]

On Monday, October 8, 2012 4:58:58 AM UTC+3, Paul wrote:

Thanks Paul. Good advice in here. Indeed, I notice that taking multiple snapshots will "bloat" your virtual folder. I think what is happening is that essentially VM VirtualBox is simply doing an XCopy of sorts within the virtual folder. Something you can do yourself to an external USB drive and not make your VM folder bloated. So I try and keep the 'snapshots' down to just one at most.

As for HD Tune, I downloaded the program, and have 15 days to test it out. I will run whatever tests they have, but if you have a 'favorite' test therein to check I/O bottlenecks let me know.

RL

Just try a read bandwidth test. That should be enough to get
some idea of the transfer rate supported.

(This version is free and an earlier version. I use this for
simple read-only testing of bandwidth.)

http://www.hdtune.com/files/hdtune_255.exe

Now, I've never tried this before, so this is a surprise.
This is a 34 GB virtual disk, holding about 12 GB of files.
Two thirds of the disk has high bandwidth transfer, because
in fact the disk drive light does not flash when that portion
of the disk is traversed. A .vhd uses "sparse" storage, and
sectors with all-zeros content are not actually stored on disk.
So the 565MB/sec sections, are not really being read off the
host disk. Other sections appear to transfer at 90MB/sec. But the
interesting part, is the valley spikes which go down to 1.3MB/sec.
Maybe you'll see more of that, than the higher transfer rate stuff.
If your compile activity is getting more of the 1.3MB/sec transfers,
that can't be good for it.

http://img196.imageshack.us/img196/8586/hdtunew2kvpc2007.gif

The "add-ons" path is perhaps the best performing path of
the lot. But not one you'd be using when compiling. Some
VMs support drag-n-drop from the host GUI to the guest GUI,
and then the file is copied from a host disk, to a guest virtual
disk. That can be a bit faster, than the path used when the
guest does its own I/O under local control (which is what
your compiler in the guest would be doing).

The host OS has file system caching, and some of the sectors
being read over and over again in the guest, might take advantage
of host caching. It means, the guest can get some advantage
from a host having more spare memory sitting around (as spare memory
can be used by the host file cache).

Still, that curve is not even close to what I imagined it would be

Paul

 

[RayLopez99]

Just try a read bandwidth test. That should be enough to get

some idea of the transfer rate supported.



(This version is free and an earlier version. I use this for

simple read-only testing of bandwidth.)



http://www.hdtune.com/files/hdtune_255.exe



Now, I've never tried this before, so this is a surprise.

This is a 34 GB virtual disk, holding about 12 GB of files.

Two thirds of the disk has high bandwidth transfer, because

in fact the disk drive light does not flash when that portion

of the disk is traversed. A .vhd uses "sparse" storage, and

sectors with all-zeros content are not actually stored on disk.

So the 565MB/sec sections, are not really being read off the

host disk. Other sections appear to transfer at 90MB/sec. But the

interesting part, is the valley spikes which go down to 1.3MB/sec.

Maybe you'll see more of that, than the higher transfer rate stuff.

If your compile activity is getting more of the 1.3MB/sec transfers,

that can't be good for it.



http://img196.imageshack.us/img196/8586/hdtunew2kvpc2007.gif



The "add-ons" path is perhaps the best performing path of

the lot. But not one you'd be using when compiling. Some

VMs support drag-n-drop from the host GUI to the guest GUI,

and then the file is copied from a host disk, to a guest virtual

disk. That can be a bit faster, than the path used when the

guest does its own I/O under local control (which is what

your compiler in the guest would be doing).



The host OS has file system caching, and some of the sectors

being read over and over again in the guest, might take advantage

of host caching. It means, the guest can get some advantage

from a host having more spare memory sitting around (as spare memory

can be used by the host file cache).



Still, that curve is not even close to what I imagined it would be



Paul

Thanks Paul. I just tested the free version and it looks good. It is 'path dependent' meaning as activity increases on your hard drive, the graph will show the bandwidth decreasing, etc. This is better than a "static test"that just gives you an average value. I've not tested in on the virtual drive yet but, as you say, there should be a slowdown.

RL