Dani M.'s picture


Does any one know why there is not a .vbox file in the "default build" ZIP?

This would permit a simple "download, unzip, double-click and play" (just needing Virtualbox installed).

This works like a charm with the already included .vmx (but needs VMWare Player installed... not so universal).

Sorry if this has been addressed before (not found in the forum or the FAQ).

Or maybe I am missing something very straighforward? (sorry if this is the case, I will appreciate any hints or feedback on this).

Besides, being this my first post here, if Liraz, Aron or Jeremy are reading this, I want to use the occasion to give them my sincere congratulations for their impressive work.

Best regards,

Dani M.

PS: Longer rationale on the question/suggestion:

  • Virtualbox is currently more "universal" and inmediate than VMWare Player (available on Mac, on vanilla Ubuntu repos, less cumbersome download and install on Windows...)... Besides VB is (almost) FOSS (also in TKLX philosophy). I think that VB is the current "initial gate" to virtualization for many "end-users" (or the suggestion to make to them, as the starting learning point).

  • Thus, adding a .vbox to the .ZIP builds, would greatly help for the use case of a "user that knows nearly nothing and wants to discover Turnkey and play with it on a local client desktop". I think that this case would "cheaply" help to increase the popularity of TKLX. I've seen in the Forums that this has been and still is a concern for the developers. TKLX is not having the popularity it clearly deserves... but I see the focus on reasons for "pro" users not adopting it, but less for reasons for totally unexperienced users not adoping it. An accidentally totally unexperienced user of today may be becoming a pro tomorrow. And this users I think have been a key reason for TKLX project.

  • Current instructions for Virtualbox in the Turnkey web (http://www.turnkeylinux.org/docs/installation-appliances-virtualbox) are a little bit "hidden" (although I consider them key for a newcomer with little background). Besides, even being "quite easy", they pose some "unnecessary" initial burden (contrary to TKLX philosophy), and specially for unexperienced users on VB: know how to create and configure a new VM (not just installing the software and "using" a prepared VM), the .vmdk is uncompressed on disk in a different place that the created VM (unless one does more sophisticated things like creating empty VM, then copying the .vmdk to the VM folder, then attaching it... not documented in the instructions). The instructions are also a lite bit "outdated": they recognize it initially and point to the support forum in case of need... But if the .vbox was "built-in", the instructions would be more future proof and simpler: Install Virtualbox, download and unzip the .zip of an appliance, double-click the .vbox file... and play!
  • Maybe this simply hasn't been in the "radar" (priorities) of the developpers (I see on the forums that they are "overwhelmed", and prioritizing recently for more professional "initial users" and use cases), but one of the greatest things of TKLX is it's potential to "catch" very inexperienced users (lowering the barriers to entry)... And this looks like a really straighforward addition for a developper, unobstrussive and IMO paying off. Sorry if I'm being too naive here (or not having the global picture).
  • On TKLX dev side, not sure how this stuff is currently done for generating the .vmx. The .vmx's seem like a common template with just a couple of customized things like the VM name and the .vmdk file name. If .vmx generation is automated on appliances generation, I assume it will be very easy adding the .vbox file from a common .vbox template (unique for the whole TKLX project), processed in a similar way than the .vmx. If not currently automated, doing so for each appliance seems like a very little and trivial step (although I know that there are a lot of appliances!).
  • Regarding "my context": I'm a IT teacher, so I love TKLX for giving my students a straightforward but "serious" initial point to learning on servers and applications (done this for a few years now). Just missing this "detail" for an "unbeatable easy initial setup" (with Virtualbox). And what applies to my students, I think that also applies to any "self-teached" guy that has the luck to land on turnkeylinux.org (but that has the "bad luck" of not having yet nearly any "non-desktop" knowledge)... It is possible that for this guy, using TKLX is maybe it's first approach to virtualization, so he is discovering Virtualbox at this moment (maybe I'm missing something, but I think Virtualbox is currently the virtualization product with lower entry barrier for end-users).


Jeremy Davis's picture

And I think your suggestion/feature request is sound. I don't know much about VirtualBox (other than basic usage) and even less about VMware...

I'm pretty sure that the VMX file is autogenerated by the build script which converts the ISO into the VMDK. So also creating a VBOX file (assuming that it is a simple text file) should be just as straight forward.

How about if I try and get the build code for the VMDK creating process publicly available then perhaps you'd be willing to look into this a little further? WIth more clarity on how the VMX is made, I suspect that automating a VBOX should be pretty easy...

Dani M.'s picture

Hi Jeremy! Thanks to your for your kind response.

While waiting for feedback (and after your feedback), I've been thinking and having a deeper look at this.

.vbox is effectively a simple XML file, although not as simple as .vmx (for VMWare).

But now I think that my initial proposal may not be the "better" way.

The problem is that VBOX (contrary to VMWare) is really picky when one tries to "hack" its VM's and .vbox files... The .vbox needs on some of its fields the UUID of the virtual disk, which must be unique for a given VBOX installation. "Building" the .vbox file on TKL dev side will not be simply putting the same info put on the .vmx (machine name, etc), but to get the .vmdk UUID, and put it in some places in the template file, and maybe further tricks are needed. Surely not a really big issue, but not as straighforward as I initially thought.

Advantajes of this approach: as I said, user only needs to unzip and then double-click the file with .vbox extension (recognized if VBOX is installed). The VM resides where the user extracted. It is very efficient, since the vmdk is only extracted once. But I've seen now that the .OVF download is also compatible with Virtualbox, and as simple as this (although it has currently a bug, I'm addressing this in a different post).

Disadvantages: development not as straighforward. Very "VBOX" dependent. Not straighforward for a novice user to "instatiate" different TKLX of the same appliance by just copying or re-extracting (due to UUID clashes... VBOX is really annoying on this).

In short: although I think it is feasible, I've been thinking of better ways... If you don't mind, we "set aside" (at least for the moment) my initial proposal and have a look to the "new ones".

I'm opening a new thread with a more convenient title, since it "diverges too much" from the original title of this one.


Add new comment