[ale] [OT] way cool, running spinrite and testing a physical hdd in a virtualbox vm

Ron Frazier (ALE) atllinuxenthinfo at techstarship.com
Sun May 26 18:57:11 EDT 2013


Hi all,

I wanted to share the results of an interesting experiment that I'm doing.

I'm upgrading a hard drive and wanted to run exhaustive spinrite testing 
on it before putting it into service. Normally, this requires booting 
the computer from the spinrite cd and giving it total control over the 
pc and the hdd so the diagnostic can run. I didn't like the idea of 
giving up the use of this pc for 3-4 days to analyze this 1TB drive. I 
had heard that you can run spinrite in a vm if you're careful. Based on 
a mention of it on Steve's podcast, I found the instructions and I've 
got it working. That's the good news. The bad news is that it's running 
4X slower than normal. So, it will take 14 days to process this drive, 
but I still have use of my pc, if I keep doing it this way.

This involves attaching a physical disk drive to virtualbox as though it 
was a virtual drive. This is called raw disk access, and it can be very 
dangerous. You must make absolutely sure that the vm doesn't access any 
drives that your host os is accessing. It's also very powerful though. 
Even if you don't want to run spinrite, these procedures might be useful 
for other purposes. I did this on windows, but you could probably do 
something similar on mac and linux.

First, you attach the hdd you want to test to a port on your 
motherboard. At this point, I don't know how to do this with usb. I 
tried to access the usb ports in virtualbox. When I turned on usb 2.0, 
it said it needed an extension pack, so I gave up on that. Usb would be 
much slower than sata anyway. So, I have the new hdd attached to a sata 
port on the mb.

Next you want to take the disk offline so the host os doesn't do 
anything to it. This part is windows centric, so you guys can tell us 
how to do this in linux if you know.

The following page lists the procedure to take the disk offline.

http://blog.nerdimmunity.com/2012/06/25/spinrite-vmware-and-windows-7/

* Run an elevated command prompt (as Administrator), then run 
“diskpart”. Once in diskpart, issue these commands.
* list disk
* find the disk you want to work on
* select disk # (Replace "#". In my case select disk 3.)
* list disk (Again. The selected disk should have an asterisk by it.)
* offline disk
* attribute disk clear readonly
* rescan

You can verify the results by doing a list disk again.

See this image: 
https://dl.dropboxusercontent.com/u/9879631/spinrite-in-vm.png

In the upper left is the diskpart screen where I've verified that disk 3 
is offline. In the middle left is an image of the Windows disk 
administrator which also shows that this disk is offline. Now that you 
know the host os won't be messing with the hdd you're working on, you 
can use the following procedure to set up your vm and attach it to that 
physical disk.

http://romaimperator.com/?p=29

Here's a warning from this webpage about raw disk access in a vm. Make 
ABSOLUTELY sure you follow the procedure correctly.

Warning
Raw hard disk access is for expert users only. Incorrect use or use of 
an outdated configuration can lead to total loss of data on the physical 
disk. Most importantly, do not attempt to boot the partition with the 
currently running host operating system in a guest. This will lead to 
severe data corruption.

Once you're done following this procedure, you should have a vmdk file 
that is directly linked to the physical hard drive in question.

In my case, it is srvm-wd1tb-disk3.vmdk .

So, the name shows what it's doing and which physical disk it's accessing.

You then create a vm to run spinrite. I used OS: other / dos and RAM: 32 
MB. You do not have to create a virtual disk drive for the vm to boot 
from if you boot from a spinrite cd. The upper right of the image I 
mentioned shows my virtualbox configuration for this vm. Note that, in 
the storage section, I have my hosts CD drive connected, and also the 
vmdk file that I mentioned. So, all the storage components the vm has 
access to are actual physical drives.

Once you're done with all that, you boot the vm, which boots from the CD 
in the physical drive, since that's first in the boot order. Spinrite 
starts up, and the only hard drive it thinks it has access to is the 
physical drive you've attached. At this point, you can proceed to test 
the drive, albeit very slowly.

The lower right part of that image shows spinrite running. The lower 
left part of the image shows it pegging one of my cpu cores at 100%.

After spinrite is done, or after you stop its function, power down the 
vm. Don't allow spinrite to reboot, which it will try to do if you press 
escape at the end.

Well, that's it. I'm using a program that requires exclusive control of 
a hdd, inside a vm, while still using my pc. Very cool. Yes, I know you 
can use something like badblocks while linux is running, but that wasn't 
my purpose here.

Misc notes:

* Do not shut down the host, change the drive cabling, and reboot. This 
will change the disk numbering. Even if you just reboot, it would be 
wise to check that the disk numbers are the same if you continue prior 
activity.
* You can clone the vm to run other copies of spinrite simultaneously. I 
think they could all boot from the same cd rom, or you could boot from 
an iso. Attach each vm to a different physical drive, which must also be 
offline. When you clone the vm, select the box to change all mac 
addresses on network adapters, although it may not matter for this 
purpose. Also, select a full clone, not a linked clone.
* I found a web page related to doing this on a mac, but have no way to 
try it. I haven't tried it on linux either.

http://jtsdigs.com/blog/2013/2/3/spinrite-on-a-mac-yes-you-can

* Finally, IMPORTANT - when you're done testing the drive and the vm is 
powered down, detach the vmdk file pointing to the physical drive from 
the vm. Go to the file menu in virtualbox and start the virtual media 
manager. DELETE the vmdk file that attached to the physical drive so you 
don't accidentally use it again and delete the vmdk file itself if 
virtual media manager doesn't do so. Otherwise, you could end up messing 
up the next thing you attach to that port on your motherboard.

Hope you find this interesting and helpful.

Sincerely,

Ron


-- 

(PS - If you email me and don't get a quick response, you might want to
call on the phone.  I get about 300 emails per day from alternate energy
mailing lists and such.  I don't always see new email messages very quickly.)

Ron Frazier
770-205-9422 (O)   Leave a message.
linuxdude AT techstarship.com
Litecoin: LZzAJu9rZEWzALxDhAHnWLRvybVAVgwTh3
Bitcoin: 15s3aLVsxm8EuQvT8gUDw3RWqvuY9hPGUU



More information about the Ale mailing list