ah, but it makes perfect sense if I want to just have some data on the VD's and use them in my unRaid on full distro's experiments

 

Oh, yes, a sandbox unRAID.  That too.  I always keep some such virtual unRAIDs handy for experiments.

I wal just pointing out that you can also have a fully functional Pro unRAID with real disks out of a virtual box.

 

 

What about vmware ESX? Can it present the drive underneath as an SATA Drive?

I'm only used to vmware workstation & vmware server.

 

 

Do yourself a solid and try the Sun version of VirtualBox.  I like it much better than VMware.  Haven't played with ESX, it's too hardware picky as far as I can tell.  And unlike VMware Server, Virtual Box Let's you have as many drives as you want.

 

Do yourself a solid and try the Sun version of VirtualBox.  I like it much better than VMware.  Haven't played with ESX, it's too hardware picky as far as I can tell.  And unlike VMware Server, Virtual Box Let's you have as many drives as you want.

 

I read ya, just that I'm so invested in vmware (have been for years).

I have it all over at home and work. I considered the virtual box in the past. I may revisit.

BTW, although I used virtual hard drives to use as a sandbox, I could just have easily used raw access to real hard drives, and there doesn't appear to be a limit on the number of drives, unlike VMware which, I believe still limits you to 4 drives...

BTW, although I used virtual hard drives to use as a sandbox, I could just have easily used raw access to real hard drives, and there doesn't appear to be a limit on the number of drives, unlike VMware which, I believe still limits you to 4 drives...

 

Vmware does not just limit you to 4 drives. It's 4 IDE drives.

If you configure them as SCSi the limit is higher. The issue is that the unRAID kernel does not support the buslogic or LSI scsi adapters. If it did, this limit would not be imposed.

 

The other issue would them be, the interface with emhttp and accessing the status data (spinup/spindown/temp).  I believe emhttp is only designed for sata drives.

If it can handle scsi drives then it should work better.

 

Does the latest vmware environment allow raw access to SATA?

Does the latest vmware environment allow raw access to SATA?

Sorry I am not familiar with vmware, but VirtualBox works nicely with SATA disks.

 

Does the latest vmware environment allow raw access to SATA?

Sorry I am not familiar with vmware, but VirtualBox works nicely with SATA disks.

 

... WITH a virtual SATA controller

Caveat: Performance is abyssmal.  Parity check is running about 6mb/sec Thank God I only created 100gb drives

 

Please check performance with modern 7200rpm SATA Raw Disks.  Just a single unprotected disk would be great. 

 

I very much want to run unRaid in a VM and have since my first post on these forums.  I did and do have unraid Basic running in vmware but with the limits of 4 IDE disks I never tried RAW disk access.  Are you running on hardware that supports VT-x or AMD-V?

 

If Virtualbox Raw Disks support spinup/spindown, smart test & drive temps and if performance is just decent I would look to move my production unraid environment to a Virtualbox guest in Windows 7 x64 host ["guest" & "host" in vmware vernacular - is vbox talk the same?].

 

I really want to eliminate a running computer if I could. 

It'd be great if Lime Tech could pre-package a virtual machine of each unRAID build, ready to be tweaked for a given hardware instantiation (e.g.,a particular USB key/license and set of physical drives).

 

But I'm no expert on either unRAID or various VM technologies--is this feasible?

 

Boy, it would be great--a way potentially to harness a lot of wasted CPU time without buying another computer.

IMO, No; it's not a feasible use of Lime-Tech time. I'd rather they focus on unRAID 5.0.

IMO, No; it's not a feasible use of Lime-Tech time. I'd rather they focus on unRAID 5.0.

 

+2... cuz it's 1 higher then +1. 

I meant to say "stable release" not build--major misphrasing there.

 

In any event, I would imagine this would have extremely limited appeal to people who've already got unRAID set up and running fine on a very low-end PC, but it might have significant appeal to those who'd love to set up something like this without dedicating a PC to it alone, if it were simple enough for those customers to set up very reliably.

... pre-package a virtual machine ... would have extremely limited appeal to people who've already got unRAID set up

Not quite.  I have my unRAID all set up, and still I use a virtual unRAID for sandbox all the time.

I wouldn't bother Limetech with that.  Setting up unRAID in a virtual machine is a relatively simple exercise and you can do it yourself.

 

... pre-package a virtual machine ... would have extremely limited appeal to people who've already got unRAID set up

Not quite.  I have my unRAID all set up, and still I use a virtual unRAID for sandbox all the time.

I wouldn't bother Limetech with that.  Setting up unRAID in a virtual machine is a relatively simple exercise and you can do it yourself.

 

 

That's good to know.  Is it then feasible, in your opinion, to have unRAID always on and with direct access to array physical drives within a VM running on a stable XP box, e.g.?  (Seems like a fair number of people in other threads have had problems.)

 

Sorry if my questions are too newb for words--I'm new to actually using VMs (versus toying with them), and even newer to unRAID (just looking, but with interest).

I don't have a clue either why the MAC address is listed in the config. I once installed the free version on a stick for a demo machine, then after receiving the licensed key I copied over the config files to the new stick (including the old MAC address) and had some problems getting up and running on the new machine. Took me some time until I got to see the MAC address of the old computer in the config files on the new stick.

I don't have a clue either why the MAC address is listed in the config.

The "HWADDR=..." line gives a way to override the MAC address of the NIC.

That line can be safely deleted, and the server will use the native MAC address of the NIC.

 

Oops, why not list the interface like anyone else?

I mean that specifying the interface name like eth0 or eth1 is probably a more flexible solution than including the MAC address.

Sounds good!