On Wed, Mar 21, 2018 at 08:19:46AM +0100, Peter Krempa wrote: > On Tue, Mar 20, 2018 at 18:55:44 -0400, John Ferlan wrote: > > Add VM Generation ID device XML schema, parse, format, and documentation. > > > > Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> > > --- > > docs/formatdomain.html.in | 54 ++++++++++++++ > > docs/schemas/domaincommon.rng | 21 ++++++ > > src/conf/domain_conf.c | 112 +++++++++++++++++++++++++++++- > > src/conf/domain_conf.h | 11 +++ > > tests/qemuxml2argvdata/vmgenid-auto.xml | 32 +++++++++ > > tests/qemuxml2argvdata/vmgenid.xml | 32 +++++++++ > > tests/qemuxml2xmloutdata/vmgenid-auto.xml | 1 + > > tests/qemuxml2xmloutdata/vmgenid.xml | 1 + > > tests/qemuxml2xmltest.c | 3 + > > 9 files changed, 266 insertions(+), 1 deletion(-) > > create mode 100644 tests/qemuxml2argvdata/vmgenid-auto.xml > > create mode 100644 tests/qemuxml2argvdata/vmgenid.xml > > create mode 120000 tests/qemuxml2xmloutdata/vmgenid-auto.xml > > create mode 120000 tests/qemuxml2xmloutdata/vmgenid.xml > > > > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > > index 6fd2189cd2..895e51b343 100644 > > --- a/docs/formatdomain.html.in > > +++ b/docs/formatdomain.html.in > > @@ -8027,6 +8027,60 @@ qemu-kvm -net nic,model=? /dev/null > > </dd> > > </dl> > > > > + <h4><a id="elementsVmgenid">VM Generation ID device</a></h4> > > + > > + <p> > > + <span class="since">Since 4.2.0</span>, the <code>vmgenid</code> > > + element can be used to add a Virtual Machine Generation ID device. > > + A <code>vmgenid</code> device is an emulated device which exposes > > + a 128-bit, cryptographically random, integer value identifier, > > + referred to as a Globally Unique Identifier, or GUID. The value is > > + stored within the virtual machine's BIOS so that programs running in > > According to the qemu docs, it's stored in the ACPI table, so it does > not depend on BIOS being used. EFI can be used as well. Yes, it is part of ACPI blob exposed to the guest > > + the virtual machine executes from a different configuration file such > > + as executing from a recovered snapshot or executing after restoring > > Okay. From this it seems that the GUID should change where the VM state > could be reverted to a point in history of the execution of the guest > software. This basically means that it should be always left to > autogenerating except in cases of migration where the new qemu process > needs to continue to use the old GUID. > > This means that you'll need to query it if 'auto' is specified and qemu > does not guarantee that it's properly transported in the migration > stream. On the other hand, if it is transported in the migration stream, > then save/restore and reversion of external snapshots with memory will > be fun, since that uses the migration code. All ACPI state is maintained by QEMU across migration - so regardless of what CLI args are given, the vmgenid won't change during migration. For sanity sake though, we should likely make sure the CLI args given the matching version on target, otherwise we'll get seriously confused when debugging. > > + from backup. Programs running in a virtual machine can protect themselves > > + from potential corruption by checking that the generation ID has not > > + changed immediately prior to committing a transaction, they can also > > + use the data provided in the 128-bit identifier as a high entropy > > + random data source. > > Whoah. The qemu docs don't speak about entropy source. Is it described > in the Microsoft documentation? In any case, if the GUID is going to be > used as an entropy source, we need to approach it way more carefully. > Especially don't report it to unauthorized eyes. I'd be very happy if > will not have to keep it secret. This will get especially tricky since > there will be cases where we'll need to put it on the command line > (either on migration or on save/restore). > > > + </p> > > + > > + <p> > > + Example: > > + </p> > > +<pre> > > +... > > +<devices> > > + <vmgenid guid='3e3fce45-4f53-4fa7-bb32-11f34168b82b'/> > > So I think we should use a more generic element with 'vmgenid' as a > model. It looks like this is one of possible implementations of such a > thing and it's fully possible to emulate a PCI device or anything else > with similar semantics. I tend to thing we should *not* represent this as a device at all. This is essentially equivalent to the global <uuid> field we have already, except that in a handful of situations it can change. IOW I think we should just have <genid>.....</genid> in the XML alongside the <uuid>. An empty <genid/> element can be used to request that the feature be enabled, and we should automatically replace the previous value when required - I don't see a compelling reason to use a magic string "auto" - it should always be automatic. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
