public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "'Moessbauer, Felix' via isar-users" <isar-users@googlegroups.com>
To: "Kowalsky, Clara" <clara.kowalsky@siemens.com>,
	"isar-users@googlegroups.com" <isar-users@googlegroups.com>
Subject: Re: [PATCH] imagetypes_vm: add support for standalone VMDK images
Date: Fri, 30 Oct 2026 12:27:54 +0000	[thread overview]
Message-ID: <ae9f0b02d436d8fcfe9d4ae80ecae7d39877dac6.camel@siemens.com> (raw)
In-Reply-To: <20261030115757.25391-1-clara.kowalsky@siemens.com>

On Fri, 2026-10-30 at 12:57 +0100, 'Clara Kowalsky' via isar-users
wrote:
> Commit 48c1aee5e797 ("imagetypes_vm: clean up intermediate ova
> artifacts") removes the VMDK after assembling the OVA. Some use cases
> require only a VMDK, both VMDK and OVA, or only OVA.
> 
> With this change, it is possible to set:
> - IMAGE_FSTYPES = "vmdk" to generate the VMDK without OVA packaging
> - IMAGE_FSTYPES = "vmdk ova.zst" to generate both. In that case, OVA
>   depends on the VMDK task and reuses its output without converting the
>   disk again
> - IMAGE_FSTYPES = "ova.zst" to build just the OVA and clean up the
>   intermediate artifacts
> 
> Signed-off-by: Clara Kowalsky <clara.kowalsky@siemens.com>
> ---
>  doc/user_manual.md                        |  1 +
>  meta/classes-recipe/imagetypes_vm.bbclass | 16 ++++++++++++----
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/user_manual.md b/doc/user_manual.md
> index 09ac080b..199eb931 100644
> --- a/doc/user_manual.md
> +++ b/doc/user_manual.md
> @@ -540,6 +540,7 @@ Currently, the following image types are provided:
>   - `wic` - full disk image with user-specified partitions created and populated using the wic tool
>   - `ubi` - image for use on mtd nand partitions employing UBI
>   - `ubifs` - raw UBI filesystem image, normally used together with UBI partitions
> + - `vmdk` - virtual machine disk image
>   - `ova` - Open Virtual Appliance: image for use on VirtualBox or VMware
>   - `wsl` - tar file for Windows Subsystem for Linux
>   - `squashfs` - raw squashfs filesystem image
> diff --git a/meta/classes-recipe/imagetypes_vm.bbclass b/meta/classes-recipe/imagetypes_vm.bbclass
> index fd4e97ed..b1be5605 100644
> --- a/meta/classes-recipe/imagetypes_vm.bbclass
> +++ b/meta/classes-recipe/imagetypes_vm.bbclass
> @@ -8,9 +8,13 @@ FILESEXTRAPATHS:prepend = "${LAYERDIR_core}/recipes-core/images:"
>  OVF_TEMPLATE_FILE ?= "virtualbox/vm-img-virtualbox.ovf.tmpl"
>  IMAGE_SRC_URI:ova = "file://${OVF_TEMPLATE_FILE}"
>  
> -IMAGE_TYPEDEP:ova = "wic"
> +IMAGE_TYPEDEP:ova = "${@bb.utils.contains('IMAGE_FSTYPES', 'vmdk', 'vmdk', 'wic', d)}"

This manually models the imagetypes logic. Can't we just make the vmdk
a proper imagetype and let the internal logic defer what is removed and
what is kept?

The current implementation interferes with that.

Felix

>  IMAGER_INSTALL:ova += "qemu-utils gawk uuid-runtime"
>  
> +IMAGE_TYPEDEP:vmdk = "wic"
> +IMAGER_INSTALL:vmdk += "qemu-utils"
> +IMAGE_CMD:vmdk = "${convert_wic}"
> +
>  # virtual machine disk settings
>  SOURCE_IMAGE_FILE ?= "${IMAGE_FULLNAME}.wic"
>  
> @@ -19,7 +23,9 @@ SOURCE_IMAGE_FILE ?= "${IMAGE_FULLNAME}.wic"
>  VMDK_SUBFORMAT ?= "monolithicSparse"
>  
>  VIRTUAL_MACHINE_IMAGE_TYPE ?= "vmdk"
> -VIRTUAL_MACHINE_IMAGE_FILE = "${IMAGE_FULLNAME}-disk001.${VIRTUAL_MACHINE_IMAGE_TYPE}"
> +VIRTUAL_MACHINE_IMAGE_FILE = "${IMAGE_FULLNAME}${@bb.utils.contains('IMAGE_FSTYPES', 'vmdk', '', '-disk001', d)}.${VIRTUAL_MACHINE_IMAGE_TYPE}"
> +VIRTUAL_MACHINE_IMAGE_TYPE:vmdk = "vmdk"
> +VIRTUAL_MACHINE_IMAGE_FILE:vmdk = "${IMAGE_FULLNAME}.vmdk"
>  VIRTUAL_MACHINE_DISK = "${PP_DEPLOY}/${VIRTUAL_MACHINE_IMAGE_FILE}"
>  
>  def set_convert_options(d):
> @@ -66,7 +72,7 @@ OVA_VARS = "OVA_NAME OVA_MEMORY OVA_NUMBER_OF_CPU OVA_VRAM \
>  IMAGE_TEMPLATE_FILES:ova = "${OVF_TEMPLATE_FILE}"
>  IMAGE_TEMPLATE_VARS:ova = "${OVA_VARS}"
>  
> -do_image_ova[prefuncs] += "convert_wic"
> +do_image_ova[prefuncs] += "${@bb.utils.contains('IMAGE_FSTYPES', 'vmdk', '', 'convert_wic', d)}"
>  IMAGE_CMD:ova() {
>      if [ ! ${VIRTUAL_MACHINE_IMAGE_TYPE} = "vmdk" ]; then
>          exit 0
> @@ -96,7 +102,9 @@ IMAGE_CMD:ova() {
>          tar -uvf ${PP_DEPLOY}/${IMAGE_FULLNAME}.ova -C ${PP_DEPLOY} ${VIRTUAL_MACHINE_IMAGE_FILE}
>          rm -f '${DEPLOY_DIR_IMAGE}/${IMAGE_FULLNAME}.mf'
>          rm -f '${DEPLOY_DIR_IMAGE}/${IMAGE_FULLNAME}.ovf'
> -        rm -f '${DEPLOY_DIR_IMAGE}/${VIRTUAL_MACHINE_IMAGE_FILE}'
> +        if [ "${@bb.utils.contains('IMAGE_FSTYPES', 'vmdk', '1', '0', d)}" = "0" ]; then
> +            rm -f '${DEPLOY_DIR_IMAGE}/${VIRTUAL_MACHINE_IMAGE_FILE}'
> +        fi
>  EOIMAGER
>  }
>  IMAGE_CMD:ova[depends] = "${PN}:do_transform_template"
> -- 
> 2.56.0
> 
> -- 
> You received this message because you are subscribed to the Google Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/isar-users/20261030115757.25391-1-clara.kowalsky%40siemens.com.

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/ae9f0b02d436d8fcfe9d4ae80ecae7d39877dac6.camel%40siemens.com.

  reply	other threads:[~2026-10-30 12:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30 11:57 'Clara Kowalsky' via isar-users
2026-10-30 12:27 ` 'Moessbauer, Felix' via isar-users [this message]
2026-11-03 12:29   ` 'Clara Kowalsky' via isar-users

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae9f0b02d436d8fcfe9d4ae80ecae7d39877dac6.camel@siemens.com \
    --to=isar-users@googlegroups.com \
    --cc=clara.kowalsky@siemens.com \
    --cc=felix.moessbauer@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox