February 10, 20179 yr Wondering if this will cause any negative efftects on either my unRAID, or my regular drives, but here's what I'd like to do if possible. unRAID setup - 1 (for now) 500GB 850 EVO for cache drive. To be split into 2 VMs --- 2 1TB WD Blacks as data and parity. Also split for each VM to have half. Regular setup - 1 250GB Crucial mSata --- 1 1TB WD Black I'd like to have all the hardware for both of these setups sitting in the same machine, and be able to choose whether to boot to my unRAID setup, or my regular setup, depending on the situation. Is this possible? Will they interfere with each other? Is having the regular setup use a WD Black same as the unRAID going to confuse the unRAID? Any other concerns? I'm pretty sure this is my last question before I build the unRAID this weekend.
February 10, 20179 yr Community Expert It is not usually a good idea to dual-boot since if another operating system writes to any unRAID array disk it will invalidate parity. Why not run your "regular" as another VM under unRAID? Also, there isn't really any way to "split" array disks so that a certain amount is allocated for a specific use.
February 10, 20179 yr Author Written data to the parity disk ruining it makes sense, but Windows isn't like OSX where it randomly write .trash folders and crap like that to it, is it? Hmmm. The 2 gamers 1 CPU bulid log makes it look like if you set the SSD to cache, make 2 VMs with a little less than half of the SSD's total space, it doesn't have any issues splitting. I watch it again to make sure I didn't miss something.
February 10, 20179 yr Community Expert Not just the parity disk, but anything writing to any array disk is going to invalidate parity. If you write to an array data disk from outside unRAID, parity will no longer be in sync with that data disk. And in the general case there isn't a filesystem on the parity disk for anything to write to anyway without formatting it. What I meant about "splitting" is there is no way to reserve space for specific use. There is no problem having multiple things on one disk, but nothing to prevent one thing "taking more than it's share".
February 10, 20179 yr Author Not just the parity disk, but anything writing to any array disk is going to invalidate parity. If you write to an array data disk from outside unRAID, parity will no longer be in sync with that data disk. And in the general case there isn't a filesystem on the parity disk for anything to write to anyway without formatting it. What I meant about "splitting" is there is no way to reserve space for specific use. There is no problem having multiple things on one disk, but nothing to prevent one thing "taking more than it's share". So with the parity not having a filesystem on it, it shouldn't be that likely I accidentally write anything to ruin the parity, correct?
February 10, 20179 yr Community Expert So with the parity not having a filesystem on it, it shouldn't be that likely I accidentally write anything to ruin the parity, correct? Not just the parity disk, but anything writing to any array disk is going to invalidate parity. If you write to an array data disk from outside unRAID, parity will no longer be in sync with that data disk.
February 10, 20179 yr Community Expert Also, in your scenario with only one data disk, parity is a mirror, so it would have a filesystem. That's why I said "in the general case". The single data disk works just like the multiple data disk with parity, but the parity calculation winds up making the parity disk a mirror in the single disk case.
February 10, 20179 yr Author Bummer. The cache drive though, being a single SSD, and not being backed up to the data and parity disks (I failed to mention the cache drive would not interact with the parity at all. It would be standalone. Sorry) shouldn't be negatively affected by being attached when booting into Windows normally, right?
February 10, 20179 yr Community Expert Your original proposal would work if your other operating system never wrote to any of the unRAID disks. And if your other operating system is Windows, none of the unRAID disks will have a filesystem that Windows can work with natively anyway. Just trying to make sure you don't make a mistake. Windows might allow you to accidentally reformat or repartition your unRAID disks.
February 10, 20179 yr Author Oh. So you're just saying worst case scenario. I'm fairly confident I won't reformat an unRAID disk from Windows. But it's good to know that they shouldn't natively show up.
February 10, 20179 yr Also, there isn't really any way to "split" array disks so that a certain amount is allocated for a specific use. In this case, he's wanting to set up VM's to exclusively use a portion of the space, which can be done nicely by allocating a vdisk file of the size he wants to reserve. Specifically, boot volumes of 240GB on the cache pool and 490GB data volumes on the array disk for each VM. I don't think he wants to use any of the traditional NAS features, he just wants a hypervisor with data redundancy.
February 10, 20179 yr Author YES! Jonathanm! That's what I'm trying to do. Is unRAID the best solution for that? Or if I didn't care about redundancy am I better of going a different hypervisor route? First thing that comes to my mind as unRAID advantage, is that it will make the disks being used in the unRAID setup not natively read or writable on regular OS to keep me from messing VMs up.
February 10, 20179 yr YES! Jonathanm! That's what I'm trying to do. Is unRAID the best solution for that? Or if I didn't care about redundancy am I better of going a different hypervisor route? First thing that comes to my mind as unRAID advantage, is that it will make the disks being used in the unRAID setup not natively read or writable on regular OS to keep me from messing VMs up. Unraid is first and foremost a NAS, the hypervisor part is fairly new and subject to rapid frequent changes. I honestly don't know if there is a better fit for what you want, but unraid isn't primarily focused on what you are wanting to do. It may work, it may not, VM's with full hardware passthrough are tricky to get running well, especially with regards to hardware compatibility. My best advice is to download the free trial and give it a spin, there is really no way to say for sure without trying.
February 10, 20179 yr Why not try put the free vmware esxi ? If you need a pure hypervisor you cannot beat esxi imho.. Verzonden vanaf mijn iPhone met Tapatalk
February 10, 20179 yr Author Doing a quick search tells me that ESXi doesn't always play nice with NVIDIA GPU pass-through. According to Linus, unRAID is somehow able to do it no problem. And being there is a step by step with unRAID, I'll try that first. I'm not the best tinkerer.
February 10, 20179 yr It'll work with Unraid, its a great product. Be aware though, some tinkering -is- required..
February 10, 20179 yr Author Just to quickly revisit a different part of the first question that wasn't quite answered. Will unRAID get confused by the 3rd 1TB Black that is not a part of unRAID, or does unRAID use a drive identifier that is more unique than brand and model?
February 10, 20179 yr Community Expert Just to quickly revisit a different part of the first question that wasn't quite answered. Will unRAID get confused by the 3rd 1TB Black that is not a part of unRAID, or does unRAID use a drive identifier that is more unique than brand and model? unRAID keeps track of drives by their serial number, which is unique. It will not get confused. The various unRAID license levels are limited as to the number of drives you can have attached whether they are used by unRAID or not.
February 10, 20179 yr Just to quickly revisit a different part of the first question that wasn't quite answered. Will unRAID get confused by the 3rd 1TB Black that is not a part of unRAID, or does unRAID use a drive identifier that is more unique than brand and model? No, UnRAID won't be "confused" by the 3rd Black ... it will simply see it as an unattached drive and won't do anything with it. The configuration you outlined will work perfectly -- but (as trurl noted above) be aware that the "extra drives" for your "regular setup" will be counted as attached devices, so the configuration you've outlined will have a total of 5 "attached devices" (3 1TB Blacks and 2 SSDs). This will work fine with a Basic license (which supports up to 6 attached devices) ... but if you decide to add drives to either setup you will need to move to a Plus license if the total number of drives in the system exceeds 6.
February 11, 20179 yr I'm maybe missing something but why? What are you trying to achieve? Why not just run 3 VMs? Sent from my SM-G935F using Tapatalk
February 13, 20179 yr Author I'm maybe missing something but why? What are you trying to achieve? Why not just run 3 VMs? Sent from my SM-G935F using Tapatalk Because I would like to have the option to boot to the machine with all resources available on occasion.
February 28, 20179 yr I built a 3-headed VR rig w/ 3 GPUs. However, I'm pretty sure that I'll run into some game or application that doesn't play well as a VM. In that case, I'll want to dual boot into Windows. I think anyone who runs a VM gaming server would want the option to boot back to vanilla windows, to eliminate issues around virtualization. Maybe a certain game runs like a slug as a VM? Maybe some VR setup has a special USB device that won't work when forwarded to a VM. There's no way to debug these virtualization related issues without the ability to switch between VM and real windows. --Harper
March 1, 20179 yr Agree that the ability to boot to native Windows is a good thing -- especially if it's a high-performance gaming rig. There are plenty of fairly involved threads on here r.e. resolving issues with virtualization and hardware pass-through; graphics incompatibilities; etc. -- and being able to run natively is either a good way to simply bypass those issues; or at least to help diagnose them and find a workaround that lets the VM work better.
Archived
This topic is now archived and is closed to further replies.