Re: [libvirt] [Qemu-devel] Question regarding Snapshots
On Wed, Feb 22, 2017 at 03:06:41PM -0600, Tim Cusack wrote:
I have a scenario that perhaps not many have attempted, but I still hope that it is possible.
Scenario:
I would like to have a Base Windows 7 VM in KVM/QEMU.
I would follow the following process (confirmed it works)
1. Shutdown running domain - virsh shutdown <Domain> 2. Remove existing disk from Domain XML: - virt-xml BASE --remove-device --disk target=hda 3. Add Correct Disk image for Snapshot to Domain XML: - virt-xml BASE --add-device --disk /var/lib/libvirt/images/BASE.qcow2,format=qcow2,target=hda,bus=ide 4. Create the snapshot with description - virsh snapshot-create-as BASE <Model>.qcow2 "OEM, Model" --disk-only --atomic 5. Start Snapshot - virsh start FA2BASE
This process uses libvirt instead of QEMU commands. Adding libvirt mailing list.
All that works, but my question and issue is this:
Can you make a snapshot, then go back to the base and ignore that snapshot like a closed branch, make another snapshot, and then go back and forth from each to each?
My reasons for needing this are that I have tools and software that doesnt play nice together, and would like to keep them separated on different snapshots, but never really need to have more than one up at a time.
This would allow me to have only 1 windows license per computer, and the ability to just change from tool to tool with simple front end to virsh to remove the disk from the .xml and add the other one.
So like this: Tool A is on snapshot A Tool B is on snapshot B go through steps 1-5 above to go back and forth.
I know that I can not merge things back into the base, but I really don't need to do that, in fact, I can throw away the tool snapshots when new tools come out, by making new snapshots from the base when new tools come out.
We have done this already, but we had an issue where the ability to write to the snapshots seemed to stop.
Reason unknown, everything worked one day and next could not write to any snapshot, but could still load the base and work on it fine.
This might be the wrong mailing list to post to, if so, could anyone point out a more appropriate one?
Tim
On Mon, Feb 27, 2017 at 11:01:06AM +0000, Stefan Hajnoczi wrote:
On Wed, Feb 22, 2017 at 03:06:41PM -0600, Tim Cusack wrote:
I have a scenario that perhaps not many have attempted, but I still hope that it is possible.
Scenario:
I would like to have a Base Windows 7 VM in KVM/QEMU.
I would follow the following process (confirmed it works)
1. Shutdown running domain - virsh shutdown <Domain> 2. Remove existing disk from Domain XML: - virt-xml BASE --remove-device --disk target=hda 3. Add Correct Disk image for Snapshot to Domain XML: - virt-xml BASE --add-device --disk /var/lib/libvirt/images/BASE.qcow2,format=qcow2,target=hda,bus=ide 4. Create the snapshot with description - virsh snapshot-create-as BASE <Model>.qcow2 "OEM, Model" --disk-only --atomic 5. Start Snapshot - virsh start FA2BASE
This process uses libvirt instead of QEMU commands. Adding libvirt mailing list.
All that works, but my question and issue is this:
Can you make a snapshot, then go back to the base and ignore that snapshot like a closed branch, make another snapshot, and then go back and forth from each to each?
If you edit the '--disk' element as above and point to the right 'snapshot', you should be able to switch between several of them. <digression> The correct term is 'overlay', let me quote Eric Blake, from his 2015 KVM Forum presentation ("Backing Chain Management" -- recommend it), where Eric warns about points in time vs. file names: Given the chain “A <- B <- C”, we have 2 points in time and an active layer: - Point 1: Guest state when B was created, contained in file A - Point 2: Guest state when C was created, contained in A+B - Active layer: Current guest state, contained in A+B+C Be careful with naming choices: Naming a file after the time it is created is misleading -- the guest data for that point in time is NOT contained in that file. Rather, think of files as a delta from the backing file.) </digression> And conveniently, you can tell libvirt to not track the metadata: $ virsh snapshot-create-as --domain vm1 guest-state1 \ --diskspec vda,file=/export/overlay1.qcow2 \ --disk-only --atomic --no-metadata This way, libvirt will not track 'overlay1.qcow2'. But if you do need it, as you know, just update the For the long answer to the complications involved in reverting to external snapshots, refer this (long read): https://wiki.libvirt.org/page/I_created_an_external_snapshot,_but_libvirt_wi...
My reasons for needing this are that I have tools and software that doesnt play nice together, and would like to keep them separated on different snapshots, but never really need to have more than one up at a time.
This would allow me to have only 1 windows license per computer, and the ability to just change from tool to tool with simple front end to virsh to remove the disk from the .xml and add the other one.
So like this: Tool A is on snapshot A Tool B is on snapshot B go through steps 1-5 above to go back and forth.
I know that I can not merge things back into the base,
How did you arrive at that conclusion? I realize you tell further below that you don't need it, but I should point out that it _is_ possible, if need be, to merge things into base: http://wiki.libvirt.org/page/Live-merge-an-entire-disk-image-chain-including...
but I really don't need to do that, in fact, I can throw away the tool snapshots when new tools come out, by making new snapshots from the base when new tools come out.
We have done this already, but we had an issue where the ability to write to the snapshots seemed to stop.
Without more details like libvirt logs (with QEMU log filters), hard to tell what's going on.
Reason unknown, everything worked one day and next could not write to any snapshot, but could still load the base and work on it fine.
This might be the wrong mailing list to post to, if so, could anyone point out a more appropriate one?
Tim
-- /kashyap
On Mon, Feb 27, 2017 at 01:33:56PM +0100, Kashyap Chamarthy wrote: [...]
Can you make a snapshot, then go back to the base and ignore that snapshot like a closed branch, make another snapshot, and then go back and forth from each to each?
If you edit the '--disk' element as above and point to the right 'snapshot', you should be able to switch between several of them.
[...]
And conveniently, you can tell libvirt to not track the metadata:
$ virsh snapshot-create-as --domain vm1 guest-state1 \ --diskspec vda,file=/export/overlay1.qcow2 \ --disk-only --atomic --no-metadata
This way, libvirt will not track 'overlay1.qcow2'. But if you do need it, as you know, just update the
Err, unfinished sentence there. Meant to write: just update the 'source file' attribute in the guest XML, pointing to the said disk.
For the long answer to the complications involved in reverting to external snapshots, refer this (long read):
https://wiki.libvirt.org/page/I_created_an_external_snapshot,_but_libvirt_wi...
[...] -- /kashyap
On 02/27/2017 07:17 AM, Kashyap Chamarthy wrote:
On Mon, Feb 27, 2017 at 01:33:56PM +0100, Kashyap Chamarthy wrote:
[...]
Can you make a snapshot, then go back to the base and ignore that snapshot like a closed branch, make another snapshot, and then go back and forth from each to each?
Yes. Or graphically, you can have: -- A ... B ... C / base < \ -- D ... E ... F and toggle between any of the named snapshots at will. As Kashyap and others pointed out, libvirt support for reverting to a particular external snapshot is not fully present, so there are some manual steps involved, but the task is still doable.
For the long answer to the complications involved in reverting to external snapshots, refer this (long read):
https://wiki.libvirt.org/page/I_created_an_external_snapshot,_but_libvirt_wi...
[...]
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (3)
-
Eric Blake -
Kashyap Chamarthy -
Stefan Hajnoczi