I am really interested in virtualizing unRAID since it requires very little cpu/ram, and I don't want to have to dedicate an entire box to it.

 

My results are as follows: I've been able to install unRAID inside a PV Slackware domU, but emhttp doesn't see the /dev/xvd devices as hard drives, and thus doesn't give me an option to select them in the webGUI.  I've emailed lime-tech about this issue, as it seems very minor.

 

I wanted to have unRAID in a PV domU versus an HVM domU for two reasons.  First, HVM is much slower than PV due to emulation.  Second, HVM has a limit of 4 disks.  I am currently setting up an HVM instance for testing purposes, but I have no doubt unRAID will work fine, albeit a bit slowly.

 

Anyone else have success with virtualizing unRAID, preferably non-emulated I/O?

Anyone else have success with virtualizing unRAID, preferably non-emulated I/O?

There was communication of it working well in virtualbox.

http://www.virtualbox.org/

Anyone else have success with virtualizing unRAID, preferably non-emulated I/O?

There was communication of it working well in virtualbox.

http://www.virtualbox.org/

 

Yep, virtualbox is essentially xen HVM, with emulated I/O calls.  In the case of unRAID, that's a pretty significant overhead due to its primary role as a fileserver.

Yep, virtualbox is essentially xen HVM, with emulated I/O calls.

 

I did not know this, thanks for opening my eyes wider.

 

Now about the /dev/xhd. emhttp might see them if you set the symlinks to the /dev/sd? devices.

Also, I would suggest trying smartctl and hdparm on the /dev/hdx devices.

If they can grab smartinfo and spin the drives down and up, you may be good.

So now we know emhttp doesn't parse /dev for devices, because I used mknod to create /dev/hda pointing to /dev/xvda (pretty much a low-level symlink) and the webGUI still ignored it.

 

Also, I got an email back from limetech specifically stating they only support /dev/hdX and /dev/sdX.  I emailed back to see if I could get a workaround.

 

I'm pretty sure hdparm and ACPI in general doesn't work in XEN, since all the drives are emulated, even in PV mode.  I'd rather just get it working first .

 

Speaking of which, I have successfully deployed unRAID in a Slackware 13.1 HVM domU running on a Debian Lenny (5.0) domU.  I'm currently rebuilding the parity, so I'll test read/write speeds sometime over the weekend.  I'm pretty certain I'll see at least a 50% hit from native, if not 75%, but speed really isn't an issue for me at the moment.

 

Hopefully support for /dev/xvdX is easily patched in, and we'll see it in a release soon.  

 

EDIT: Parity is being build at about 21 MB/s, which isn't that bad for write speeds (80-100MB/s normal, unraid writes 4x for each normal write).  It seems almost native?

EDIT: Parity is being build at about 21 MB/s, which isn't that bad for write speeds (80-100MB/s normal, unraid writes 4x for each normal write).  It seems almost native?

 

Depends on what drives you are using.

A modern 1tb or larger drive should get at least 50MB/s parity generate speed.

I would expect this to drop, but not to 21MB/s for parity build.

A write to the array via network should be over 12MB/s but in the upper 20's, low 30s.

 

I believe unRAID uses the other dev directories for determining what drives are available.

Try making the correct symlinks in the dev/disk/by-id and dev/disk/by-path directory.

I believe emhttp only looks at ata, sata, scsi

Yet if hdparm and smartctl do not work on the /dev/xvda, I would not expect emhttp to operate correctly.

I believe unRAID uses the other dev directories for determining what drives are available.

Try making the correct symlinks in the dev/disk/by-id and dev/disk/by-path directory.

unRAID relies on udev to symlink those directories.

You could look into adding a udev rule to do your linking.

 

Yet if hdparm and smartctl do not work on the /dev/xvda, I would not expect emhttp to operate correctly.

I've had disks that don't respond well to either hdparm or smartctl.

They still work in unRAID, with the only side effect that emhttp complains in syslog when it can't take its temperature,

and when it doesn't get the expected response on spin up/down commands.

(Disable unRAIDS spin up/down functionality for such drives, or emhttp will crash your server by quickly growing the syslog)

 

(Disable unRAIDS spin up/down functionality for such drives, or emhttp will crash your server by quickly growing the syslog)

 

Sometimes I wonder if using syslog-ng would be better, then you can set it to ignore the messages or automatically do other operations based on messages.

 

http://www.campin.net/syslog-ng/faq.html

http://www.campin.net/syslog-ng.conf

I believe unRAID uses the other dev directories for determining what drives are available.

Try making the correct symlinks in the dev/disk/by-id and dev/disk/by-path directory.

I believe emhttp only looks at ata, sata, scsi

 

Well, I tried using both mknod and udev rules to create /dev/sdx, etc. but emhttp still refuses to see it.  I suspect emhttp uses the kernel name for identification (which is /dev/xvdx).  Anyone know how to trick the what the kernel sees?

 

I guess my two options here are messing with the xen block driver, which would be scary, or wait for unRAID to support /dev/xvdX.  Any advice would be appreciated.