virtualbox.org

Hi,

I'm a Virtualbox newbie; I just installed (and am trying to learn how to use) 3.2.1.0 (not OSE) on OS X 10.6.4. I've noticed that when I create a raw-partition VMDK, it only seems to work if I attach it to an IDE controller, not a SCSI or a SATA one. I haven't tried SAS yet.

I searched the forums and found this: http://forums.virtualbox.org/viewtopic. ... 5&p=146390 -- which doesn't really help. I'd rather not have to use IDE since if this works I plan to give my VM a 4 TB raw partition on my (the host computer's) RAID, and I doubt if that big of a virtual disk will work with an emulated IDE controller.

Here's what I'm doing: (output from commands deleted as it is a LOT of text -- I can post the output from the commands if people want to see it, though)

VBoxManage createvm --name test1 --ostype FreeBSD_64 --register
VBoxManage modifyvm test1 --memory 512 --rtcuseutc on --nic1 bridged --bridgeadapter1 en0:

VBoxManage storagectl test1 --name sata_1 --add sata --hostiocache off
VBoxManage internalcommands createrawvmdk -filename /Volumes/corridor_vms/disks/test1_1.vmdk -rawdisk /dev/disk1s2 -register
VBoxManage modifyhd /Volumes/corridor_vms/disks/test1_1.vmdk -type writethrough
VBoxManage storageattach test1 --storagectl sata_1 --port 0 --device 0 --type hdd --medium /Volumes/corridor_vms/disks/test1_1.vmdk

VBoxManage storagectl test1 --name ide_1 --add ide
VBoxManage openmedium dvd ~/FreeBSD-8.1-RELEASE-amd64-dvd1.iso
VBoxManage storageattach test1 --storagectl ide_1 --port 0 --device 1 --type dvddrive --medium ~/FreeBSD-8.1-RELEASE-amd64-dvd1.iso

VBoxManage setproperty vrdpauthlibrary VRDPAuthSimple
VBoxManage modifyvm test1 --vrdp on --vrdpport 7123 --vrdpaddress 127.0.0.1 --vrdpmulticon on --vrdpauthtype external
VBoxManage setextradata test1 VRDPAuthSimple/users/(redacted) (redacted)

> VBoxHeadless --startvm test1 --vrdp=config
Oracle VM VirtualBox Headless Interface 3.2.10
(C) 2008-2010 Oracle Corporation
All rights reserved.

Listening on port 7123.
Error: failed to start machine. Error message: VD: error VERR_NOT_SUPPORTED opening image file '/Volumes/corridor_vms/disks/test1_1.vmdk' (VERR_NOT_SUPPORTED).
VD: error VERR_NOT_SUPPORTED opening image file '/Volumes/corridor_vms/disks/test1_1.vmdk' (VERR_NOT_SUPPORTED).
Failed to open image '/Volumes/corridor_vms/disks/test1_1.vmdk' in read-write mode rc=VERR_NOT_SUPPORTED (VERR_NOT_SUPPORTED).
Failed to attach driver below us! Not supported. (VERR_NOT_SUPPORTED).
AHCI: Failed to attach drive to Port0 (VERR_NOT_SUPPORTED).
Unknown error creating VM (VERR_NOT_SUPPORTED)


However, when I then do this:


VBoxManage storageattach test1 --storagectl sata_1 --port 0 --device 0 --type hdd --medium none
VBoxManage storagectl test1 --name sata_1 --remove
VBoxManage storageattach test1 --storagectl ide_1 --port 0 --device 0 --type hdd --medium /Volumes/corridor_vms/disks/test1_1.vmdk

> VBoxHeadless --startvm test1 --vrdp=config
Oracle VM VirtualBox Headless Interface 3.2.10
(C) 2008-2010 Oracle Corporation
All rights reserved.

Listening on port 7123.

It works fine.

Any clues? Is there some better place I should post this? Should I file a bug?

Thanks!! BTW, the above is much further than I got with VMWare Fusion -- boy was that a waste of $50. So I'm glad to be in the VirtualBox camp. :-)

My general attitude towards the raw disk/partition access feature: it's dangerous, for expert users only. Meaning that if you need help getting it working then you probably shouldn't be using it.

mpack, thanks for the response! I think any disk in writethrough mode (whether it's a raw-partition one or not) is going to be dangerous *in conjunction with snapshots*. Since I really want raw-partition disks, and I really want writethrough mode, my answer to that is "never ever ever ever take a snapshot, or use savestate". I also think VMDKs that refer to an entire host disk are dangerous; mine refers to a specific partition (I'm not using -partitions for that; I'm just passing in a block device that *itself* refers to a partition).

Reading between the lines of what you wrote, though -- is createrawvmdk kind of an "ugly stepchild that nobody wants to fix when it gets broken"? Like, is it likely that for various releases of VirtualBox, sometimes createrawvmdk will work and sometimes it won't, and that's just how it is? Also, would I be likely to have better luck with the OSE?

Thanks again!

To answer the last first: the OSE is exactly the same product - from the same code - with just a small number of bits missing, none of which have anything to do with raw, SATA etc IIRC.

I'm not aware that the devteam treats raw disk access like the ugly stepsister, it's just me who does that. For me it's noticable how every newbie who joins the site has gone directly for that feature, whereas I don't know that any of the most experienced users here ever bother with it. There are simply precious few valid reasons for using it: it's usually easier to create a virtual OS image from scratch, or P2V the existing one.

In response to your original query: it doesn't make much sense to me. I would have thought that disk controller virtualisation doesn't know or care what type of disk is behind the virtual I/O interface it accesses to get data. More likely IMHO is that something about your guest means it doesn't like SCSI or SATA controllers, making the raw disk stuff a red herring.

mpack wrote:There are simply precious few valid reasons for using it: it's usually easier to create a virtual OS image from scratch, or P2V the existing one.

Heh. My reason isn't that I'm trying to use an existing OS install -- in fact the partitions I'm using have had /dev/urandom dd'ed onto them. I've taken a 5TB RAID and created eight 64GB partitions, four 128GB ones, and one 4TB one, and I'm anticipating that every time in the next several years that I want to make a new VM, I'll have a partition of the right size to do it in. I'm a bit more comfortable that way because it's just fewer layers that my data has to go through before it gets to the disk, and fewer things that could go wrong. So, actually, if I were to become convinced that I'd actually get *more* reliability by using a VDI, due to the likelihood of raw VMDKs breaking in future versions of virtualbox, I'd do the VDI thing. It's just that right now, it seems like the reverse to me.

mpack wrote:In response to your original query: it doesn't make much sense to me. I would have thought that disk controller virtualisation doesn't know or care what type of disk is behind the virtual I/O interface it accesses to get data. More likely IMHO is that something about your guest means it doesn't like SCSI or SATA controllers, making the raw disk stuff a red herring.

It doesn't make much sense to me either! But there you go. There have clearly been threads about this before, as well as threads about emulated DVD-ROM drives only working in IDE controllers: http://forums.virtualbox.org/viewtopic. ... 1&p=118738 (I also experienced this, but I really don't mind if my DVD-ROM is on IDE so I didn't make a huge fuss).

And there is no guest OS installed yet -- heck, there's not even a partition table inside the emulated disk yet. And the error was coming from VBoxHeadless itself -- it didn't even manage to start the VM successfully.

I guess, boiled down, here's my question. Is it likely that raw VMDKs on controller types other than IDE will be supported soon, and will continue to be supported? If so, I'll live with IDE for now. Is it likely that raw VMDKs will never be supported on controller types other than IDE, and might be broken even on IDE in some future version of VirtualBox because nobody uses or tests them? If so, I'll go with VDI.

Thanks again!

On the issue of raw VMDK reliability, it's the same as the underlying disk reliability, meaning it can of course be affected by power cuts and by mechanical and software failures. However if you are using RAID then perhaps these are non-issues for you. The primary advantage of a VDI is that its portable, hence it can be easily copied to another host or to backup media. If done properly this of course creates redundancy that makes the VDI solution very reliable, and far more flexible than the solution you are considering.

Considering that the raw vmdk file is created as IDE, why not do the simple thing and use it as IDE, as VMware, Parallels do with BootCamp?