[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 9/9] docs: Start documenting VM templating
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH v2 9/9] docs: Start documenting VM templating |
Date: |
Tue, 22 Aug 2023 14:47:16 +0100 |
User-agent: |
Mutt/2.2.9 (2022-11-12) |
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 :|
- Re: [PATCH v2 3/9] backends/hostmem-file: Add "rom" property to support VM templating with R/O files, (continued)
[PATCH v2 6/9] softmmu/physmem: Fail creation of new files in file_ram_open() with readonly=true, David Hildenbrand, 2023/08/22
[PATCH v2 5/9] softmmu/physmem: Bail out early in ram_block_discard_range() with readonly files, David Hildenbrand, 2023/08/22
[PATCH v2 7/9] softmmu/physmem: Never return directories from file_ram_open(), David Hildenbrand, 2023/08/22
[PATCH v2 8/9] docs: Don't mention "-mem-path" in multi-process.rst, David Hildenbrand, 2023/08/22
[PATCH v2 9/9] docs: Start documenting VM templating, David Hildenbrand, 2023/08/22