Patch - support for VMware / VMX file overrides

Project:JNode Core
Component:Miscellaneous
Category:task
Priority:normal
Assigned:Stephen Crawley
Status:closed
Description

You know how manual additions the jnode-x86-lite.iso.vmx file get clobbered each time you run the build script? Well this patch allows you to merge VMX settings to override the default ones ... each time the ...iso.vmx file is created.

To use it, simply create a file containing the VMX setting overrides you want, then edit the jnode.properties file to set the vmware.vmx.overrides properties to the name of the file.

If this approach looks good to other folks, I'll commit it.

AttachmentSize
issues_12012.9 KB

#1

Status:active» patch (code needs review)

I've updated the Booting from VMWare" page to describe the way to do this (among other things).

#2

Since the only thing the build system delivers to VMware is the cd image (besides the config file) I don't see a huge need for this. I always had my own vmware config file to which I added that only cd image from JNode and it was done. That might be only my way of doing it though and others might prefer other solutions.
On one hand I can see a need for more flexibility in tailoring the build system to one's own needs without much conflicts on the SVN level, on the other hand I would like to avoid overloading the build system with features of little or very speciffic use. For me the whole topic of the VMX files belong much more to the domain of VMware. Providing the VMX file for the convenience of the downloaders proved to be useful though.
One could also ask, what about the other vmware-like products like bochs, qemu, vitualbox, parallels etc., should we provide some basic support for them?

What do others think?

#3

Some points in response to Levente:

  1. The patch I've implemented, while specific to VMWare, builds on existing VMWare support. The decision to include VMWare specific support into the JNode build process has already been made.
  2. The fact that we do not (currently) provide any build support for the various other emulator products is not a valid reason not to support VMWare better.
  3. I for one think it is OK to "support" just one emulation product to run JNode, provided that does the job well enough. It may actually a good thing to do. If we "support" just one emulator, new folks don't need to waste time figuring out which is the best one to use for JNode. (I wasted a few hours on this, and forked out money for a VMWare Workstation license that I didn't really need!)

In the long run, people should be able to EASILY configure/build JNode from SVN so that it runs on the supported emulator(s) with a virtual disc and FS that lasts beyond the next time they run "build". The current approach is just too hard. My patch goes some way to implementing this ideal. If we added some tar / zip files to SVN containing pre-built VMWare virtual disk images and VMX overrides, and did some ant work to untar/unzip these images to an appropriate location (not in the all/build tree), we'd have a reasonable first-cut solution.

#4

I still don't get how the appraoch proposed by this patch is more simple and useful than creating your own VMX file based on what JNode generates?

#5

For a start, it provides a better way to integrate Martin's pre-built filesystem TAR files. The TAR files would supply a file containing the override VMX entries for the hard disc that is being configured. The end user just has to untar the file, and then change one line of the "jnode.properties" file.

This is clearly easier for a new JNode user than using a text editor to merge Martin's full ".vmx" files with the ones generated by the build. For a start, the user does not need to read the VMX file format documentation to figure which settings to merge and which ones to discard.

We should be aiming to make configuring JNode easy, not something that new users have to spend hours trying to figure out. You forget that new JNode users do not understand the system the way that you do. Even I had problems last week when I tried to configure a virtual disk for the first time.

#6

Bug in patch ... fixed

#1

Status:patch (code needs review)» closed

Similar changes to this patch have been committed. Closing this issue.