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 <da...@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 :|
