Often we use the same two or three resources to perform an action, for example to setup an application (install a package, manage a configuration file, and start a service).
We can used Defined Resources to avoid repeating the same blocks of code (ie package, file, service resources).

Here I have created a module file that has a Defined Resource called add:service that uses three resources - /etc/puppetlabs/code/environments/production/modules/add/manifests/service.pp

define add::service (
  String $package = $title,
  String $service,
  String $config,
) {
  package { $package:
    ensure => 'installed',
    before => File[$config]
  }
  file { $config:
    ensure => present,
    notify => Service[$service],
    require => Package[$package],
  }
  service { $service:
    ensure    => 'running',
    subscribe => File[$config],
  }
}

Here is the contents of site.pp where I call the Defined Resource.  The title of the resource call (ie ntp, openssh-server, yum-cron) is read by the Defined Resources as $title to ensure that contained resources are unique.

node 'somebox.local' {
  add::service { 
    'ntp'            : service => 'ntpd',     config  => '/etc/ntp.conf';
    'openssh-server' : service => 'sshd',     config  => '/etc/ssh/sshd_config';
    'yum-cron'       : service => 'yum-cron', config  => '/etc/yum/yum-cron.conf';
  }
}

I have run this code in my home environment and successfully managed these three services.  It seems like an efficient way to perform a repetitive action.

I also had a go at leveraging functionality from another module, in this case firewalld.  By running the below code in my dev environment I was able to add firewalld rules.
This could have been added to the add::service Defined Resource, but I created a new add::firewall one - /etc/puppetlabs/code/environments/production/modules/add/manifests/firewall.pp

define add::firewall (
  String  $rule = $title,
  String  $ensure,
  String  $zone,
  String  $sourceip,
  Integer $port,
  String  $protocol,
  String  $action,
) {
  firewalld_rich_rule { $rule:
    ensure       => $ensure,
    zone         => $zone,
    source       => $sourceip,
    port         => {
      'port'     => $port,
      'protocol' => $protocol,
    },
    action       => $action,
  }
}

My site.pp where I call the Defined Resource and include the Firewalld class reference. Note, if you call the firewalld class in the Defined Resource you get duplicate resource declarations when you add more than one rule.

node 'default' {
  class { 'firewalld': }
  add::firewall {
    'NTP 123 UDP incoming' : ensure => 'present', zone => 'public', sourceip => '10.10.10.0/24', port => 123, protocol => 'udp', action => 'accept';
    'SSH 22 TCP incoming'  : ensure => 'present', zone => 'public', sourceip => '192.168.1.0/24', port => 22, protocol => 'tcp', action => 'accept';
  }
}

KubeVirt leverages KVM and QEMU to run VMs inside the context of a pod.

Many business who have/want to move to containers will still have VMs due to them running legacy applications that can't be lift and shifted into a container due to:
* technical reasons such as older operating systems or kernel versions.
* business reasons such as time to market and the cost of conversion.

KubeVirt can be used to:
* import these VMs into a pod (APP1).
* migrate some of the application's services into containers, whilst keeping the legacy services on a VM (APP2).

Source RedHat

This provides a transition path for users with VMs running legacy applications that may only end up being partly containerised, or not containserised at all.

The advantages of this migration path are:
* applications that reside across containers and/or VMs are deployed in a common shared environment.
* once all VMs have been migrated to the new platform, the VM platform can be decomissioned.

Note, KubeVirt should be installed on baremetal, not on a VM (VM running in a container on a VM lol).

Short Explanation (KubeVirt)
Short Explanation from Redhat regarding Native Virtualization (CNV). RedHat's downstream project of KubeVirt which seems to be currently in a technical preview form.
Long Explanation (KubeVirt)
Further KubeVirt reading