For some time now, we were looking for a quality dependable name brand “server”. The sole purpose of this server is for backup/DR storage. We use ShadowProtect for our customers and hanging 2TB USB drives off each server was becoming a hassle and a limitation. After a bunch of reading on the HP Proliant Microserver, I’m pretty impressed. For us, it hits a sweet spot. Not too big, not too small – smaller than a sheet of typical printer paper (height and width) but capable of housing 4 hotswap drives & possibly two more without much modification in the CDROM bay.
The server came with 1GB Ram and a 250GB harddrive. After burning FreeNAS 8.x ISO to CD, I plugged in a USB CDROM and 16GB USB memory stick. Booting off the CDROM and installing FreeNAS onto the USB stick took 15 minutes. Upon booting and initial configuration, FreeNAS could not detect the stock 250GB HD. Not sure why, but I read the same elsewhere. Also, integrating into ActiveDirectory did not seem to work so after much reading I decided to try FreeNAS 7.2.
FreeNAS 7.2 proved fruitful. ActiveDirectory integration was sound, the stock 250GB HD was detected; perfect. I decided to pull the 250GB and install (4) 1TB WesternDigital RE3 Drives. I prefer enterprise drives vs desktop for the MTBF. FreeNAS picked up the new drives after performing a RESCAN. Formatted each drive as “software-raid”. Plan is to use RAID5 yielding a 2.7TB volume. Initializing took about 2 hours.
Simple CIFS copy tests with its current configuration yielded 40MB/sec. After changing the “Send and Receive buffer sizes” from default 16MB (16384) to 128MB (131072) my performance improved by 20%.
A crazy idea I had was to boot from a USB VMware Stick, install FreeNAS as a VM and format 80% of space for storage. If for any reason a physical server melted, the ability to P2V on this server would be ideal; for temporary purposes obviously. A must, however, would be to upgrade the memory from 1GB to it’s maximum, which is 8GB.
But that’s not all that crazy is it?
I recently upgraded my ESXi host to 4.1u1 and forgot to enable SSH. In the past, from what I know, you can only enable SSH on a vmware host by the hidden feature or via menu on the console requiring you to be there or depend on a IP-KVM device.
Apparently, you can enable it remote!
- Fire up vSphere Client
- Go to Configuration Tab (vmhost must be highlighted not a vm)
- Select Security Profile (You should see a few services listed ie Remote Tech Support (SSH)
- Click Properties to the top right of the list
- Another box will appear – Select Remote Tech Support (SSH)
- Click Options
- Select your preference (Start Automatically)
- Click Start
- Click OK – That’s it!
You should be able to log in now via SSH
For the last 5-6 months I have procrastinated about upgrading a ESXi box to 4.1. I finally bit the bullet and started researching. Well, of course, a quick search engine query resulted in about a dozen or two “How-To’s”. Many of them look credible and tried a couple resulting in the bitter taste of fail. I came across this “SIMPLE” How-To and I’ll link it because it deserves much credit for my success….
Here it is…and thank you for the easy guide!
So I wanted to test using NexentaStor as an ISCSI target again. NexentaStor v2.5x ISCSI target less than stellar in speed, but I have been told it has greatly improved with COMSTAR. COMSTAR was written from the ground up, one of the last things the OpenSolaris project worked on. I initially created a small 50GB zvol to test a couple virtual machines. The speed appeared to be much improved so I decided to expand it, but when I did on Nexenta, VMware didn’t reflect it. So I tried to refresh the datastore in vsphere client, didn’t see it. I opened up the properties of the ISCSI datastore. There, you’ll notice a button the “increase” Total Capacity – Fig. 1. so I hit increase a viola! It increased it!

VMware needs to extend the volume and does so in seconds. Now I have more space to test with.
I’ve seen the subject above in many posts but mine was slightly unique. I could not get my VMware host to mount an NFS volume on another box. My VMware host could see the SAN/NFS host and vice versa. I burned a good 2 hours testing all the basics except for when I examined the “/etc/resolv.conf” on the SAN, which in my case, is Nexenta . Well, like a dummy, I had pointed my DNS to resolve from a VM which, you guessed it, is stored on Nexenta. I updated the “/etc/resolv.conf” with OpenDNS servers and gee whiz, my NFS daemon started working. Talk about a FACEPALM.