Greetings, due to hardware failure I had to replace my workstation which has a different CPU. I have a VM with several snapshots and I need to revert to a specific one.

While reverting to it, I get an error due to unsupported CPU features.

Therefore, I try to edit the snapshot XML through the command: virsh snapshot-edit <domain_name> <snapshot_name> When I save the changes I get the error message: error: intermal error: unexpected domain snapshot <snapshot_name> already exists Tried to look around for solution but didn't find any information related to my problem. Am I doing something wrong? It's quite critical for me to be able to revert to that state of the machine. Is there any chance to do so via libvirt?

On 04/29/2015 01:08 AM, NoxDaFox wrote: > Greetings, > > due to hardware failure I had to replace my workstation which has a > different CPU. I have a VM with several snapshots and I need to revert to a > specific one. > > While reverting to it, I get an error due to unsupported CPU features. > Therefore, I try to edit the snapshot XML through the command: > > virsh snapshot-edit <domain_name> <snapshot_name> > > When I save the changes I get the error message: > error: intermal error: unexpected domain snapshot <snapshot_name> already I hope that typo "intermal" is just a copy-paste bug on your part, and not in the source code. > exists > > Tried to look around for solution but didn't find any information related > to my problem. > > Am I doing something wrong? It's quite critical for me to be able to revert > to that state of the machine. Is there any chance to do so via libvirt? Changing the CPU features is guest visible. Generally, it is a bad idea to change what hardware a guest sees (particularly if the guest was already running as it may crash apps in the guest, but also even if the guest is offline but is a picky OS like Windows that requires revalidation), so even if you can get virsh snapshot-edit to work, I doubt libvirt will let you use it to change CPU features. Is your snapshot from a running guest state, or offline? If offline, just edit the <domain> to point to the correct disk state at the same time you remove the CPU features, to get a fresh boot, rather than trying to revert to the snapshot state. Also, is your snapshot internal or external? Depending on how the snapshot was created may affect how to alter the <domain> to point at the desired disk state. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

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.

> 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.

> 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.

> 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.

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.