August 20, 201015 yr I thought that while the right stuff was there to RUN vmware, the right stuff to INSTALL it was not! Am I missing something? That's what I thought as well... Anyway - if VirtualBox is easier I could go for that. Just the ability to install and run any virtual machine on top of stock unRAID without having to establish development environments for compiling and making sure the right kernel versions, exotic package updates and whatnot is in place just to get there would be REALLY nice I believe it is something that could be useful to many.
August 20, 201015 yr I thought that while the right stuff was there to RUN vmware, the right stuff to INSTALL it was not! Am I missing something? That's what I thought as well... Anyway - if VirtualBox is easier I could go for that. Just the ability to install and run any virtual machine on top of stock unRAID without having to establish development environments for compiling and making sure the right kernel versions, exotic package updates and whatnot is in place just to get there would be REALLY nice I believe it is something that could be useful to many. Me too, but VirtualBox is not available as a pre-compiled module against the unRAID kernel. So... it needs to be compiled. At the very least you need the compiler and the matching kernel headers and whatever support tools its configure script requires. You may not need a full development system, as unMENU already has packages that download "and install "gcc", "make," and then use them to compile ffmpeg with all its libraries to support AirVideo for the iPod/iPad folks. I think it would work with the correct/matching kernel header files. Joe L.
August 20, 201015 yr VBox always worked well for me with unRAID, bit I'm running on a full slackware distro. I hope to be able to move off of a full Slackware install after 5.0 has stabalized, and if so, I'll need to build an installable package for VBox.
August 20, 201015 yr Vbox has a strict license regarding package distribution on the closed version. The opensource is freely distributable, but you loose the USB and RDP support.
August 20, 201015 yr The VMWare installation hell is all the doing of VMWare and not the doing of unRAID. From what it seems, VMWare prevents the distribution of prepackaged installations and each installation requires it's own license, even though the software and license is free to obtain. It's not a matter of who's fault it is. It's a matter of it would be nice to be possible to install VMware on stock unRAID. So the request is can some headers or drivers or whatever be included in stock unRAID so that it could be installed?
August 21, 201015 yr That would unduely bloat the unRAID image for no benefit to the common usage pattern for well over 98% of the users. The power users, after all those are the only ones going to be running VMWare/VirtualBox, are quite capable of installing the additional needed packages. Now, if unRAID required the use of a 4GB flash drive or larger, then I'd have no issue with adding all the additional items and the kitchen sink required for everything. However it doesn't. It's meant to be a minimalistic approach. This is an issue of fundamental product philosophy. If you want the kernel source and headers have a look at http://kernel.org/.
August 21, 201015 yr That would unduely bloat the unRAID image for no benefit to the common usage pattern for well over 98% of the users. The power users, after all those are the only ones going to be running VMWare/VirtualBox, are quite capable of installing the additional needed packages. Now, if unRAID required the use of a 4GB flash drive or larger, then I'd have no issue with adding all the additional items and the kitchen sink required for everything. However it doesn't. It's meant to be a minimalistic approach. This is an issue of fundamental product philosophy. If you want the kernel source and headers have a look at http://kernel.org/. Some few power users are able to get VMware installed. Many of what I consider power users (just not with Linux) are not. Yes, I understand you don't consider that group important.
August 21, 201015 yr I do consider the group important. Here's some stats that I think you're missing. The unRAID distro is roughly 55 Meg (compressed bzroot). The kernel source is roughly 69 Meg (compressed .tar.bz2). The kernel source extracted is roughly 457 Megs (uncompressed /usr/src/linux/ tree). The kernel source once compiled is roughly 763 Megs (uncompressed /usr/src/linux tree after a make all). Remember, unRAID boots into a RAM-based filesystem. Everything included is placed there. If the source is included extracted in the unRAID image, you can no longer even boot on 512 Meg RAM machines. If the source and compilation artifacts are included in the unRAID image, you can no longer even boot on a 768 Meg RAM machines. The realistic minimum specification needed to run unRAID is now 1.5 - 2 Gig RAM. Now are you honestly able to come to a different conclusion after looking these numbers over?
August 21, 201015 yr I do consider the group important. Here's some stats that I think you're missing. The unRAID distro is roughly 55 Meg (compressed bzroot). The kernel source is roughly 69 Meg (compressed .tar.bz2). The kernel source extracted is roughly 457 Megs (uncompressed /usr/src/linux/ tree). The kernel source once compiled is roughly 763 Megs (uncompressed /usr/src/linux tree after a make all). Remember, unRAID boots into a RAM-based filesystem. Everything included is placed there. If the source is included extracted in the unRAID image, you can no longer even boot on 512 Meg RAM machines. If the source and compilation artifacts are included in the unRAID image, you can no longer even boot on a 768 Meg RAM machines. The realistic minimum specification needed to run unRAID is now 1.5 - 2 Gig RAM. Now are you honestly able to come to a different conclusion after looking these numbers over? Release two versions and allow the users to determine which to get. Or, provide the extra stuff with enough explanation how or where to uncompress it so that installations are possible.
August 21, 201015 yr Release two versions and allow the users to determine which to get. Or, provide the extra stuff with enough explanation how or where to uncompress it so that installations are possible. Now that I can agree with, but then it's slightly more work for Lime-Tech. Though I suppose one of us could make a package for installpkg for it. My point behind VMWare/VBox being a pita was simply if they allowed binary distributions, then this is all moot. One of us could/would go through the trouble of compiling it, then make a package of the artifacts, and then distribute that. No headaches would be distributed to each and every user trying to get it running. But no.... They don't seem to allow that.
August 21, 201015 yr My point behind VMWare/VBox being a pita was simply if they allowed binary distributions, then this is all moot. This is very true. So getting back to the original purpose of this thread, there isn't anything additional needed kernel-wise to support VMware or VBox. <<If you don't care about VMs in unRAID, feel free to stop reading here>> However, though this would probably be more appropriate in a different thread, to address the point of those who would like to use VMs but aren't keen on all the work currently required, two things would make using VMs on a stock unRAID much more trivial: Scripting of the entire compiling/packaging process Building a development environment VM (including the script) that could be shared The goal would be that a user could fire up the VM dev environ in, say, a Windows environment, log in, download the VMware (or VBox) software, update a text file to enter their key code, run the script, and voila...an unRAID-installable VMware package. I wish I had thought of doing this way back when, when I first published my instructions. At this point, I don't know when/if I'll ever have the time to upgrade my current install (4.4.2) and/or learn how to do any semblance of scripting to help accomplish this, but it should be entirely possible. This is what's needed to make VMware/VBox easy to install. unRAID already has what we need, so let's take this on as a community and let Lime-Tech work on the stuff we can't do.
August 21, 201015 yr This is very true. So getting back to the original purpose of this thread, there isn't anything additional needed kernel-wise to support VMware or VBox. No. You just need a build environment.
August 21, 201015 yr This is very true. So getting back to the original purpose of this thread, there isn't anything additional needed kernel-wise to support VMware or VBox. No. You just need a build environment. Statement. Not a question.
August 21, 201015 yr I agree with queegs comments and suggestions above in the thread. I also really like unRAID for its simplicity, and fully understand the objective of keeping it lean. That's why I think this is really a good idea. Release two versions and allow the users to determine which to get. Or, provide the extra stuff with enough explanation how or where to uncompress it so that installations are possible. Now that I can agree with, but then it's slightly more work for Lime-Tech. Though I suppose one of us could make a package for installpkg for it. Either two versions, optional installs from Lime-tech or the community, or whatever else leads to the objective. Is there a way forward here?
August 21, 201015 yr This is not rocket science ... it is the same procedure with anything you try to install which fails because something is missing. 1. Download application (in this case, vbox/vmware) 2. Run the install. If it installs, run the program itself. 3. Note what the install or the program complains you don't have. 4a. go to http://slackware.cs.utah.edu/pub/slackware/slackware-12.1/ 4b. check PACKAGES.TXT to find the location of what you are missing 4c. download what you are missing 4d. installpkg what you are missing 5. Go to step 2 and try the install again For example, this is what I needed to add, to compile the kernel (I am on Slackware 13.1, so they have .txz packages) binutils-2.20.51.0.8-i486-1.txz libx86-1.1-i486-1.txz make-3.82-i486-1.txz gcc-4.4.4-i486-1.txz gcc-g++-4.4.4-i486-1.txz gettext-0.17-i486-3.txz glibc-2.11.1-i486-3.txz gmp-5.0.1-i486-1.txz kernel-headers-2.6.33.4_smp-x86-1.txz libpciaccess-0.11.0-i486-1.txz mpfr-2.4.2p03-i486-1.txz ncurses-5.7-i486-1.txz pciutils-3.1.5-i486-1.txz perl-5.10.1-i486-1.txz zlib-1.2.3-i486-2.txz and the xz package, of course, for the .txz packages.
August 21, 201015 yr This is not rocket science ... it is the same procedure with anything you try to install which fails because something is missing. 1. Download application (in this case, vbox/vmware) 2. Run the install. If it installs, run the program itself. 3. Note what the install or the program complains you don't have. 4a. go to http://slackware.cs.utah.edu/pub/slackware/slackware-12.1/ 4b. check PACKAGES.TXT to find the location of what you are missing 4c. download what you are missing 4d. installpkg what you are missing 5. Go to step 2 and try the install again For example, this is what I needed to add, to compile the kernel (I am on Slackware 13.1, so they have .txz packages) binutils-2.20.51.0.8-i486-1.txz libx86-1.1-i486-1.txz make-3.82-i486-1.txz gcc-4.4.4-i486-1.txz gcc-g++-4.4.4-i486-1.txz gettext-0.17-i486-3.txz glibc-2.11.1-i486-3.txz gmp-5.0.1-i486-1.txz kernel-headers-2.6.33.4_smp-x86-1.txz libpciaccess-0.11.0-i486-1.txz mpfr-2.4.2p03-i486-1.txz ncurses-5.7-i486-1.txz pciutils-3.1.5-i486-1.txz perl-5.10.1-i486-1.txz zlib-1.2.3-i486-2.txz and the xz package, of course, for the .txz packages. Oh, yeah. Everybody redo this over and over and over and over and over............individually!
August 21, 201015 yr Oh, yeah. Everybody redo this over and over and over and over and over............individually! As I said, this PAIN is caused by the policies of VMWare and VBox. It could be easily remedied if their policies were different. Direct your anger appropriately.
August 22, 201015 yr Oh, yeah. Everybody redo this over and over and over and over and over............individually! Most people who run vmware or vbox on unRIAD are doing it 1) on a full Slackware install or 2) have a full Slackware build environment they can install it on, and then move it. So you are asking someone to do work that they do not need to do, that benefits you and not them. We've told you how to fish, and you keep complaining you are not getting enough fish. If you think an installable package of vmware or vbox is such a hot idea, then why don't you do it, and then anyone else who needs it will thank you for it.... and you can deal with the vmware/oracle license violations such a package creates. I certainly have no desire to invite nastygrams from vmware or Oracle's lawyers. There are some very detailed and useful instructions in the wiki and the forums, but almost all of them were done by people who wanted the end product for themselves, and documented the process to share it. I simply don't know anyone who needs what you are asking for other than yourself, so I don't see anyone volunteering to do the work you want done.
August 22, 201015 yr Oh, yeah. Everybody redo this over and over and over and over and over............individually! Most people who run vmware or vbox on unRIAD are doing it 1) on a full Slackware install or 2) have a full Slackware build environment they can install it on, and then move it. So you are asking someone to do work that they do not need to do, that benefits you and not them. Don't get on your high horse. Lots of people on this forum do free service for the benefit of others. I have also. So don't try to make some kind of pariah out of me. You seem to attack character at the drop of a hat. If you think an installable package of vmware or vbox is such a hot idea, then why don't you do it, and then anyone else who needs it will thank you for it.... and you can deal with the vmware/oracle license violations such a package creates. I certainly have no desire to invite nastygrams from vmware or Oracle's lawyers. There are some very detailed and useful instructions in the wiki and the forums, but almost all of them were done by people who wanted the end product for themselves, and documented the process to share it. I simply don't know anyone who needs what you are asking for other than yourself, so I don't see anyone volunteering to do the work you want done. I have tried. The detailed instructions fail. Even you don't remember all the stuff you did. I'm not ashamed to want to use vmware on unRAID and I'm not ashamed that I haven't been able to do it myself. If you feel that my character is beneath yours then so be it. Others have +1 EVERY time the subject comes up. Pull your head out of the sand. It's one thing to not want to invest any time solving the problem. It's a completely different thing to be compelled to beat down those requesting the feature. Consider it requested again.
August 22, 201015 yr What you really want is for VMWare to change the terms of their license and remove their restrictions. In the mean time you will have to make do with http://lime-technology.com/wiki/index.php?title=Installing_unRAID_on_a_full_Slackware_distro and http://lime-technology.com/forum/index.php?topic=862.msg24297#msg24297
August 22, 201015 yr I am not attacking your character, I am trying to point out that what you want will violate the license terms of VMware and Oracle. In order to do it legally, you first need to install unRAID on a full Slackware distro. Plenty of people can and will help you with that, including me. There are detailed instructions for that in the wiki, although I need to update a couple of things for 5.0-Beta-2. Once you have unRAID on a full Slackware distro, you can build either VBox or VMware, and we will help you with that. After you build it you can move it if you want. But no one can send you the pre-built binaries w/o violating the license agreements. There is not now, no will there ever be a simple "one-click" option to install VMware or VBox on unRAID.... unless they change their license agreement.
August 22, 201015 yr Can we move the vmware on unRAID to another thread? Don't get me wrong, I'm very interested in having vmware run on unRAID. I've been running vmware since 2.0. This started out originally as a call for requests on beta-3. It's gotten a bit off subject. Albeit a valid request, there are issues here that limetech cannot resolve. Beta-3 is ready to post. Here's the current change log: ... Reason for this post is to let you request things you need for -beta3 that I can throw in before embarking on above 'major' changes. I'd like to get -beta3 out this week, preferably by Wednesday, so the window for requests is open for a small time. FWIW, one of the prior discussions had to deal with tmpfs and having some of unRAID reside on tmpfs instead of initramfs. I've found a way of doing this via rc.S at least for the /usr area. By adding the following chunklet to /etc/rc.d/rc.S we can have a callout which can do operations earlier then the go script (which is invoked via rc.local). /etc/rc.d/rc.S # tmm - finally stops the staircasing! stty -F /dev/console -raw # Invoke the user 'rc.S' script if [ -f /boot/config/rc.S ]; then fromdos </boot/config/rc.S >/var/tmp/rc.S chmod +x /var/tmp/rc.S /var/tmp/rc.S fi My script to move /usr to a tmpfs follows. I'm going to play with /var now. root@unraidvm:/etc/rc.d# more /boot/config/rc.S #!/bin/bash if /bin/grep -qi safe /proc/cmdline then echo "$0: safe mode enabled, skipping." exit fi echo "$0: running." MP=usr /bin/test -d /${MP}.tmpfs && /bin/rmdir /${MP}.tmpfs /bin/mkdir /${MP}.tmpfs /bin/mount -t tmpfs tmpfs /${MP}.tmpfs /bin/mv /${MP}/* /${MP}.tmpfs/ /bin/test -d /${MP}.bak && /bin/rmdir /${MP}.bak /bin/mv /${MP} /${MP}.bak /bin/mkdir /${MP} /bin/mount --move /${MP}.tmpfs /${MP} /bin/rmdir /${MP}.tmpfs /${MP}.bak /bin/df -vH /${MP} This ends up with. root@unraidvm:/etc/rc.d# df -vh /usr Filesystem Size Used Avail Use% Mounted on tmpfs 252M 124M 128M 50% /usr Which allows unused parts of /usr to be swapped out when needed. No one has to use the /usr on tmpfs script. I'm only asking for the callout to /boot/config/rc.S for the more advanced users. before multiuser is invoked. I have other chunklets and patches which modify the /etc/rc.d/rc.inet1.conf which allow use of alternate ethernet ports. To summarize I have 2 requests. 1. to add a callout to /boot/config/rc.S if it exists. 2. to add a safe mode check in /etc/rc.d/rc.local # Install any extra packages if ! grep -qi safe /proc/cmdline; then if [ -d /boot/extra ]; then ( cd /boot/extra ; find -maxdepth 1 -type f -exec installpkg {} \; ) fi fi Ideally we should have something like this in the go script after the call to emhttp. I'll leave that up to the user since many have already modified the go script.
August 22, 201015 yr FWIW, this works with /var too. In addition I filled up usr & var when mounted as a tmpfs (and having 1GB of swap). Ths system did not crash. root@unraidvm:/# df -vH Filesystem Size Used Avail Use% Mounted on /dev/hda1 2.2G 1.6G 581M 73% /boot tmpfs 264M 130M 135M 50% /usr tmpfs 264M 615k 263M 1% /var /dev/md2 2.2G 34M 2.2G 2% /mnt/disk2 /dev/md1 2.2G 377M 1.8G 18% /mnt/disk1 shfs 4.3G 410M 3.9G 10% /mnt/user root@unraidvm:/# /boot/bin/swap.sh swapon on /boot/unraid.swapfile swapon: warning: /boot/unraid.swapfile has insecure permissions 0777, 0600 suggested root@unraidvm:/# top -b | head -5 top - 13:45:59 up 2 min, 1 user, load average: 0.13, 0.20, 0.08 Tasks: 60 total, 1 running, 59 sleeping, 0 stopped, 0 zombie Cpu(s): 0.2%us, 22.6%sy, 0.0%ni, 76.4%id, 0.2%wa, 0.6%hi, 0.0%si, 0.0%st Mem: 514856k total, 191500k used, 323356k free, 664k buffers Swap: 1048568k total, 0k used, 1048568k free, 156820k cached root@unraidvm:/# cd / -- out space is expected here. I'm filling up the filesystems. root@unraidvm:/# dd if=/dev/zero of=/usr/test.dd dd: writing to `/usr/test.dd': No space left on device 261817+0 records in 261816+0 records out 134049792 bytes (134 MB) copied, 1.00897 s, 133 MB/s root@unraidvm:/# dd if=/dev/zero of=/var/test.dd dd: writing to `/var/test.dd': No space left on device 513145+0 records in 513144+0 records out 262729728 bytes (263 MB) copied, 6.79241 s, 38.7 MB/s root@unraidvm:/# top -b | head -5 top - 13:46:43 up 3 min, 1 user, load average: 0.32, 0.23, 0.10 Tasks: 60 total, 1 running, 59 sleeping, 0 stopped, 0 zombie Cpu(s): 0.4%us, 18.9%sy, 0.0%ni, 76.8%id, 3.5%wa, 0.5%hi, 0.0%si, 0.0%st Mem: 514856k total, 508288k used, 6568k free, 360k buffers Swap: 1048568k total, 82412k used, 966156k free, 463608k cached root@unraidvm:/# tail /var/log/syslog Aug 22 13:43:19 unraidvm emhttp: get_config_idx: fopen /boot/config/shares/pub.cfg: No such file or directory - assigning defaults Aug 22 13:43:19 unraidvm emhttp: Restart CIFS... Aug 22 13:43:19 unraidvm emhttp: shcmd (19): killall -HUP smbd Aug 22 13:43:19 unraidvm emhttp: shcmd (20): /usr/local/emhttp/emhttp_event svcs_restarted Aug 22 13:43:19 unraidvm emhttp_event: svcs_restarted Aug 22 13:43:24 unraidvm in.telnetd[1913]: connect from 192.168.1.16 (192.168.1.16) Aug 22 13:43:27 unraidvm login[1914]: ROOT LOGIN on `pts/0' from `rcotrone-vxpws.cotrone.com' Aug 22 13:43:53 unraidvm kernel: md: sync done. time=35sec rate=59917K/sec Aug 22 13:43:53 unraidvm kernel: md: recovery thread sync completion status: 0 Aug 22 13:45:53 unraidvm kernel: Adding 1048568k swap on /boot/unraid.swapfile. Priority:-1 extents:1 across:1048568k no unexpeced OOM messages. on console or here. root@unraidvm:/# df -vH Filesystem Size Used Avail Use% Mounted on /dev/hda1 2.2G 1.6G 581M 73% /boot tmpfs 264M 264M 0 100% /usr tmpfs 264M 264M 0 100% /var /dev/md2 2.2G 34M 2.2G 2% /mnt/disk2 /dev/md1 2.2G 377M 1.8G 18% /mnt/disk1 shfs 4.3G 410M 3.9G 10% /mnt/user So my proposal is for the rc.S hook. use of this hook to move /usr and /var to tmpfs is entirely up to the user. Ideally / on a tmpfs is the best choice, but for now, this helps those of us who have swap and want to use it for temporary expansion.
August 22, 201015 yr How about a 64-bit version of unRAID? Can we start testing this with the 5.0beta series? I'm sure many of us would like to start running x64 apps on our processors to speed up CPU intensive applications.
Archived
This topic is now archived and is closed to further replies.