All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Peter Xu" <peterx@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Thiner Logoer" <logoerthiner1@163.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Elena Ufimtseva" <elena.ufimtseva@oracle.com>,
	"Jagannathan Raman" <jag.raman@oracle.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Ani Sinha" <anisinha@redhat.com>,
	"Xiao Guangrong" <xiaoguangrong.eric@gmail.com>,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>,
	"Greg Kurz" <groug@kaod.org>, "Eric Blake" <eblake@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>
Subject: Re: [PATCH v2 9/9] docs: Start documenting VM templating
Date: Tue, 22 Aug 2023 14:47:16 +0100	[thread overview]
Message-ID: <ZOS8ZNaRrcrNNNOe@redhat.com> (raw)
In-Reply-To: <20230822114504.239505-10-david@redhat.com>

On Tue, Aug 22, 2023 at 01:44:57PM +0200, David Hildenbrand wrote:
> Let's add some details about VM templating, focusing on the VM memory
> configuration only.
> 
> There is much more to VM templating (VM state? block devices?), but I leave
> that as future work.

Then there's the supposedly "unique" hardware identifiers, most notably
VM UUID & NIC MAC addr that don't change if you create many VMs from
a "template". Or from the guest OS there are "unique" things like
/etc/machine-id, SSH host keys, web server certificates, etc.

The vmgenid device at least provides a way for guest OS to get notified
to update its unique resources/identifiers, but doesn't solve the overall
VM UUID. NIC MAC addr could be solved by hotunplug+plug either side of
creating the template & instantiating the template.

> 
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  docs/vm-templating.txt | 109 +++++++++++++++++++++++++++++++++++++++++

Can you make this doument RST from the start and link to it from
somewhere appropriate in our documentation. Perhaps it should live
under the docs/system/ directory ?

>  1 file changed, 109 insertions(+)
>  create mode 100644 docs/vm-templating.txt
> 
> diff --git a/docs/vm-templating.txt b/docs/vm-templating.txt
> new file mode 100644
> index 0000000000..419362c1ea
> --- /dev/null
> +++ b/docs/vm-templating.txt
> @@ -0,0 +1,109 @@
> +QEMU VM templating
> +==================
> +
> +This document explains how to use VM templating in QEMU.
> +
> +For now, the focus is on VM memory aspects, and not about how to save and
> +restore other VM state (i.e., migrate-to-file with 'x-ignore-shared').
> +
> +Overview
> +--------
> +
> +With VM templating, a single template VM serves as the starting point for
> +new VMs. This allows for fast and efficient replication of VMs, resulting
> +in fast startup times and reduced memory consumption.
> +
> +Conceptually, the VM state is frozen, to then be used as a basis for new
> +VMs. The Copy-On-Write mechanism in the operating systems makes
> +sure that new VMs are able to read template VM memory; however, any
> +modifications stay private and don't modify the original template VM or any
> +other created VM.

I feel like we should have a paragraph at the top here explicitly calling
out the dangers of templating, wrt to unique data in the hardware and guest
OS. Don't have to provide solutions, just more of a scarcy "here be dragons"
warning to users who might be tempted to try this.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2023-08-22 13:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-22 11:44 [PATCH v2 0/9] memory-backend-file related improvements and VM templating support David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 1/9] nvdimm: Reject writing label data to ROM instead of crashing QEMU David Hildenbrand
2023-08-22 19:25   ` Stefan Hajnoczi
2023-08-22 11:44 ` [PATCH v2 2/9] softmmu/physmem: Distinguish between file access mode and mmap protection David Hildenbrand
2023-08-22 13:13   ` ThinerLogoer
2023-08-22 13:25     ` [PATCH " David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 3/9] backends/hostmem-file: Add "rom" property to support VM templating with R/O files David Hildenbrand
2023-08-22 13:27   ` Markus Armbruster
2023-08-22 13:29     ` David Hildenbrand
2023-08-22 14:26   ` ThinerLogoer
2023-08-23 12:43     ` [PATCH " David Hildenbrand
2023-08-23 14:47       ` ThinerLogoer
2023-08-23 14:59         ` David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 4/9] softmmu/physmem: Remap with proper protection in qemu_ram_remap() David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 5/9] softmmu/physmem: Bail out early in ram_block_discard_range() with readonly files David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 6/9] softmmu/physmem: Fail creation of new files in file_ram_open() with readonly=true David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 7/9] softmmu/physmem: Never return directories from file_ram_open() David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 8/9] docs: Don't mention "-mem-path" in multi-process.rst David Hildenbrand
2023-08-22 13:21   ` ThinerLogoer
2023-08-22 13:24     ` [PATCH " David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 9/9] docs: Start documenting VM templating David Hildenbrand
2023-08-22 13:47   ` Daniel P. Berrangé [this message]
2023-08-22 14:04     ` David Hildenbrand
2023-08-22 14:23   ` Peter Maydell
2023-08-22 14:31     ` David Hildenbrand

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=ZOS8ZNaRrcrNNNOe@redhat.com \
    --to=berrange@redhat.com \
    --cc=anisinha@redhat.com \
    --cc=armbru@redhat.com \
    --cc=danielhb413@gmail.com \
    --cc=david@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=elena.ufimtseva@oracle.com \
    --cc=groug@kaod.org \
    --cc=imammedo@redhat.com \
    --cc=jag.raman@oracle.com \
    --cc=logoerthiner1@163.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=xiaoguangrong.eric@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.