On Thu, Feb 24, 2022 at 09:22:50AM +0100, Laszlo Ersek wrote: > (+Daniel, +Rich) > > On 02/23/22 17:08, Jason A. Donenfeld wrote: > > On Wed, Feb 23, 2022 at 2:12 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > >> second patch is the reason this is just an RFC: it's a cleanup of the > >> ACPI driver from last year, and I don't really have much experience > >> writing, testing, debugging, or maintaining these types of drivers. > >> Ideally this thread would yield somebody saying, "I see the intent of > >> this; I'm happy to take over ownership of this part." That way, I can > >> focus on the RNG part, and whoever steps up for the paravirt ACPI part > >> can focus on that. > > > (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." IIRC this part of the QEMU doc was making an implicit assumption about the way QEMU is to be used by mgmt apps doing snapshots. Instead of using the 'loadvm' command on the existing running QEMU process, the doc seems to tacitly expect the management app will throwaway the existing QEMU process and spawn a brand new QEMU process to load the snapshot into, thus getting the new GUID on the QEMU command line. There are some downsides with doing this as compared to running 'loadvm' in the existing QEMU, most notably the user's VNC/SPICE console session gets interrupted. I guess the ease of impl for QEMU was more compelling though. 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 :|
