• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

New All-In-One Build (Storage/Virtualization)

DevX81

[H]ard|Gawd
Joined
Dec 16, 2000
Messages
1,283
Just seeing what the consensus is on the following build, any tips/tricks for optimizing would be appreciated.

Antec 300 Case
Antec 500w PSU

Supermicro Mini ATX MB (Intel C202 chipset)
Intel Sandy Bridge Xeon (4c, 8t) 3.x GHz
16gb ECC Unbuffered RAM
IBM M1015 HBA (Going to go IT Mode)
2x OCZ 30gb SSD
4x Spinpoint F4 2tb
1x 4gb USB Key


Going to go ESXi 5 to the USB stick
One of the SSD's will use the onboard SATA to host a datastore for my OpenIndiana/Solaris Express install. (Seems overkill.. but I couldnt find a 2.5" drive for less that $60 (the cost of the ssd) right now).
M1015 Adapter will get passed through to the solaris install to provide the 4x drives for use as a ZFS RAIDZ (likely z1, maybe z2).
The other SSD will be used for the L2ARC for said set. (Unsure if going to use it on the IBM or the onboard sata ports).

Plan to host 4-5 low-usage VM's on this as well, which is why I am going ESXi and not just bare metal for the solaris install.
 
You can't put it on the onboard port and pass it in, since the onboard sata controller needs to be usable by esxi for the local datastore. You have 8 ports on the m1015 and are only using 4 for the zfs pool, so stick the l2arc ssd on a free hba port. Keep in mind that if you go raidz2, you are taking a 50% space hit, which is fine. The tradeoff is to then ask whether you are better off doing raid10 or raidz2, and the answer depends on your I/O usage pattern.
 
Got a question related to this...

I know that it is recommended to pass drives directly to the guest, but for the L2ARC what about using a SSD drive as a datastore and creating a virtual disk in the VM on that datastore as the L2ARC? Obviously directly attaching the SSD would be the best performance, but even with the overhead I would think the virtual disk would provide caching improvements wouldn't it?

OP... out of curiosty why install ESXi on USB if you are already going to use an SSD for a local datastore? 30GB is plenty of space for an ESXi + OI installation and would give you faster boot times than USB...
 
I would put esxi on usb just because if you have to reinstall esxi, you can play it safe and unplug the ssd local datastore. There is no performance hit from what I've been told having esxi on the usb stick (apart from slower bootload.) Hmmm, good point about the l2arc on local ssd - might be a win...
 
Actually the local storage controller does NOT need to be used by ESXi due to my usage of a USB thumb drive. However, I do not really want to attempt to passthrough the chipset controller, who knows what else might try to go with it.

I was thinking of making a datastore on the ssd rather than passthrough, unless it causes some weirdness that I havent experienced yet.

z2 vs 10, yep, that was something I thought of yesterday but forgot about in my post today. Still on the fence either way really.

You are correct, I should ditch the USB key. Main reason was i made two purchases. First did not include the SSD's (or even the M1015). Just a bit scatterbrained this morning it seems....
 
Maybe I am misunderstanding you? If you have a local datastore on a local drive, that drive has to be plugged into a controller port and that controller cannot be passed in. You cannot put a datastore on the usb thumb drive. Unless there is a disconnect here, I stand by my statement.
 
You have a point on the seperate ESXi install and datastore.. I may think about going back that route. Of course recreating my OI install and importing my pools shouldn't be too time consuming if I had to. My experience with booting ESXi from USB was pretty horrible though. I realize that ideally you wouldn't reboot the ESXi server if at all possible, but when it was required it took close to 10 minutes before ESXi and the OI VM had completely restarted....

DevX81.. you mention using a SSD as a datastore for the OI VM. Whatever controller this disk is attached to will have to be used by ESXi and cannot be passed to a guest VM. Unfortunately you can't use USB as a datastore also to house the OI VM, so at least one controller in your system will still have to be visible to ESXi and not passed through to a guest VM...
 
farscapesg1:

Yep, the onboard controller would remain non-passthrough. Just the HBA would get passthrough.

My thought was what you said. Both SSD's are connected to onboard SATA ports. One provides datastore for OI itself. The second provides a datastore to OI as well, however this 2nd datastore (with a 2nd VDMK inside) would be used strictly for L2ARC... hell, depending on the OI install size, I could just make two VMDK's on the first SSD, one for the install and one for cache. Spare ssd for... profit?
 
Oh crap, I just thought of something that might make the L2ARC on local datastore a bad idea. If someone makes a read request over the network, OI is first going to look in ARC, if it doesn't find it, it will then look in L2ARC. If it doesn't find it, it goes to the pool on the HBA. Consider what happens if it hits in the L2ARC: it will have to read the data from the L2ARC device, then transmit it back to the network client. But, if the L2ARC is on an ESXi local datastore, the cached data will have to be transmitted from ESXi to the OI VM, and then transmitted back to the network client. e.g. you will take a double network latency hit. Might still be okay if you have unrestricted VMCI set for the OI client, but I don't see how it's better than sticking that SSD on a free HBA port?
 
Need to get a 2nd SAS -> SATA breakout cable. That is about all that is holding me back, lol.
 
Oh good point, I did need two for mine. I completely forgot about that since I have 6 disks, and just had to bite the bullet and get two to start with :)
 
Back
Top