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!
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
