unRAID Server Release 6.0-beta3-x86_64 Available

[limetech]

I can't believe I've gotten to sift through 2 pages of debate on nano in the announcement forums. Off topic much?

 

Me either, wtf?  IronicBadger already requested nano days ago and it's already in -beta4, I guess it was a PM where I told him that because obviously no one else got the message.  You want to use nano, go ahead.  You want to use vi, go ahead.  Can we stop talking about editors now???

 

Yes hoping to have a rudimentary webGui VM manager posted to github and included in -beta4 release.

[limetech]

As it stands right now, unRAID 6.0 beta2 to beta3 went from 256MB of total ram to over 512MB.

That's mainly due to inclusion of python and perl, and the package includes a lot of stuff not needed which I will eventually prune out.

 

We haven't even gotten to KVM which has A LOT more stuff than Xen does which I would expect to push it over 1GB if we continue to use a root ram file system.

If a Xen setup works, why would we need to include KVM at all?

 

[peter_sm]

Agree! Xen seems to work better than KVM, I liked KVM before, but have learn Xen, and no way using KVM longer 

 

//Peter

[WeeboTech]

As it stands right now, unRAID 6.0 beta2 to beta3 went from 256MB of total ram to over 512MB.

That's mainly due to inclusion of python and perl, and the package includes a lot of stuff not needed which I will eventually prune out.

 

My question on this one is, do we need it as part of the bzroot, or can it be installed in the /extras folder?

I know we are catering to a larger market now, but I question the need for these tools as the most basic usage of a lightweight NAS appliance.  Don't get me wrong, I'm a perl advocate.  I compiled my own miniperl as a static binary so i could have the most rudimentary perl interpreter do what i need to do in a speedy manner.

 

Do I need python to operate basic unRAID as a NAS?

 

Yes, memory is cost effective today, but if I'm running unRAID under ESX, then I have to think of who else could use that extra 256MB of memory vs a python interpreter that I'll probably not use.

 

points to consider.

If the /var/log/packages is up to date and allows removal of python/perl for us lightweight advocates, I guess that will suffice to allow easy removal.

 

Is it time to consider a unionfs?

 

If rootfs were on a tmpfs instead of a rootfs, then it can be swapped out.

[SchoolBusDriver]

If a Xen setup works, why would we need to include KVM at all?

 

SURVEY SAYS!

1. VirtFS (9P with virtio)

 

People can have all their VMs access / read / write / copy directly to the unRAID Drives / Cache Drive at close to block level speeds. Much better than having to use a file based protocol like NFS and Samba (which aren't even in the neighborhood of VirtFS) to copy LARGE GBs worth of data from our VMs to the Host (unRAID).

 

 

 

2. Video Card Passthrough is way better on KVM.

 

AMD RADEON 5xxx, 6xxx, 7xxx - Works

 

NVIDIA GEFORCE 7, 8, 4xx, 5xx, 6xx - Works <--- No Quattro Card required. Xen or ESXi cannot do this.

 

INTEL IGD - Sorta working but not there / stable yet.

 

3. KVM is more catered to home users and they are way ahead of Xen and ESXi when it comes to the things that we are going to want now and going forward.

 

Xen and ESXi does not have anything like VirtFS because they are more Business / Enterprise focused. A typical Xen / ESXi server / VMs are using 10GB /100GB+ speeds on their network and using block level protocols like iSCSI, FCoE, AoW, etc. to take advantage of those network speeds.

[NAS]

I can't believe I've gotten to sift through 2 pages of debate on nano in the announcement forums. Off topic much?

 

Me either, wtf?  IronicBadger already requested nano days ago and it's already in -beta4, I guess it was a PM where I told him that because obviously no one else got the message.  You want to use nano, go ahead.  You want to use vi, go ahead.  Can we stop talking about editors now???

 

Yes hoping to have a rudimentary webGui VM manager posted to github and included in -beta4 release.

 

Its really nothing at all to do with nano.

 

The real discussion (that was conveniently lost in the noise) is that we are slowly moving away from the model where all config is done via emHTTP or worst case the cifs config share to one where all guides are being written for the command line.

 

I believe we got this right the before and the move to SSH + console configs is a bad one.

 

Sure we need to do this now in the beta cycle but not in the stable.

 

[butlerpeter]

If a Xen setup works, why would we need to include KVM at all?

 

SURVEY SAYS!

1. VirtFS (9P with virtio)

 

People can have all their VMs access / read / write / copy directly to the unRAID Drives / Cache Drive at close to block level speeds. Much better than having to use a file based protocol like NFS and Samba (which aren't even in the neighborhood of VirtFS) to copy LARGE GBs worth of data from our VMs to the Host (unRAID).

 

 

 

2. Video Card Passthrough is way better on KVM.

 

AMD RADEON 5xxx, 6xxx, 7xxx - Works

 

NVIDIA GEFORCE 7, 8, 4xx, 5xx, 6xx - Works <--- No Quattro Card required. Xen or ESXi cannot do this.

 

INTEL IGD - Sorta working but not there / stable yet.

 

3. KVM is more catered to home users and they are way ahead of Xen and ESXi when it comes to the things that we are going to want now and going forward.

 

Xen and ESXi does not have anything like VirtFS because they are more Business / Enterprise focused. A typical Xen / ESXi server / VMs are using 10GB+ speeds on their network and using block level protocols like iSCSI, FCoE, AoW, etc. to take advantage of those network speeds.

 

This is why, a few pages back, I raised the idea of the VM related bits and pieces being created as plugins on top of a base 6.0 release that includes all the necessary kernel configs and modules.

 

That way both Xen and KVM can be supported, not all users will be affected by a huge growth in the size of the bzroot and users can have the choice of which VM platform suits their wants/needs best - possibly none for those who aren't interested in either.

[WeeboTech]

I can't believe I've gotten to sift through 2 pages of debate on nano in the announcement forums. Off topic much?

 

Me either, wtf?  IronicBadger already requested nano days ago and it's already in -beta4, I guess it was a PM where I told him that because obviously no one else got the message.  You want to use nano, go ahead.  You want to use vi, go ahead.  Can we stop talking about editors now???

 

Yes hoping to have a rudimentary webGui VM manager posted to github and included in -beta4 release.

 

Its really nothing at all to do with nano.

 

The real discussion (that was conveniently lost in the noise) is that we are slowly moving away from the model where all config is done via emHTTP or worst case the cifs config share to one where all guides are being written for the command line.

 

I believe we got this right the before and the move to SSH + console configs is a bad one.

 

Sure we need to do this now in the beta cycle but not in the stable.

 

Ahh, I get your point now /me slaps head.

Which is why I suggested the possibility of a browser based webGui editor.

[SchoolBusDriver]

This is why, a few pages back, I raised the idea of the VM related bits and pieces being created as plugins on top of a base 6.0 release that includes all the necessary kernel configs and modules.

 

That way both Xen and KVM can be supported, not all users will be affected by a huge growth in the size of the bzroot and users can have the choice of which VM platform suits their wants/needs best - possibly none for those who aren't interested in either.

 

That is a decision Tom has to make.

 

My idea about an ISO with 2 Partitions or WeeboTechs solves A LOT of problems.

 

It's not 2006 anymore and when Tom started with the root ramfs... Sickbeard, CouchPotato, Newznab, Plex, Tvheadend, Crashplan, Virtualization (for home users), etc. didn't exist.

 

The root ram FS makes unRAID a NIGHTMARE for what most users seem to be using / purchasing unRAID for. 85% of the 100,000+ posts in Support / Plugins / Applications / User Customization / Virtualization forums are a direct result of it. It's really hard to swallow the root ram fs makes supporting unRAID easier / less problematic pill at this point.

 

If you want to keep Prostaff who runs unRAID 4.7 and Windows 95 / XP happy... Fine. Make an unRAID "Commodore 64 Edition" and keep a root ram fs.

 

However, if most of your customer base (and the new business you hope to win) is into XBMC, CouchPotato, Sickbeard, Virtualiztion, etc. Make us an unRAID "21st Century Edition" with at least my method or Weebotechs. It will solved so many problems and with my method... A simple batch file or click in the WebGUI would default to 2nd Partition back to default.

[limetech]

In the 6.0-betas I've taken a "kitchen sink" approach of adding stuff in bzroot until I've completely solidified my understanding of Xen and it's requirements.  Probably -rc1 bzroot will be much smaller, but I'm leaning toward generating two bzroot's, one for Xen and for non-Xen, and eventually I suppose a third one for KVM.

[Dephcon]

Tom, you're a sexy beast!

 

<3

[SchoolBusDriver]

In the 6.0-betas I've taken a "kitchen sink" approach of adding stuff in bzroot until I've completely solidified my understanding of Xen and it's requirements.  Probably -rc1 bzroot will be much smaller, but I'm leaning toward generating two bzroot's, one for Xen and for non-Xen, and eventually I suppose a third one for KVM.

 

I just 5hit in my pants!

 

The Commodore 64 Edition was funny though, right? Even Prostaff1 has to laugh at that one.

 

He is damn proud of unRAID 4.7 and his Windows 95 / XP (is there a different at this point) VMs. I thought it was fitting.

[limetech]

However, if most of your customer base (and the new business you hope to win) is into XBMC, CouchPotato, Sickbeard, Virtualiztion, etc.

 

IMHO the proper solution to running these apps is to run them in a VM, perhaps via installing badger's "appliance" or similar.

[limetech]

In the 6.0-betas I've taken a "kitchen sink" approach of adding stuff in bzroot until I've completely solidified my understanding of Xen and it's requirements.  Probably -rc1 bzroot will be much smaller, but I'm leaning toward generating two bzroot's, one for Xen and for non-Xen, and eventually I suppose a third one for KVM.

 

I just 5hit in my pants!

 

The Commodore 64 Edition was funny though, right? Even Prostaff1 has to laugh at that one.

 

He is damn proud of unRAID 4.7 and his Windows 95 / XP (is there a different at this point) VMs. I thought it was fitting.

 

What are you on about? I honestly don't understand what you just wrote.

[meep]

As it stands right now, unRAID 6.0 beta2 to beta3 went from 256MB of total ram to over 512MB.

That's mainly due to inclusion of python and perl, and the package includes a lot of stuff not needed which I will eventually prune out.

 

We haven't even gotten to KVM which has A LOT more stuff than Xen does which I would expect to push it over 1GB if we continue to use a root ram file system.

If a Xen setup works, why would we need to include KVM at all?

 

While I haven't had a chance to run any tests or produce any metrics, it seems to me that my disk and network transfer speeds were much better when I had unraid and windows vms virtualised under arch/kvm than I have now with unraid dom0 / xen.

 

In addition, some devices that worked flawlessly for me in pci passthrough under kvm and throwing hissy fits (<-! Technical term) under xen.

 

I'll document comparative speeds if I get a chance.

 

[SchoolBusDriver]

What are you on about? I honestly don't understand what you just wrote.

 

I wouldn't worry about. I don't think you and I share the same sense of humor.

 

1. If you haven't already take a look at the following: http://lime-technology.com/forum/index.php?topic=31653.msg288903#msg288903

 

2. I think it is probably best that you have 3 separate releases Vanilla, Xen and KVM (if you decide to pursue it).

[needo]

1. VirtFS (9P with virtio)

ve at close to block level speeds. Much better than having to use a file based protocol like NFS and Samba (which aren't even in the neighborhood of VirtFS) to copy LARGE GBs worth of data from our VMs to the Host (unRAID).

 

Xen and ESXi does not have anything like VirtFS because they are more Business / Enterprise focused. A typical Xen / ESXi server / VMs are using 10GB /100GB+ speeds on their network and using block level protocols like iSCSI, FCoE, AoW, etc. to take advantage of those network speeds.

 

This is the one thing keeping me from running VMs right now. I did not spend $300 on a cache SSD drive to be slowed waaaay down by NFS!

[limetech]

2. Video Card Passthrough is way better on KVM.

 

AMD RADEON 5xxx, 6xxx, 7xxx - Works

 

NVIDIA GEFORCE 7, 8, 4xx, 5xx, 6xx - Works <--- No Quattro Card required. Xen or ESXi cannot do this.

 

INTEL IGD - Sorta working but not there / stable yet.

 

3. KVM is more catered to home users and they are way ahead of Xen and ESXi when it comes to the things that we are going to want now and going forward.

 

Is this situation going to improve with 4.3.2 or 4.4?

[limetech]

1. VirtFS (9P with virtio)

ve at close to block level speeds. Much better than having to use a file based protocol like NFS and Samba (which aren't even in the neighborhood of VirtFS) to copy LARGE GBs worth of data from our VMs to the Host (unRAID).

 

Xen and ESXi does not have anything like VirtFS because they are more Business / Enterprise focused. A typical Xen / ESXi server / VMs are using 10GB /100GB+ speeds on their network and using block level protocols like iSCSI, FCoE, AoW, etc. to take advantage of those network speeds.

 

This is the one thing keeping me from running VMs right now. I did not spend $300 on a cache SSD drive to be slowed waaaay down by NFS!

 

It's hard for me to believe that any network protocol running between unRaid storage and a domU via a virtual network connection is going to be slower than the speed of a single disk, even an SSD.  If you have a raid5 setup with a large stripe size, then sure, but that's not unRaid.

[limetech]

What are you on about? I honestly don't understand what you just wrote.

 

I wouldn't worry about. I don't think you and I share the same sense of humor.

 

1. If you haven't already take a look at the following: http://lime-technology.com/forum/index.php?topic=31653.msg288903#msg288903

Yes saw that and already put in almost all of it in -beta4.

 

2. I think it is probably best that you have 3 separate releases Vanilla, Xen and KVM (if you decide to pursue it).

 

The idea of a loop back file system on the flash is not new.  Hell unRaid v. 1 had that originally.  The are reasons other than what you have thought up for why it would be nice to have it, and there are reasons not to include it.  Actually I'll let you in on one of the reasons: I want to eventually get away from requirement of USB flash entirely.  We already get daily requests from past customers to transfer their key to a new flash because the old one has "worn out".  Changing the product design so that the flash gets even more I/O to it is going in the wrong direction.

[SchoolBusDriver]

Is this situation going to improve with 4.3.2 or 4.4?

 

I haven't tried it yet in 4.3.2 or 4.4.

 

If VirtFS isn't going to make a difference and there is only a small number of users who care about XBMC VMs with PCI Passthrough... AMD works and a video card that can do 1080p with HD Audio is only $15 or so. I wouldn't jump through hoops for KVM if it isn't worth it.

 

[SchoolBusDriver]

Actually I'll let you in on one of the reasons: I want to eventually get away from requirement of USB flash entirely.  We already get daily requests from past customers to transfer their key to a new flash because the old one has "worn out".  Changing the product design so that the flash gets even more I/O to it is going in the wrong direction.

 

You know and have far more experience than I do regarding this.

[bmfrosty]

I haven't constructed enough argument to argue for OpenVZ as well, I just think it's sexy as hell.  chroot on f'n steroids.  Only issue I have is that a kernel panic in one VM is a kernel panic in all VMs, and the root OS.

[heffe2001]

I can't believe I've gotten to sift through 2 pages of debate on nano in the announcement forums. Off topic much?

 

Me either, wtf?  IronicBadger already requested nano days ago and it's already in -beta4, I guess it was a PM where I told him that because obviously no one else got the message.  You want to use nano, go ahead.  You want to use vi, go ahead.  Can we stop talking about editors now???

 

Yes hoping to have a rudimentary webGui VM manager posted to github and included in -beta4 release.

 

Is it planned that the location of the VM files will be changable in the webgui?  I'd rather put my VM's on a seperate SSD and not my cache drive if I can (I know I can just symlink, but having that configurable in the GUI would be nice).

 

Also (this is something I've been meaning to ask for a while), would it be possible to have a configuration option to 'hide' a drive from unraids array setup?  For instance, take that SSD I mentioned above, select it in say settings/disk settings, and it NOT show up in any of the dropdowns for array configuration?  That way I don't inadvertently add it into the array and wipe it out?  (I've about done this back when I was running a single drive for extraction/DTS rencoding that wasn't in the pool). 

 

[Niccarter]

SchoolBusDriver - in http://lime-technology.com/forum/index.php?topic=31653.msg288903#msg288903 you recommend (amongst other things):

allocate a CPU to dom0

don't allocate fixed amount of memory to dom0

 

Just came across this: http://wiki.xen.org/wiki/Xen_Best_Practices which agrees with your first recommendation, but has the opposite view on memory - ie DO allocate fixed amount of memory.

 

Cheers

Nic