• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Project: Rackmount Overkill

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
speaking of rails have u tried any of the istar-usa ones? they are pretty cheap, but they glide so smooth and easy 100 times easier than my norco rails. not exactly the heaviest duty rails in the world, but we arent towing a truck with them lol. thats what i have on my 4u and i like them quite a bit better than my norco rails i have. only thing i didnt like was the square hole setup, but it looks like your rack is made to accept those type :thup: mine isnt.
 
Got the shelf and installed it yesterday. It works really well. The adjustment system could use some work to make it easier to use, but I really can't complain. It would be nice if they would use "keyed" bolts to not allow them to spin in place so you didn't have to remove the shelf to change the depth or tighten them when you get it set. Once set though, it is solid. They don't show it in the pictures well, but there is support along the center down the length of the shelf, which I was worried about with Ruby being so fat (god Ruby cmon seriously). It has no problems being right up against the R710 and it doesn't touch it.

The only downside with this method is that I lose a unit of space for the shelf and I can't pull the case out of the rack. With nothing above it, however, this isn't too much of an issue. If I start adding more servers, this could be problematic.

DSC_0077.JPG
 
It isn't a final decision. I just wanted to get Ruby off of (literally) sitting on top of the R710. Going with the R510 and SAS expander is an option, but I still have to think on it. It limits me in certain areas, but opens up in others. For one, it will draw less power and put out less heat, which will be nice. On the other hand, it has only 16 drive bays unless I buy another unit.

If I could use the internal SAS bays of the R510 with the M1015, that would give me four more slots minimum, eight if I wanted them all. And it isn't that I can't do it, that part is very easy. The problem is that the server will complain (orange light) if it doesn't see both SAS backplanes. I can ignore this, but if a real problem occurs, I won't notice.

I've always told people that when you build a system or do an upgrade, don't build it at capacity. Meaning, if you need 4 TB disk space now, build it slightly bigger in case you need more immediately, and allow for the addition of more disks in case you need more in the future. That way you aren't wasting money by having to constantly rebuild the server every time you hit the cap. I follow my own advice.
 
It monitors the backplane and disk health. If it isn't connected, it thinks something is wrong, so it sets off the silent alarm. You can see that in all my previous pictures it always has an orange screen. I can't connect the backplanes to the M1015 because I'd be passing it through to a virtual machine. Analogy would be pulling the rug out from under yourself. Even if that would allow the Dell hardware to see the status of the backplanes, what disks would the bare metal operating system have access to? It'd crash.

Interesting that you can flash it to a H700 though, I didn't know that.
 
I'd like it to be more reliable than that and I would need disk space. That is also assuming that the Dell server itself would be able to see the backplanes through a passed through controller, which I really doubt.

It would be easier to run a Dell controller in its own (stock) spot along with my own controller in the back, if I wanted to do this "right". I don't want to hack this together, especially when this is storing important files and I rely on it working.
 
If I understand this correctly, you are using VT-d / however AMD calls it to pass the whole controller to the VM.

Why are you doing that instead of something "easier" such as raw device mappings? I reckon I have not researched this or the performance / security / reliability impact it might have, but that's the setup that I am running right now and so far, no problems. Of course my array is way humbler than your thiderastic storage.
 
I don't understand your question. Passing the whole controller through is mapping the raw device and that is what I'm doing.
 
I don't mean the controller, I mean the disk only. The block device, not the whole controller. Adding a "virtual drive" to the virtual controller that is actually the real drive and is detected by the guest OS as such.

I've been Googling and it seems Xen calls that "phy:/ mapping". I haven't searched enough though, so I don't really know how that works. I know that, on ESXi, it's called Raw Device Mapping for LUNs.
 
Passing through individual disks would be incredibly annoying.
 
How would the script differentiate between "system" disks and ones that need to be passed in? That wouldn't work well.
 
How many system disks do you have, anyway? You could always manually delete them from the VM.

And I think all your VM drives were Velociraptors? You could filter those out, somehow.

I am no programmer but surely there's a way to do that.
 
You are missing the point though. If I make any serious changes, then I'd have to make changes to the script in addition to whatever I need to do in the VM. I also don't think this would work well with live disk additions. I will not restart the server to add new disks because it is unnecessary. If I had to add the disk to a single drive array, I'd need to access the controller's configuration to create it. By default, XCP does not have this, but I could build it (which could break something).

As it stands now, if I pass through the entire controller, I just pop the disk in and the virtual machine sees it right away. No messing with scripts or trying to pass it through. It shows right up.
 
Last edited:
I'm running mine off a USB drive, you just want to make sure you clone it so you have a backup. A couple local SSD drives and everything else on the virtualized NAS.
 
There is not enough suspense or confusion in this thread. So:

Ruby and SED (r510) are going away. Bye bye.
 
Back