[broadened subject line and added relevant parties to cc list] On Tue, Sep 17, 2024 at 10:55:20PM +0200, Alexander Graf wrote: > What is still open are user space applications that require event based > notification on VM clone events - and *only* VM clone events. This > mostly caters for tools like systemd which need to execute policy - such > as generating randomly generated MAC addresses - in the event a VM was > cloned. > > That's the use case this patch "vmgenid: emit uevent when VMGENID > updates" is about and I think the best path forward is to just revert > the revert. A uevent from the device driver is a well established, well > fitting Linux mechanism for that type of notification.
The thing that worries me is that vmgenid is just some weird random microsoft acpi driver. It's one sort of particular device, and not a very good one at that. There's still room for virtio/qemu to improve on it with their own thing, or for vbox or whatever else to have their version, and xen theirs, and so forth. That is to say, I'm not sure that this virtual hardware is *the* way of doing it. Even in terms of the entropy stuff (which I know you no longer care about, but I do), mst's original virtio-rng draft mentioned reporting events beyond just VM forks, extending it generically to any kind of entropy reduction situation. For example, migration or suspend or whatever might be interesting things to trigger. Heck, one could imagine those coming through vmgenid at some point, which would then change the semantics you're after for systemd. Even in terms of reporting exclusively about external VM events, there's a subtle thing to consider between clones/forks and rollbacks, as well as migrations. Vmgenid kind of lumps it all together, and hopefully the hypervisor notifies in a way consistent with what userspace was hoping to learn about. (Right now, maybe we're doing what Hyper-V does, maybe, but also maybe not; it's kind of loose.) So at some point, there's a question about the limitations of vmgenid and the possible extensions of it, or whether this will come in a different driver or virtual hardware, and how. Right now, this is mostly unexplored. The virtio-rng avenue was largest step in terms of exploring this problem space, but there are obviously a few directions to go, depending on what your primary concern is. But all of that makes me think that exposing the particulars of this virtual hardware driver to userspace is not the best option, or at least not an option to rush into (or to trick Greg into), and will both limit what we can do with it later, and potentially burden userspace with having to check multiple different things with confusing interactions down the road. So I think it's worth stepping back a bit and thinking about what we actually want from this and what those semantics should be. I'd also love to hear from the QEMU guys on this and get their input. To that end, I've added qemu and virtio mailing lists, as well as mst. Also, I'd be interested to learn specifically what you (Amazon) want this for and what the larger picture there is. I get the systemd case, but I'm under the assumption you've got a different project in your woods. Jason
