OSX RamDisk as Raw for Win7 VM
Posted: 26. Dec 2014, 22:46
Hi,
I don't spend much time in the Forum but I just figured out how to make this work and thought it might help someone else. Here' the scenario:
I'm running a Windows 7 VM on OSX to host Visual Studio for some Windows development I'm doing. As it's a very large Solution consisting of thousands of small files; The virtual disk inside the VM is a bit of a bottleneck. The solution itself is only 400MB so I thought a RAMDisk would speed things up. My first attempt involved creating a RAM disk on OSX and using the VBox "Shared Folders" to access it in the Windows VM. While this does work, and probably would work for most people, the solution I'm developing is based on a Framework that has issues when source files are located on "Network Drives". I haven't looked at the VBox API but I presume they are using SMB for their shared folders; at least Visual Studio seems to think so. So the next idea, and the one I'll publish here, involves creating a Ram Disk in OSX as a RAW block device, _not mounting it_, and using the VBox shell utilities to create a RAW to virtual disk mapping for the VM.
Here's the procedure:
1) Start an OSX shell. You'll need to be root for this, I tend to sudo su, do all my work and then kill the shell but if you want to sudo each command that's prefectly acceptable.
2) sh-3.2# hdid -nomount ram://8388608 --> This will create a ram drive of 4GB as a virtual device in /dev. The output of that command, on my machine is:
/dev/disk4
The main thing to note here is that this is now a raw block device with no file system and is _not_ mounted by OSX. Most of the other articles that I read wanted you to create the block device, format it and mount it all in one step.
3) VBoxManage internalcommands createrawvmdk -filename "/Volumes/SSD/VirtualBox/Ultimate/ram.vmdk" -rawdisk /dev/disk4
In this step I am using the VBoxManage command to create a rawvmdk file at the specified location called ram.vmdk which points to /dev/disk4 (the raw block device created in the previous step). This is a mapping file similar to other virtual environments; I've done similar things in OSX to attach to RAW LUN's or internal SATA drives.
4) chown Wolfie /dev/disk4
chown Wolfie /Volumes/SSD/VirtualBox/Ultimate/ram.vmdk
This step is important because both the block device and mapping file were created as root. You have to give your regular user owenship of these constructs or you will get permission errors when you try to consume them.
Then all you have to do, and I used the GUI for this, is edit your Virtual Machine to add the new disk. I added a new SAS controller and then added the ram disk to that. When you boot into your Windows VM the new disk will not immediately be available. As far as Windows is concerned you've added a new controller and hard drive. You have to go into the DiskManagement tool, add the disk (which should popup), format it with a filesystem (NTFS) and assign a drive letter. Be careful not to assign a drive letter that may already be assigned by shared folder mappings as they will take priority and the new disk will not appear in Windows Explorer.
Once it's formatted go ahead and copy your working files to it. Now this is the cool part. When you reboot the VM everything copied into the RAM drive persists. This is due to the fact that the backing store is a block device on OSX, not in Windows. If, however, you reboot OSX you will nuke the contents of your RAM drive and, in fact, you'll need to re-create the RAM drive block device (steps 1 & 2). I'm sure you can easily put these in a startup script, I haven't thought that through yet but I expect it's trivial.
And the next thought, which I will have to do some reading on, would be to use DRBD to asynchronously replicate the contents of the RAM block storage device to a physical file somewhere on your OSX SSD. (Lars?) This would give you a pseudo write cache. And if some really clever bunny out there wanted to the whole idea could be wrapped up in such a way that the RAM device backed onto a physical store and provided a 4GB (or whatever size) cache for up to 4GB worth of recently accessed files. I'm pretty sure most of this could be accomplished using the existing OSX and VBox tools without having to write much code at all; this sort of thing, in my opinion, falls into the category of "configuration" not development. At least my old SysAdmin brain tells me so...
Maybe there's a clever bunny at Oracle who wants to pick this up as a feature request for a future edition of their already awesome product.
Hope that's helpful to someone.
/W
I don't spend much time in the Forum but I just figured out how to make this work and thought it might help someone else. Here' the scenario:
I'm running a Windows 7 VM on OSX to host Visual Studio for some Windows development I'm doing. As it's a very large Solution consisting of thousands of small files; The virtual disk inside the VM is a bit of a bottleneck. The solution itself is only 400MB so I thought a RAMDisk would speed things up. My first attempt involved creating a RAM disk on OSX and using the VBox "Shared Folders" to access it in the Windows VM. While this does work, and probably would work for most people, the solution I'm developing is based on a Framework that has issues when source files are located on "Network Drives". I haven't looked at the VBox API but I presume they are using SMB for their shared folders; at least Visual Studio seems to think so. So the next idea, and the one I'll publish here, involves creating a Ram Disk in OSX as a RAW block device, _not mounting it_, and using the VBox shell utilities to create a RAW to virtual disk mapping for the VM.
Here's the procedure:
1) Start an OSX shell. You'll need to be root for this, I tend to sudo su, do all my work and then kill the shell but if you want to sudo each command that's prefectly acceptable.
2) sh-3.2# hdid -nomount ram://8388608 --> This will create a ram drive of 4GB as a virtual device in /dev. The output of that command, on my machine is:
/dev/disk4
The main thing to note here is that this is now a raw block device with no file system and is _not_ mounted by OSX. Most of the other articles that I read wanted you to create the block device, format it and mount it all in one step.
3) VBoxManage internalcommands createrawvmdk -filename "/Volumes/SSD/VirtualBox/Ultimate/ram.vmdk" -rawdisk /dev/disk4
In this step I am using the VBoxManage command to create a rawvmdk file at the specified location called ram.vmdk which points to /dev/disk4 (the raw block device created in the previous step). This is a mapping file similar to other virtual environments; I've done similar things in OSX to attach to RAW LUN's or internal SATA drives.
4) chown Wolfie /dev/disk4
chown Wolfie /Volumes/SSD/VirtualBox/Ultimate/ram.vmdk
This step is important because both the block device and mapping file were created as root. You have to give your regular user owenship of these constructs or you will get permission errors when you try to consume them.
Then all you have to do, and I used the GUI for this, is edit your Virtual Machine to add the new disk. I added a new SAS controller and then added the ram disk to that. When you boot into your Windows VM the new disk will not immediately be available. As far as Windows is concerned you've added a new controller and hard drive. You have to go into the DiskManagement tool, add the disk (which should popup), format it with a filesystem (NTFS) and assign a drive letter. Be careful not to assign a drive letter that may already be assigned by shared folder mappings as they will take priority and the new disk will not appear in Windows Explorer.
Once it's formatted go ahead and copy your working files to it. Now this is the cool part. When you reboot the VM everything copied into the RAM drive persists. This is due to the fact that the backing store is a block device on OSX, not in Windows. If, however, you reboot OSX you will nuke the contents of your RAM drive and, in fact, you'll need to re-create the RAM drive block device (steps 1 & 2). I'm sure you can easily put these in a startup script, I haven't thought that through yet but I expect it's trivial.
And the next thought, which I will have to do some reading on, would be to use DRBD to asynchronously replicate the contents of the RAM block storage device to a physical file somewhere on your OSX SSD. (Lars?) This would give you a pseudo write cache. And if some really clever bunny out there wanted to the whole idea could be wrapped up in such a way that the RAM device backed onto a physical store and provided a 4GB (or whatever size) cache for up to 4GB worth of recently accessed files. I'm pretty sure most of this could be accomplished using the existing OSX and VBox tools without having to write much code at all; this sort of thing, in my opinion, falls into the category of "configuration" not development. At least my old SysAdmin brain tells me so...
Maybe there's a clever bunny at Oracle who wants to pick this up as a feature request for a future edition of their already awesome product.
Hope that's helpful to someone.
/W