As far as I can tell, virsh snapshots contain enough information to create new VM from the snapshot (RAM and disk are saved). When cloning from snapshot, we would get same results as we would when reverting to a snapshot, but in a new VM. Main benefit would be easy backups. We could just take snapshot and save it externally with ability to restore to it at any time. Hope it's clear what the intention is behind this RFE. I would gladly provide more information if needed.
It almost sounds like you are asking for a way to clone a new live VM from a snapshot of an existing live VM, while leaving the existing VM running. This is extremely dangerous, as having two distinct VMs running at the same time, but sharing resources such as hostname, entropy pool, network connections, ... from the point in time where the snapshot was created, will create chaos if not security holes. Cloning a new VM is best done on an offline VM, through specialized tools such as virt-sysprep, which handle all the implications of scrubbing the new VM to be distinct enough from the original. If you are NOT asking for two parallel VMs, then you are merely asking for a way to revert back to the state recorded in a snapshot, but then you don't need a new VM. And yes, being able to revert to a snapshot is a desirable property of any snapshot system (the fact that libvirt can currently do it for internal snapshots but not for external snapshots is a deficiency, already tracked in other bug reports). At any rate, the act of properly cloning a VM (particularly a live one) involves too much knowledge about the contents of the guest being cloned, so that libvirt will never do that (rather, it's a task for tools higher in the stack, like virt-sysprep).
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.