Sorry for the lack of information, my bad. 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 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? What puzzled me was the error output which is kinda misleading. Is it so that libvirt prevents editing snapshot configuration when running? Is it due to the fact that the snapshots are internal? Thank for the help. 2015-04-29 17:38 GMT+03:00 Eric Blake <eblake@redhat.com>:> 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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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!