unRAID Server Release 6.0-beta2-x86_64 Available

[ironicbadger]

I recall that 6.0 was supposed to be for a lack of better words the 64 bit counter part of 5.0 to help us with memory management. I do understand some variation, but this seems that it has forked completely off that premise, no? Looking more like a 6.1beta.

 

I think this is all cool, but we lost the 64 bit counterpart, Tom will be so busy with all these virtual layers and new samba, etc. I am sure many would have appreciated the 64 bit counter part to 5.0 first, fix and learn from it as the first pass and pick these additions back up in a 6.1 beta.

 

Dude what are you talking about?

 

I haven't seen any show stopper 6.0 bugs yet. Myself and others are dying for unraid to be the VM host and WE think it's great Tom is dancing down this particular road.

 

I don't get your point at all though.

 

Sent from my Nexus 5 using Tapatalk

 

 

[Dephcon]

Adding virtualization support to unraid makes it a MUCH better product.  Soon plugins will be can limited to unraid specific functions and we can run any obscure linux or windows app on the unraid box without waiting for someone to write a plugin for it.

 

This is where we should be going and merely making a 64bit version of 5.0 is a waste of time and testing.

[jumperalex]

Well if I had to take a guess, I think his point is that the original roadmap indicated 6.0 was supposed to be 5.x+64bit and nothing else major added.  That means no virtualization, added/upgraded packages (beyond that needed to work with 64-bit).  The the result would be a much faster 6.0-final release.  Thennnnn by 6.1 beta would include Samba4, virtualization, etc etc etc.

 

So this would appear to be a different path than the "original" roadmap.  Mind you , I don't have any complaints about Tom's current development path.  I'm eagerly awaiting virtualizaion and am glad to see it is being developed right out of the gate.

 

I'm just saying I think that is madburg's point.

[PeterB]

Adding virtualization support to unraid makes it a MUCH better product.

 

I don't hear many people denying that.  I am certainly excited to be able to use unRAID as host for VMs supporting auxiliary functions.

 

Soon plugins will be can limited to unraid specific functions and we can run any obscure linux or windows app on the unraid box without waiting for someone to write a plugin for it.

 

Exactly - the first one I hope to be able to run is jdownloader, which I have abandoned for the time being, because it seems to need a front end and I don't want to leave my desktop machine running 24/7.  Interaction with a UPS is one thing which I strongly believe should be handled by the host (unRAID-specific), which is why my very first effort was to convert the apcupsd plugin to 64-bit/Slack 14.1.

 

This is where we should be going and merely making a 64bit version of 5.0 is a waste of time and testing.

 

I'm not sure that I agree with that.  I think that a pure replica of 32-bit v5.x, built to run in 64-bit mode would be a very good stepping stone.  What is the point of adding new functions if the old ones are flakey?  I'm a little concerned that it appears that effort is being put into virtualisation support while there are reported problems with nfs.  Virtualisation is the cream - nfs is core functionality for a nas/server.

 

My plans for upgrade from 5 to 6 are definitely to implement all of my essential functionality - handling my email (dovecot/mpop), supporting my OpenELEC boxes (dnsmasq, SQL) and downloads (couchpotato/transmission), my photoframe (minidlna) and my Squeezeboxes (LogitechMediaServer) - using plugins, exactly as they are now.  I have converted, but not tested, all of these except couchpotato/transmission, since I read that someone else has already tackled those, and MySQL (wanting to create a MariaDB plugin).

 

I will probably then play with virtualisation as a means of adding new functionality (jdownloader?)  After that, with the knowledge gained, I will start to offload existing plugin functionality to VMs.

 

So, I would say that getting V5 functionaliy solid in V6 should be an absolute priority.  After all the criticism levelled at Tom about 'feature creep' during the v5 development cycle, you now seem to be advocating this for the v6 development.

[syntaxx]

This is good news. Though I think I like a linux with package management and run unraid on a vm. like the opensuse thread you can use the host as xbmc as well then passthrough your video card on a vm that will make another pc for you less power consuption and device. Again this is just me pleae don't hate me.. keep it up Tom!

[vl1969]

Adding virtualization support to unraid makes it a MUCH better product.

 

I don't hear many people denying that.  I am certainly excited to be able to use unRAID as host for VMs supporting auxiliary functions.

 

Soon plugins will be can limited to unraid specific functions and we can run any obscure linux or windows app on the unraid box without waiting for someone to write a plugin for it.

 

Exactly - the first one I hope to be able to run is jdownloader, which I have abandoned for the time being, because it seems to need a front end and I don't want to leave my desktop machine running 24/7.  Interaction with a UPS is one thing which I strongly believe should be handled by the host (unRAID-specific), which is why my very first effort was to convert the apcupsd plugin to 64-bit/Slack 14.1.

 

This is where we should be going and merely making a 64bit version of 5.0 is a waste of time and testing.

 

I'm not sure that I agree with that.  I think that a pure replica of 32-bit v5.x, built to run in 64-bit mode would be a very good stepping stone.  What is the point of adding new functions if the old ones are flakey?  I'm a little concerned that it appears that effort is being put into virtualisation support while there are reported problems with nfs.  Virtualisation is the cream - nfs is core functionality for a nas/server.

 

My plans for upgrade from 5 to 6 are definitely to implement all of my essential functionality - handling my email (dovecot/mpop), supporting my OpenELEC boxes (dnsmasq, SQL) and downloads (couchpotato/transmission), my photoframe (minidlna) and my Squeezeboxes (LogitechMediaServer) - using plugins, exactly as they are now.  I have converted, but not tested, all of these except couchpotato/transmission, since I read that someone else has already tackled those, and MySQL (wanting to create a MariaDB plugin).

 

I will probably then play with virtualisation as a means of adding new functionality (jdownloader?)  After that, with the knowledge gained, I will start to offload existing plugin functionality to VMs.

 

So, I would say that getting V5 functionaliy solid in V6 should be an absolute priority.  After all the criticism levelled at Tom about 'feature creep' during the v5 development cycle, you now seem to be advocating this for the v6 development.

 

I think you are missing the whole point of the V6 64bit project.

a lot of issues with functionality in v5 is that it is build on old kernel that simply does not have the advantages that have been made in the last few years. all the fixes and changes that exist today in the new kernel are not there.

also lots of people need/want things running on unraid that at this moment only available as a custom plugins  where if unraid was runnig a current updated kernel could simply be added using what I would call a stock applications. in addition  virtualization functionality  added to V6 is needed to simplify runing other apps on unraid instead of plugins it might even help solving some of the functionality issues we have now as we can unload this to a VM instead of doing in with unraid core.

your nfs issue as an example may be solved if we could just run the VM on unraid host and run all the nfs share from there using unraid array drives as source.

[PeterB]

I think you are missing the whole point of the V6 64bit project.

 

Really?  I thought that (one of) the initial goals of the 64-bit project was to allow more effective use of larger memory - especially after the widely reported problems of X9-SCM boards sporting more than 4GB.

 

a lot of issues with functionality in v5 is that it is build on old kernel that simply does not have the advantages that have been made in the last few years. all the fixes and changes that exist today in the new kernel are not there.

 

Sorry - I didn't make it clear that I consider moving to current kernel/build is an inherent part of the 64-bit project.  I was talking about added functionality - I don't have a problem with updating the underlying foundations.

 

also lots of people need/want things running on unraid that at this moment only available as a custom plugins  where if unraid was runnig a current updated kernel could simply be added using what I would call a stock applications. in addition  virtualization functionality  added to V6 is needed to simplify runing other apps on unraid instead of plugins it might even help solving some of the functionality issues we have now as we can unload this to a VM instead of doing in with unraid core.

 

I'm not arguing with any of that - I'm just saying that a first step along that road would be to re-implement what we currently have, in a 64-bit and updated environment.  Ensure that the cake is stable before adding the icing!

 

your nfs issue as an example may be solved if we could just run the VM on unraid host and run all the nfs share from there using unraid array drives as source.

 

Is that really a sane way to tackle the issue?

[vl1969]

PeterB, I never said it was a sane way to tackle the issue.

just a way.

 

also I am not 100% sure but maybe moving to an updated kernel would solve some of the issues by itself. maybe the issues that exist in V5 are there because it is based on an some what outdated kernel and libraries. we will see what happens soon enough.

64 bit support have been asked for for ages

and enabling VM stuff is just a bonus. KVM is part of the kernel so it was there to begin with just begging to be switched on, Xen stuff have been added to many latest kernels so I do not see a big issue in enabling that capability either.

 

 

[bmfrosty]

I'm extremely happy that Tom is working on all of this.  Bumping up to 64 bit means that a lot of existing plugins are going to stop working, but by working on VM support while this is in beta and some of the core functionality issues get shaken out like NFS/SMB/AFP speeds, he'll manage to provide a much more elegant way for us to deal with extended functionality that would normally muddle up what should be a very clean core system.

 

I for one know that the first thing I'm going to do when I upgrade to 6.0, the first thing that I'll do is spin up a minimal Fedora or Debian VM to host things like Transmission and Sabnzbd, and those things will be off in their own little walled garden that won't have much impact on system functionality for this system as a NAS.  I'm even really damn happy about NFS being in the middle to mangle all my file permissions to nobody:users.

 

Thank you Tom for all your hard work!

[ironicbadger]

..., he'll manage to provide a much more elegant way for us to deal with extended functionality that would normally muddle up what should be a very clean core system.

 

This.

 

Sent from my Nexus 5 using Tapatalk

 

 

[Dephcon]

I just think that adding virtualization support to 6.0 will add a lot more beta testers as not many people are having issues with 5.0.  I'm still on the initial release because it's been working great so far and wouldn't bother participating in 6.0 testing for just x64 support.

 

You need a pimp feature to tickle the balls of the testers. 

 

This way everyone one wins, the users with issues and the testers that demand new cool shit.

[bkastner]

I agree that the proper approach likely should have been to migrate 5.0 to 64-bit and stabilize before layering virtualization on top of it - this would have helped ensure a solid 64-bit foundation to start adding features onto whereas now there are a lot more moving parts which could cause issues, which may cause delay on 6.0-final.

 

However given the general up swell of virtualization interest over the last couple of months and the potential of people taking UnRAID off on their own directly, I can appreciate Tom needing to take this step to maintain control of his business.

 

I am guessing UnRAID is likely not following development best practices, but he is trying to do what is best for his company, which at this point does include catering to the higher-end users who have the potential to fragment his business or jump ship entirely. The wealth of knowledge available in these forums is impressive and it would be a huge loss to the community (and UnRAID) if they were to jump ship as they are helping drive UnRAID to the next level.

 

Sometimes it's a matter of doing what is best from a big picture perspective vs. what is right from a purely technical perspective.

 

[NAS]

Please remember this thread is for people to follow 6.0-beta2-x86_64 announcements and nothing else.

 

Time to fork this discussion so it can have it own dedicated thread and people looking for news dont need to read 75% unrelated posts

[RobJ]

I've updated the following wiki page with the current state of UnRAID 64 bit development, as far as I have been able to research it:

 

  64 bit Compatibility

 

PLEASE feel free to update it, expand it, add new sections to it, fix wrong information, add missing items and information, etc.  If you don't feel able to edit the wiki page yourself (it's easy!), notify someone else about it (but not here in the announcement thread).

 

Developers:  please consider adding appropriate 64 bit comments and links to your primary plugin posts (the Original Post), as a number of them do not mention the 64 bit version yet, even though it is available.

 

All users:  please report success and failure in the appropriate threads, so the rest of us can know what works and what doesn't.

[nicinabox]

I've updated the following wiki page with the current state of UnRAID 64 bit development, as far as I have been able to research it:

 

  64 bit Compatibility

 

PLEASE feel free to update it, expand it, add new sections to it, fix wrong information, add missing items and information, etc.  If you don't feel able to edit the wiki page yourself (it's easy!), notify someone else about it (but not here in the announcement thread).

 

Developers:  please consider adding appropriate 64 bit comments and links to your primary plugin posts (the Original Post), as a number of them do not mention the 64 bit version yet, even though it is available.

 

All users:  please report success and failure in the appropriate threads, so the rest of us can know what works and what doesn't.

 

Thanks for the reminder. I updated my bits of the wiki.

[madburg]

I appreciate the replies, good, bad, an the dude as well.

 

The post was not to take the thread of coarse just some clarification.

 

To touch on some points, Tom created and expressed the roadmap. Reading the two beta threads took me by surprise with the roadmap for 6.0

 

What I dont understand with some of the points made,  is many people have taken a hyper visor like VMware (free) virtualized unRAID and passed-througth the disk controllers and off loaded varies functions. So while some may want unRaid to be the hypervisor, I ask this if in this case unRaid for myself and others is already virtualized and now 6.0 boots to dom0 it really is now just another layer between the controllers and unRAID? Does that even work, and if it does and there is a performance hit and/or bugs, that's ok for all those people?

 

Where if this would be the case at least we would not be stuck with a 32bit unRAID with this setup. We would have a 64 bit 6.0 and 6.1 would be for others.

 

Secondly even with off loading various functions to our VMs today we still have memory management issues, thus why we were happy to hear that a 64 bit counter part was in the roadmap.

 

How about the people who really wanted cache pool? It's not cool to roadmap and then jump ship on it. As I expressed its not that all this new new stuff is not cool, it's a bit unfair not to offer a 64 bit counter part to 5.0 to basic users and who would benefit from a 32 bit to 64 bit swap.

Tom takes pride when non-techie setup unRAID and love the easy. This is way past that. I respectfully request some consideration from Tom on this. Moved this as 6.1 and work 5.x, 6.x and 6.1 at the same time if need be, since this work started.

 

Sorry in advance for typos, on a mobile phone typing this up.

[BLKMGK]

The 64bit code proposed is just a normal Linux 64bit kernel with some switches thrown to turn on KVM and Xen! The dom0 is confusing you but it's really not different, it's what the host OS is called. UnRAID won't be in its own VM, this is a bare metal hypervisor that's being discussed. UnRAID will have real access to the hardware, all of the other VMs will be virtualized and the unRAID environment rules them so to speak. If you don't use the virtualization stuff I don't think you'll see any difference from unRAID today other than 64bit and newer kernel\packages.

 

I can't speak to cache pools. Do note though that this is still very early beta releases and that much is still being sorted out. Be patient, I think the hypervisor stuff is simply getting many of us excited because of the possibilities....

 

 

Sent from my iPad using Tapatalk

[limetech]

-beta3 status: got network bridge working (including bridge of bonded ethernet ports).  Got ubuntu running in a VM with access via console and vnc.  A few more issues to address and then I'll release it.

 

Some have expressed concerns over the 'road map'.  bkastner got it exactly right.  Yes I took a bit of a "detour" off the map to get Xen working, but I think it will be well worth it.  Why Xen vs KVM?  Flipped a coin and it came up Xen 

 

Turns out getting Xen + unRaid as dom0 wasn't too bad.  The way it works is you will have a choice at the 'boot' menu about what you want to load.  See attached image.  You can load unRaid in the traditional manner, in which case everything runs exactly the same.  Alternately you can boot Xen first, which will load same unRaid kernel and image as "dom0".  I don't believe there is any speed degradation running as dom0, but I haven't run extensive tests yet.

 

No doubt there will be more issues to work out with Xen+unRaid and there is still a lot of work to do to make it "user friendly".  For example, starting VM's is really not difficult and would be straight-forward to code into a webGui plugin.

 

Once this is released and it's mostly working, I will concentrate on finishing other features, chief of which is "cache pool".  I think this feature will be very handy for VM's as well.

 

 

[BLKMGK]

Safe Mode? Now that's an awesome idea!

 

 

Sent from my iPad using Tapatalk

[jumperalex]

Well Safe mode isn't new, but you're right it is a great idea.

 

But having the option to boot unraid or xen/unraid is brilliant.

 

Exciting Times!  Thanks Tom.

[BLKMGK]

Pretty sure my 5.04 isn't offering me that but I've not recreated my stick in something like 4 years I'd guess lol so that might account for it.

 

My biggest concern, other than management, is speed for the VM HDD. Where will be looking to host these, a separate cache type drive or on unRAID proper where it will have some data protection? unRAID, to this point, hasn't exactly been a speed demon for IO so I'll be interested to see how this shakes out :-)

 

Tom were you able to solve the permission issue with SMB files and Samba4 yet?

 

 

Sent from my iPad using Tapatalk

[soana]

In case of a reboot what will be the default option unRaid OS or Xen unRaid Os or maybe the last option used before reboot?

[BLKMGK]

 

In case of a reboot what will be the default option unRaid OS or Xen unRaid Os or maybe the last option used before reboot?

 

I foresee a plugin for setting default boot in the future! ;-)

 

 

Sent from my iPad using Tapatalk

[PeterB]

-beta3 status: got network bridge working (including bridge of bonded ethernet ports).  Got ubuntu running in a VM with access via console and vnc.  A few more issues to address and then I'll release it.

 

Thanks for the update Tom!

 

I know that VM is in high demand, and it's exciting to be working on something new - I'm sure that I'll be exploring the world of virtualisation very soon - but I don't want to disrupt the whole family by moving to 6 while there are unaddressed issues with nfs.  Please don't postpone addressing issues with the core functionality for too long!

[bmfrosty]

I'm very under the impression that the practical difference for the two is whether or not the Xen functionality is available.  Can someone in the know a little bit more say if it's further off - if the Xen kernel would have any disadvantages to someone who isn't going to run VM's on their system?