Hi Lazlo, Thanks for your reply. On Thu, Feb 24, 2022 at 9:23 AM Laszlo Ersek <lersek@xxxxxxxxxx> wrote: > QEMU's related design is documented in > <https://git.qemu.org/?p=qemu.git;a=blob;f=docs/specs/vmgenid.txt>. I'll link to this document on the 2/2 patch next to the other ones. > "they can also use the data provided in the 128-bit identifier as a high > entropy random data source" > > So reinitializing an RNG from it is an express purpose. It seems like this is indeed meant to be used for RNG purposes, but the Windows 10 RNG document says: "Windows 10 on a Hyper-V VM will detect when the VM state is reset, retrieve a unique (not random) value from the hypervisor." I gather from that that it's not totally clear what the "quality" of those 128 bits are. So this patchset mixes them into the entropy pool, but does not credit it, which is consistent with how the RNG deals with other data where the conclusion is, "probably pretty good but maybe not," erring on the side of caution. Either way, it's certainly being used -- and combined with what was there before -- to reinitialize the RNG following a VM fork. > > More info in the libvirt docs (see "genid"): > > https://libvirt.org/formatdomain.html#general-metadata Thanks, noted in the 2/2 patch too. > QEMU's interpretation of the VMGENID specifically as a UUID (which I > believe comes from me) has received (valid) criticism since: > > https://github.com/libguestfs/virt-v2v/blob/master/docs/vm-generation-id-across-hypervisors.txt > > (This document also investigates VMGENID on other hypervisors, which I > think pertains to your other message.) Thank you very much for this reference! You're absolutely right here. v3 will treat this as just an opaque 128-bit binary blob. There's no point, anyway, in treating it as a UUID in the kernel, since it never should be printed or exposed to anywhere except random.c (and my gifs, of course :-P). > > > (It appears there's a bug in QEMU which prevents > > the GUID from being reinitialized when running `loadvm` without > > quitting first; I suppose this should be discussed with QEMU > > upstream.) > > That's not (necessarily) a bug; see the end of the above-linked QEMU > document: > > "There are no known use cases for changing the GUID once QEMU is > running, and adding this capability would greatly increase the complexity." I read that, and I think I might disagree? If you're QEMUing with the monitor and are jumping back and forth and all around between saved snapshots, probably those snapshots should have their RNG reinitialized through this mechanism, right? It seems like doing that would be the proper behavior for `guid=auto`, but not for `guid={some-fixed-thing}`. > > So that's very positive. But I would appreciate hearing from some > > ACPI/Virt/Amazon people about this. > > I've only made some random comments; I didn't see a question so I > couldn't attempt to answer :) "Am I on the right track," I guess, and your reply has been very informative. Thanks for your feedback. I'll have a v3 sent out not before long. Jason
