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_will_not_let_me_delete_or_revert_to_it
> > 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-current-active-disk
> > 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
