olbrecht.net journal VMware server on ReadyNAS 4.2.11

VMware server on ReadyNAS 4.2.11

This is an updated and extended how-to, in which I will explain how you can install VMware Server 2 on the Netgear ReadyNAS PRO / 3200 / 4200 platform:

It applies to the following versions:

  • ReadyNAS firmware version Raidiator 4.2.11
  • VMware Server v2.0.2-203138.i386

First of all, let’s prepare:
1. Upgrade your ReadyNAS to the current firmware release using the Frontview control panel -> System -> Update -> Remote -> Reboot.
2. Decide on where you want to put your virtual machines, I decided to put them on a share of their own which I created. I called it “vm”. Create this share via Frontview. This makes sense in so far as VMware will create the files for virtual machines with “root” privileges, meaning only the root user will have access to these files via SMB or other access methods unless you reset share privileges via Frontview.
3. Decide where you want to put the ReadyNAS source code and VMware installation packages. I chose the already existing backup-share.
4. Install the EnableRootSSH addon to gain access to the ReadyNAS via SSH. You can download this add-on here: http://www.readynas.com/download/addons/x86/4.2/EnableRootSSH_1.0-x86.bin and install it via Frontview in System -> Update -> Local. Reboot.
5. You will need an ssh client such as putty.
6. You will need to register an account on vmware.com to download the free VMware Server. Get the i386 package, not the 64-bit package. This guide was compiled against version 2.0.2-203138.i386

Now let’s get started:
With putty, connect to your ReadyNAS and login as the “root” user. The password should be the same as your FrontView admin-password. You are now at the command prompt for your NAS.

#Note the following line:
Linux YOURNASNAME 2.6.33.4.RNx86_64.2.1 #1 SMP Wed May 19 19:36:51 PDT 2010 x86_64 GNU/Linux
#If you did all the earlier preparation right, your NAS will be running the x86_64 Linux Kernel in version 2.6.33.4. Let’s continue some preparations:

apt-get update && apt-get install build-essential

#This will install the necessary Linux components for compiling your kernel and VMware server. There will be a prompt if you really want to install these packages, as well as a prompt that a few packages could not be authenticated. Answer both with YES.

#Then let’s change into our work directory:
cd /c/backup
#We are now on the backup share. All shares you create via Frontview will be created within the directory /c/. Avoid using other Linux paths as they probably will be on the system partition of the NAS, which is only 5GB. It is not a good idea to have that run out of space.

#Then we will download the ReadyNAS GPL Package for Raidiator 4.2.11:
wget -q http://www.readynas.com/download/GPL/RNDP6xxx_4.2.11_WW_src.zip
#Let’s unpack it:
unzip -q RNDP6xxx_4.2.7_WW_src.zip -d ./GPL
#Now we will have to compile a new kernel to get the modules we need to run VMware Server.
cd GPL/linux-2.6.33.4
make ARCH=x86_64 oldconfig && make ARCH=x86_64
#This is going to take a while. You can go get another cup of coffee.

#We will need to tell Linux that we compiled a new kernel and its associated modules, as well as where to find it. For this we make a symbolic link:

ln -s /c/backup/GPL/linux-2.6.33.4/ /usr/src/linux
KERN_DIR=/usr/src/linux

#There has been a slight change in symlinks with kernel 2.6.32 onward which requires us to create two additional symlinks. Without these, VMware setup won’t work later on:

cd /usr/src/linux/include/linux
ln -s ../generated/utsrelease.h
ln -s ../generated/autoconf.h .

Now on to install the VMware server. First let’s copy the downloaded archive for the VMware server on the backup share.
Back in the ssh session, we’re going to unpack it, but first let’s change back into the backup share directory:

cd /c/backup
#and let’s unpack it:
gzip -d VMware-server-2.0.2-203138.i386.tar.gz
tar –xvf VMware-server-2.0.2-203138.i386.tar.gz

#Now we need to install some patches for VMware server to make it compatible with our kernel version:
wget http://risesecurity.org/~rcvalle/VMware-server-2.0.2-203138-update-2.patch

The following is taken from Ramon de Carvalho Valle at rise security (http://risesecurity.org/2010/04/02/vmware-server-2-0-2-update-patch-2/). Thanks to him for creating the patch.

#Extract VMware Server modules:
# Change working directory to vmware-server-distrib/lib/modules/source/
$ tar -xf vmci.tar
tar -xf vmmon.tar
tar -xf vmnet.tar
tar -xf vsock.tar

#Apply the patch:

#Change working directory to vmware-server-distrib/
patch -p1 < ../VMware-server-2.0.2-203138-update-2.patch

#Archive VMware Server modules again:

#Change working directory to vmware-server-distrib/lib/modules/source/
$ rm -f vmci.tar
rm -f vmmon.tar
rm -f vmnet.tar
rm -f vsock.tar
tar -cf vmci.tar vmci-only/
tar -cf vmmon.tar vmmon-only/
tar -cf vmnet.tar vmnet-only/
tar -cf vsock.tar vsock-only/

#And now let’s go install the VMware server:

cd vmware-server-distrib
./vmware-install.pl

#You will get several prompts now which you can all accept at face value except for one: You *must* change the default value for where to put the storage for virtual machines to a path within the /c/ directory. For this I prepared my “vm” share. Hence, I changed the path to “/c/vm/”. This is to make sure your virtual machines won’t kill the system volume of the ReadyNAS.

End notes and limitations:
Thanks to chirpa at the ReadyNAS forum for helping with my questions about the kernel and GPL package and for supplying me with early access to the GPL resources.
Enjoy.

Known limitations:
– The VMware server webinterface seems to have its issues on browsers other than Internet Explorer. I recommend you install the VMware Infrastructure Client to access the VMware host and its virtualised guests.
– Sometimes if you manually restart the VMware services by running “/etc/init.d/vmware restart”, the virtual network service does not want to properly restart. This requires re-running the configuration script “/usr/bin/vmware-config.pl”.

2 thoughts on “VMware server on ReadyNAS 4.2.11”

  1. Hello,

    I tried to install VMware on a readynas pro 4.2.13.
    Somehow it failed…..
    The last entry’s:
    arch/x86/boot/compressed/vmlinux.bin.lzma: No such file or directory
    AS arch/x86/boot/compressed/piggy.o
    gcc: arch/x86/boot/compressed/piggy.S: No such file or directory
    gcc: no input files
    make[2]: *** [arch/x86/boot/compressed/piggy.o] Error 1
    make[1]: *** [arch/x86/boot/compressed/vmlinux] Error 2
    make: *** [bzImage] Error 2

    When i run the command again it gives:
    scripts/kconfig/conf -o arch/x86/Kconfig
    #
    # configuration written to .config
    #
    scripts/kconfig/conf -s arch/x86/Kconfig
    CHK include/linux/version.h
    CHK include/generated/utsrelease.h
    CALL scripts/checksyscalls.sh
    CHK include/generated/compile.h
    LZMA arch/x86/boot/compressed/vmlinux.bin.lzma
    /bin/sh: lzma: command not found
    MKPIGGY arch/x86/boot/compressed/piggy.S
    arch/x86/boot/compressed/vmlinux.bin.lzma: No such file or directory
    AS arch/x86/boot/compressed/piggy.o
    gcc: arch/x86/boot/compressed/piggy.S: No such file or directory
    gcc: no input files
    make[2]: *** [arch/x86/boot/compressed/piggy.o] Error 1
    make[1]: *** [arch/x86/boot/compressed/vmlinux] Error 2

    Any change that i can succesfull install VMware?

  2. Just install lzma:

    apt-get install lzma
    run the make command again

Comments are closed.

Related Post

Issues preparing for upgrade to SCVMM 1801Issues preparing for upgrade to SCVMM 1801

I just ran into a small hickup upgrading my System Center Virtual Machine Manger 2016 to the new version 1801. I wasn’t able to find any documented cases of anyone running into this so here we go:

The upgrade to SCVMM 1801 actually requires uninstalling SCVMM 2016. This failed on my installation just at the point where I was clicking on the “Remove features” button in the setup dialog.

In C:\ProgramData\VMMLogs\SetupWizard.log I found the following entry:

11:52:28:Uncaught Exception: Threw Exception.Type: Microsoft.VirtualManager.Utils.CarmineException, Exception.Message: Unable to detect cluster configuration of the node.
Ensure that the user has permissions to detect cluster node configuration.
11:52:28:StackTrace: at Microsoft.VirtualManager.Setup.ClusterServiceHelper.get_IsAClusterNode()
 at Microsoft.VirtualManager.Setup.AddRemoveComponentsPage.EnterPage()
 at Microsoft.VirtualManager.SetupFramework.PageNavigation.WaitEnterSet(Page page)
 at Microsoft.VirtualManager.Setup.AddRemovePage.RemoveComponent_Click(Object sender, RoutedEventArgs e)
 at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
 at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
 at System.Windows.Controls.Primitives.ButtonBase.OnClick()
 at System.Windows.Controls.Button.OnClick()
 at System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButtonEventArgs e)
 at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
 at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
 at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
 at System.Windows.UIElement.ReRaiseEventAs(DependencyObject sender, RoutedEventArgs args, RoutedEvent newEvent)
 at System.Windows.UIElement.OnMouseUpThunk(Object sender, MouseButtonEventArgs e)
 at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
 at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
 at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
 at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
 at System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)
 at System.Windows.Input.InputManager.ProcessStagingArea()
 at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
 at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
 at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
 at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
 at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
 at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
 at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
 at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
 at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
 at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
 at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
 at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
 at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
 at System.Windows.Application.RunDispatcher(Object ignore)
 at System.Windows.Application.RunInternal(Window window)
 at Microsoft.VirtualManager.Setup.Program.UiRun()
 at Microsoft.VirtualManager.Setup.Program.Main()

So what this means is that the setup is unsuccessfully trying to determine whether SCVMM is installed in a clustered setup. Which mine is not. Has never been.

The solution is to actually *install* the Windows Feature Failover Clustering. This way the check can run and setup will continue. There is no need to actually configure clustering.

Fixing Windows Admin Center ‘Can’t verify whether “cluster_name” is online’Fixing Windows Admin Center ‘Can’t verify whether “cluster_name” is online’

So you’re trying to add your Hyper-Converged Cluster to Windows Admin Center and it’s giving you the “Can’t verify whether “cluster_name” is online” treatment. You’ve checked DNS, upgraded WAC/Honolulu and tested installing it on multiple servers and workstations. Nothing helped. I have good news! for you:

I ran into this immediately after Project Honolulu became public and have been banging my head continuously. Here’s what to do:

Check the Event Viewer\Applications and Services Logs\Microsoft-ServerMangementExperience for the following entry:

400 - CimException: The xsi:type attribute (p1:MSCluster_Property_Node_PrivateProperties) does not identify an existing class.

This indicates your that WAC is connecting fine to your cluster but is running into an issue where it’s missing some cluster property.

I’ll have to give props to Robert Hochmayr here as he pointed me to the solution:

There are two private properties that are set on the cluster and its nodes which through some combination of events (like adding nodes to the cluster at a later point in time) are missing from nodes. You can find out by running the following PowerShell command on one of your S2D cluster nodes:

get-clusternode | Get-ClusterParameter

The output will look something like this:

Object Name Value Type
------ ---- ----- ----
S2D-01 S2DCacheBehavior 88 UInt64
S2D-01 S2DCacheDesiredState 2 UInt32
S2D-03 S2DCacheDesiredState 2 UInt32
S2D-03 S2DCacheBehavior 88 UInt64

Note that this was a four node cluster.. Nodes S2D-02 and S2D-04 are missing!

Off to the registry to fix it:

At HKLM\Cluster\Nodes\x\Parameters there should be two entries for the above cluster parameters. On my systems, the full registry key Parameters was missing from nodes 1 and 4 (go figure…). I added them *on each host* by running the following command lines:

REG ADD HKEY_LOCAL_MACHINE\Cluster\Nodes\1\Parameters /f /v  "S2DCacheBehavior" /t REG_QWORD /d "88"
REG ADD HKEY_LOCAL_MACHINE\Cluster\Nodes\1\Parameters /f /v "S2DCacheDesiredState" /t REG_DWORD /d "2"
REG ADD HKEY_LOCAL_MACHINE\Cluster\Nodes\4\Parameters /f /v  "S2DCacheBehavior" /t REG_QWORD /d "88"
REG ADD HKEY_LOCAL_MACHINE\Cluster\Nodes\4\Parameters /f /v "S2DCacheDesiredState" /t REG_DWORD /d "2"

Checking I now get the correct PowerShell output:

get-clusternode | Get-ClusterParameter

Object Name Value Type
------ ---- ----- ----
S2D-01 S2DCacheBehavior 88 UInt64
S2D-01 S2DCacheDesiredState 2 UInt32
S2D-02 S2DCacheBehavior 88 UInt64
S2D-02 S2DCacheDesiredState 2 UInt32
S2D-03 S2DCacheBehavior 88 UInt64
S2D-03 S2DCacheDesiredState 2 UInt32
S2D-04 S2DCacheBehavior 88 UInt64
S2D-04 S2DCacheDesiredState 2 UInt32

Once this was added I was immediately able to add the cluster to Windows Admin Center. No reboots or service restarts were needed.

-Jan

Maintenance and Non-OEM sparesMaintenance and Non-OEM spares

So I need to replace the battery on my trusty vacuum bot iRobot Roomba 780. Judging from my purchase history, I have had the robot for approx. 18 months when I replaced the old original battery with a knock-off spare claiming 50% more capacity (4500mAh vs 3000mAh on the original pack).

By now, 25 more months have passed and I need to get another replacement. Just looking at the timeline, there is precious little reason to even think about getting the original part when the knockoff lasted longer than the original one.

So in case anyone is wondering, here’s what I’m getting:

-Jan