On 30/04/15 17:49, Eric Blake wrote:
On 04/30/2015 12:28 AM, NoxDaFox wrote:
Sorry for the lack of information, my bad.
Also, we tend to avoid top-posting on technical lists. Sorry again.
The snapshot is an internal one and the machine is running.
The whole thing was set-up by another person and left to me to cope with. The typo is mine, as the machine is isolated I cannot actually copy-paste it so have to do it in the traditional way. I know the feeling :)
I am aware of the issue which come when changing HW but I couldn't do otherwise.
I am only interested in reverting the disk's state. I guess qemu-img can deal with it that but can libvirt as well? qemu-img can be used to extract the internal snapshot disk state into a standalone file. The problem is that reverting to an internal snapshot is only possible if you provide a qemu command line compatible with when the snapshot was taken, but qemu doesn't store that information itself. So it is up to libvirt to store the information, but libvirt refuses to allow changes to a snapshot where the guest ABI would be different, at least if the snapshot was tied to a running guest state. I eventually extracted the state in a standalone file. As said, I just needed to revert the disk state. A newly created machine with compatible CPU was created and everything went smooth. I was expecting the guest OS to complain (Windows asking to register the key again) but luckily it seemed it liked the CPU.
What puzzled me was the error output which is kinda misleading. Yeah, I'm not sure why you got that particular error, but I'm worried that what you are trying to do won't work through libvirt API, so you'll end up having to do a backdoor approach anyways in order to revert to the state but with a different guest hardware description. Point was the misleading sentence "<snapshot_name> already exist" which is kinda funny as it's hard to edit a non existing one.
Is it so that libvirt prevents editing snapshot configuration when running? No, libvirt should allow snapshot edits regardless of current state and regardless of the state captured in the snapshot, but only as long as the edits don't change the guest ABI.
Is it due to the fact that the snapshots are internal? You'd get the same restrictions on editing machine ABI on external snapshots. It's just that external snapshots are a bit easier to forcefully revert to by editing <domain> xml, rather than trying to change the snapshot in place. Clear.
It may also be possible to capture the snapshot xml (virsh snapshot-dumpxml $dom $name > $file'), then have libvirt forget about it ('virsh snapshot-delete --metadata $dom $name'), then edit the xml and redefine the snapshot ('virsh snapshot-create --redefine $dom $file'), where the redefined domain is not strictly ABI compatible, but where libvirt no longer has the information on hand to reject the redefinition as invalid. Didn't try this one as it sounded scary.
Anyway, I manage to solve my issue. Thank you very much!