Your argument about the ability to have a given name be used as the final 
artifact name is not correct for prior 4.11 versions, as that only was a 
specific case/condition for systemvm template to copy/rename and then use an 
existing definition, and not with rest of the veewee definitions that existed 
in the folder.

Even if the name of the folder was systemvm64template, you build job may still 
fail due to the build process and tool/environment changes. Finally, you can 
always rename the build artifacts. The issue IMO is with your build job and not 
the current build scripts.

The README file already mentions what arguments can be used to build templates 
but can indeed get some improvements:

Both your suggestions are okay with me, you may improve the README or send a PR 
that modifies the script to handle exporting appliances to custom name 
(but as a general option, not specific to systemvmtemplate).

- Rohit


From: Khosrow Moossavi <>
Sent: Monday, February 19, 2018 3:07:41 AM
Subject: Re: Potential backward incompatibility problem in building SystemVM

Daan, Rohit

With the new packer build (4.11+) one cannot give "blah" to be the final
name of the template.
The script will look for a folder called "blah" in appliance folder which
does not exist. But in before
packer (prior to 4.11) one can give "blah" to be the final name, because
the script would copy
"definition" to "blah" folder and continue the script.

In our own case, for instance, we needed to change the Jenkins script
because it was failing with
"systemvm64template" as the name on

So I guess my point is either 1) we need to change the script to still
handle custom name, 2) have
this documented somewhere (applicane/README may be) that the only accepted
name will be

Minor change either way.

On Sat, Feb 17, 2018 at 2:30 PM, Rohit Yadav <>

> Khosrow,
> The name 'systemvmtemplate' refers to the name of the folder, the
> script now accepts a folder that has the packer definitions such as the
> built-in one or any other future packer based templates. The systemvm
> template's file name is never used for compatibilities sake, one can choose
> whatever name they want and they will be used okay as long as that name is
> correctly configured in the global settings. I don't understand the bit
> about name/compatbility.
> Historically, we used to a 32bit template with its definition defined in
> systemvmtemplate and then we moved to 64-bit template with introduction of
> definitions in systemvm64template folder, and when we did that we added
> that constraint to remove and rename folders while are not needed/useful
> anymore.
> Wrt building it's not backward compatible as well, the build process has
> been changed from virtualbox+veewee/ruby based to packer+qemu/kvm based so
> the old script/jobs are broken as well.
> - Rohit
> <>
> ________________________________
> From: Khosrow Moossavi <>
> Sent: Friday, February 16, 2018 5:58:59 PM
> To:
> Subject: Potential backward incompatibility problem in building SystemVM
> Hi
> I just noticed that the changes [1] in tools/applince/ may break
> backward compatibility
> of the building process of systemvmtremplate.
> In the highlighted (and now removed) line, we used to have a predefined
> name as "systemvm64template"
> and if one still wants to execute " systemvm64template ..." (or any
> other name they
> want) the build will break (becauase of the now new if condition).
> Was this intentional to always have a new "systemvmtemplate" as the name or
> the new if
> condition should be fixed? Super simple to fix anyway.
> if [ "systemvmtemplate" != "${appliance_build_name}" ]; then
> instead of:
> if [ "${appliance}" != "${appliance_build_name}" ]; then
> [1]
> 961036ef91#diff-68ae31f5f30dae8f541e26b8acbd75eeL247
> Khosrow Moossavi
> CloudOps
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue

53 Chandos Place, Covent Garden, London  WC2N 4HSUK

Reply via email to