SchoolBusDriver

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.

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.

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.

Since we are all having a robust / fiery debate about nano... Let's talk about something more serious. As it stands right now, unRAID 6.0 beta2 to beta3 went from 256MB of total ram to over 512MB. 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. An few suggestions to fix several things at once... 1. Quit trying to put EVERYTHING under the sun in a bzoot. 2. Create dual partitions on a USB Flash drive via an ISO. 3. Partition 1 - VFAT - All the stuff that Tom / Users needs to access / configure / etc. in unRAID via Windows and Mac. (NFS Shares, Password, Shadow, Disk Settings, Key file, etc.) 4. Partition 2 - EXT4 (noatime and no journaling) and put the rest of Slackware on there. 5. Tom would put A LOT of Slackware stuff that is static in the bzimage but put things like /lib64, /usr, /bin, /sbin, etc. on the EXT4 Partition. Together both would appear / be one normal looking root file system. 6. We could keep the RAM used by Slackware to a minimum like it is now. You would not have the program and the amount of space it takes up on a Flash Drive getting loaded into memory. 7. People would only have to load something ONCE. For example, we settle on perl version X and python verion Y and zlib version Z and put those in the second EXT4 partition. 8. This would solve 80% of the BS that plugins developers / users have to deal with like downloading and installing 6 different versions / kinds of perl or python, zlib, etc. from who knows where. 9. Since there isn't that many Plugins, edit the plugins to load only the program itself at each boot and not all the various core Linux apps / libraries that each Plugin Developer decides. 10. It makes adding something like KVM less painful and it doesn't take up our RAM do to only having a root ram file system. 11. It's writecycles that "wear out" a flash drive... not reads. A $5 POS USB Flashdrive has 100,000 writecycles and how many times do you think someone is going to be installing NEW packages in Slackware after they loaded them once?!?!?!?! 12. Tom could keep an "image" of the default EXT4 Partition on VFAT4 partition where a user could run a batch file or click an option in the WebGUI that overwrites it and makes it default / vanilla again if something went wrong. The config / settings / etc. would remain untouched on the VFAT Partition. 13. How many people have 256MB unRAID Flash Drives? I personally buy any of these users a $5 4GB (or more) if this is would be the hang up to the above.

Nah... Where is the fun in that? We need to man up and make a decisive decision about this very important issue. LOL!

Would you like Tom to include nano (text editor that is 534kb) in unRAID?

It's not? If a user wants to preclear drives, install unmenu, add their TV Tuner Card, use VMs... They don't have choice but to use CLI. Unless someone hid plugins for the above that will further blow up my semi-working plugins / crash my server. Uhhhhh... If there is a passionate and robust debate on whether a default 534kb text editor should be added to unRAID or not... Your Full Linux Distro in openSUSE dreams don't have a snowballs chance in hell of ever becoming reality. Imagine how many people would be banned and the number of threads that would be closed / deleted over which checkbox is selected for the Linux Desktop. It would be Biblical! Even though you could choose / select another Desktop or none... The fact that I suggest KDE or Enlightenment or XFCE be the default checked or someone else suggests Gnome or Cinnamon be the default checked... would literally cause some people on here to run into the streets screaming naked or perhaps even commit suicide.

Wait... What?!?!?! There is a preclear plugin? A preclear plugin that also installs screen so I can preclear 2 or 3 drives at once? There is a plugin that will custom compile a Kernel and add my TV Card? There is a plugin that runs Resier fstack tools? There is a plugin that installs unmenu? Someone please post a links to all these plugins (hope to God they work and don't crash my Server like the rest of the plugins do) so I can avoid going to command line from now on. I need nano, the people who will use my guides / VM Appliances will need nano. If I have I to post a bzroot along with my Guides / VM Appliances... so be it. In the meantime, will you or someone else write a WebGUI / plugin (that always works and doesn't crash my Server) for Xen / KVM, preclear, fstck, nano, unmenu, screen, Pxe Server, etc? Since plugins works so well and people are literately begging / pleading / offering money for someone to fix / create / modify existing ones... How much of a reward are you personally going to put up for someone to write a nano plugin? Make it $100 at least so I have it today. That way, I don't have to upload my own bzroot along with my XBMC Appliance. Three of my family members who have an unRAID Server... Do not know Linux and do not want use the command line. 1. They are FORCED too if they want to preclear drives, install unmenu, run fstack tools and a bunch of other stuff. 2. They spend God knows how much time trying in command line to figure out / fix the screwed up plugin system (that everyone here and their brother knows doesn't work and will probably crash your Server). 3. Yet here you are pushing a flawed / unreliable / broken pile of shit plugin system. 4. Who is going to write this nano plugin?!?!?! We ran off the plugin developers and only a few people are bothering patching / updating plugins. A new one hasn't been written in how long? A year? 5. 534kb of space that almost every Linux Distro has and 90% or more of any guide / documentation / Wiki you see on the web uses nano. What is your solution? Halt unRAID 6.0? Rip Xen out of it until a Plugin / WebGUI exists? Good luck with that... I do not see either one of those things happening. Look how much money Tom has made with just the users who posted in $30 Limited Time Offer Thread and took advantage of it. Are you personally going to refund all those users (and the ones we don't know about) who purchased unRAID at that special price their money? I bet that cost you several thousand dollars. Is preventing Tom installing an App that 95% of us want and 534kb of space really worth that much trouble / cost?

[glow=red,2,300]Certified Studs like me use nano (Chicks dig us and nano too).[/glow] If we really want to go all out and make unRAID dork / geek friendly... Let's switch over to Gentoo, forget plugins and compile our packages from source. With every unRAID "Gentoo Edition" purchase... Tom will include: 1. A pocket protector. 2. Dorky classes with tape in the middle. 3. Short sleeve button up shirt that is too tight and a ugly clip on tie that is too short. 4. A subscription to your "adult site" of choice because it's probably a save bet that you haven't seen someone from the opposite sex naked in real life and probably never will. 5. Think of all the fun we will have showing off our make.conf and our custom CFLAGS & CXXFLAGS for how we compile everything. This is Geek / Dork Porn at it's finest.

What is your recommendation? We could install a Linux Desktop and use the libvirt GUI. We could get some users focused on writing a WebGUI or plugin. I am not a programmer or else I would lead this effort. Are you one? If so, would you be willing to give up some of your free time to help? That might be how you roll but almost ANY guide that a user is going to see on the web for Ubuntu, Arch, CentOS, Fedora, Linux Mint, Debian, OpenSUSE, etc. where the users are asked to edit / make changes to something... 95% of them use nano as the editor of choice. nano is also installed by default in almost every Linux Distro I have ever tried in the last 5+ years so I think it's safe to consider it well tested and proven to be reliable. Since a nano plugin with a guide on how to install it doesn't exist... No worries. In the VM Appliances I post here, I will just include a bzroot with nano installed (plus the other changes I suggested earlier). This will make it easier for the users and people like me who have to write guides / support users where editing of files is going to happen (until a WebGUI or plugin is written).

With all the guides that need to be written around Xen / KVM, all manual editing of cfg files for VMs that needs to be done by users (many novices) and due to the 10 or so people who have already had issues with DOS characters in their cfg files... It makes life more difficult on people who write guides, the users with little to no Linux experience and those of us supporting the novices. I am posting a XBMC VM Appliance later today and I will just include a bzroot with nano in it (and the changes listed a few posts up). That way users can follow my guide (which has some nano commands in it) and I don't have to wait for someone to write a plugin to install nano, explain to people how to get the plugin, install it, etc. or explain vim or mcedit.

I might have missed it but I hope that is sarcasm.

Tom, A few recommendations... 1. Do not assign a set amount of memory to Dom0 and make syslinux.cfg look like this: label Xen 4.3.1 / unRAID OS kernel /syslinux/mboot.c32 append /xen dom0_max_vcpus=1 dom0_vcpus_pin --- /bzimage --- /bzroot label Xen 4.3.1 / unRAID OS Safe Mode (no plugins) kernel /syslinux/mboot.c32 append /xen --- /bzimage --- /bzroot unraidsafemode Since a lot of people use a Cache Directories (a memory hog), let Dom0 get assigned all the memory. That way if memory runs low, the VM has the issues / crash (as a previous use a few posts up experienced) and not unRAID. Even with all the memory assigned to Dom0 (unRAID), the VMs can still use / grab it but unRAID has the priority and will take back what it needs. Note - By default, this how most Linux Distros handle it. 2. You will probably want to dedicate at least one CPU to Dom0 by default. label Xen 4.3.1 / unRAID OS kernel /syslinux/mboot.c32 append /xen dom0_max_vcpus=1 dom0_vcpus_pin --- /bzimage --- /bzroot label Xen 4.3.1 / unRAID OS Safe Mode (no plugins) kernel /syslinux/mboot.c32 append /xen --- /bzimage --- /bzroot unraidsafemode a) Dedicating a CPU core only for dom0 makes sure dom0 always has free CPU time to process the IO requests for the domUs. b) When dom0 has a dedicated core there are less CPU context switches to do, giving better performance. c) Assigning more than one isn't going to make Dom0, write files faster to unRAID or make the VMs run any faster. 3. Cosmetics - I would put the version number of Xen in syslinux. As you know unRAID 4.3.2 and 4.4 are both due out this month around the same time. Depending on where we are at in the beta process and if / when you are comfortable updating to either 4.3.2 or 4.4 it will make supporting the users easier if they (and those of us supporting them) see / know which version of Xen they are running (assuming you eventually update to 4.3.2 or 4.4 through the beta process). 4. Make the following changes in /etc/default/xendomains: XENDOMAINS_SAVE= XENDOMAINS_RESTORE=false XENDOMAINS_AUTO=/etc/xen/auto <--- Symbolic link or point this to a directory you create on the unRAID Flash Drive. If we Symbolic link or copy our VM cfg files into the XENDOMAINS_AUTO folder the VMs will autostart on boot (there is an automatic delay from each VM starting so they do not start all at once).

Memory Ballooning is not turned on. Since you have tons of memory throw more at Dom0 cause with cache directiores it needs it.

I would turn off cache directories for starters and element that from the equation. Also, what where you or the apps doing in your Windows VM? Do you have the GPLPV drivers loaded?

Question for everyone... How many MB / GBs is your XBMC folder (including sub-directories)? I am curious how many plugins, skins, thumbnails, artwork, etc. people are using and what the total size of other people's XBMC folder is.

Thanks... I didn't think of that. I know Ironic saw the post and I don't want to step on his toes at this point. I'm sure he will want to double check / test some of things I mentioned above. If need be, move them over to that thread.

All the big things that Arch needed to switch too they have done... netctl instead of netcfg, systemd instead of sysintv, etc. As of now... Arch doesn't have any major changes in the core apps / Linux Kernel aside from doing things with Pacman (Package Manager) but even those are more around package building and the common user wouldn't know / notice anyway. If Ironic really wants to maintain a VM Appliance for unRAID long term... I would move all the Packages from Arch to his repo, remove all the Arch repos from the VM and point them only to his. I would then lag behind Arch 3 - 6 months. That way he can manage and plan well in advance for any changes / test / let Arch deal with bugs. For example, the libnfs and grub issues would be prevented. For the users who wanted to stay more current, they could enable a "testing" repo he sets up that are the packages that get rolled out in the 3+ month release. That would be how I would do it if I was going to roll out a VM Appliance. Even though this might offend some, if I was him I would also charge for my VM Appliance too once all the bugs get worked out. Slacklet provides a vanilla Linux OS and charges $10 where as Ironic does 1,000 more things and has a cost associated with hosting it.

I have a long bus, short bus and a Audi S5. I usually am in the Short Bus due some of the "special" kids on here who need to be taken to school. Hopefully with the new forum rules Tom instituted, I can drive the Long Bus more or maybe even the Audi.

I'm looking for Sponsors. I have plenty of room for some Lime Technologies Stickers if Tom is interested.

Arch is good a choice because many of the Applications we use are "cutting edge". Depends what you plan on running in your VM. If you choose CentOS and want XBMC, Sickbeard, Couchpotato, Owncloud, etc. and any number of the Apps that people here typically use... Good luck finding a guide / package to install it. XBMC is version 11 and you will be compiling all those apps and have to manually update them. Now if you are going to put up a WebServer / Blog / Forum / etc. and expose it to the internet... I think something like CentOS (that you secure / harden) is a great choice. Once you have a VM Appliance you pretty much just go to the various WebGUIs to access the apps. You don't really need to fool with the OS much. Also, there will be tons of stuff on here around Arch and their Wikis are probably the best out there beside maybe Gentoo. Go look to how to install Sickbeard or turn on NFS in Ubuntu... You are going to get 100+ different answers and 50 of them are going to be incorrect or for the wrong version of Ubuntu. Another thing about Arch... Once you know it, you know CentOS, Fedora, Red Hat, openSUSE, etc. because they are "true" to Linux and all work / use the same programs (aside from a package manager). Where as Ubuntu is what I consider a "fork" of Linux and custom in many ways. The beauty of Arch is that it's a rolling release and their are no versions / releases. To update the system, the user has to type "pacman -Syyu" and it will update Arch / Apps. When you say long term support you have to explain. Arch isn't a flash in the pan Linux Distro that is going away. It's just as stable as any other Distro if Ironic sets it up / maintains it that way. You mentioned CentOS but with the partnership with Red Hat, it is now going to be a "development / testing" Distro for Red Hat so I would start to consider it as stable as you would Fedora (Red Hat's other development / testing Distro). Think of it this way... Fast forward 2+ years and Ironic choose to use Ubuntu. In that time, there will be 4 releases of Ubuntu. Can you imagine having to update, maintain and upgrade all the packages for 5 separate versions of Ubuntu? He would because there are plenty of users here still running unRAID 4.7 and betas / release candidates for 5.0 and they probably won't update / upgrade Ubuntu 13.10 till Ubuntu 23.10 is out. Not to mention in one of those releases Ubuntu is going to switch to systemd. That in of itself is a MAJOR change and pretty much every thing you have every read / seen on the internet about installing apps in Ubuntu does not work anymore.

I will save you all a bunch of time / trouble. 1. You can use VHD, QCOW2, thin-provisioning, CoW, etc. 2. You need qemu installed to create qcow2. 3. There are other tools for VHDs. 4. You need to boot them with pvgrub. 5. You are going to need multipath and other packages if you ever want to mount / access the partitions within the VM. 6. Yes, you can convert images from VHD, QCOW2, VMDK to RAW format but it isn't the greatest tool. There are other opensource ones that a much better. Also, you will be running your VMs in HVM and not PV. Which means unRAID (Host) has to work a lot harder and your VMs are slower. 7. It's best that you create a fresh VM from scratch with the Xen PV drivers installed (like ironics). It's very easy to install a Linux VM with Xen Drivers in a VM... Do not bother creating images in VMWare and then use QEMU tools that are designed for KVM to convert them over. 8. Leave the VM Appliance images small. Let the users create their own "data drive" image for the size they want and need. You can mount more than one "drive" in your VM using the VM cfg file. Mount the "data" drive (image file you create) as "xvdb" and leave the VM Appliance as "xvba". Your "data" drive is where you have all your stuff download / store before your Apps or a chron job move it to unRAID for you. Instead of people arguing or only being able to have VM Appliance X size, let you users decide for themselves. 9. Jumping through hoops for QCOW2, VHD, etc. isn't worth the trouble and using step 8 above you avoid the necessity of having to create thin provisioned images that are designed for KVM. Xen DOES NOT recommend you use them in a production environment. 10. Why go spend $100+ on an even bigger cache drives to store your downloads that you are going to copy over to your unRAID? Why not just download them to your unRAID instead? Do you value this data? a) Having your drive(s) on your unRAID server spin down does not increase how long they will last. b) The amount of money you spend on a new cache drive is probably 4X the cost of what you would spend for electricity for a year. c) When your files are done downloading, renamed, copied where they should be... The unRAID drive(s) will spin down. 11. Instead of using file based protocols like NFS or Samba... It's time to look at block-based protocols too.

Thanks for the nice words and you are correct, documentation is the worst part of it.

XBMCbuntu works. Although I am not a fan of it. Too much bloat and no PV Drivers. OpenELEC is it's own Linux Distro. Due to how they compile the Linux Kernel and not having some packages installed... It doesn't have the ability to work in a VM on KVM, Xen or ESXi. Ironic ran into the same problem today. It's an issue with the latest ISO. Many users who were trying to use it (outside of a VM) are having the same problem. Ironic figured out the solution, use an older version and follow my post here (which johnodon told me about): http://lime-technology.com/forum/index.php?topic=31570.msg286363#msg286363 When I get some time, I will post a XBMC VM Appliance that boots into XBMC Frodo 12.3 (similar to openELEC) and it will also have HD Audio too should you need it.

1. I am a fan of both AMD and Intel. 2. My AMD is $100 dollars cheaper plus I get 8 cores. 3. Been converting a lot of my files from x.264 to x.265 and the extra cores are nice to have. 4. x.265 with the same quality as x.264 is about 60% smaller. With better quality about 40 - 50% (depends on the source). 5. Without Hardware Video Acceleration still only running 20 - 30% on my CPU.