5:01 a.m.
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
6:33 a.m.
New subject: [libvirt] [Qemu-devel] Question regarding Snapshots
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...
> 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-includ...
> 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
7:17 a.m.
New subject: [libvirt] [Qemu-devel] Question regarding Snapshots
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...
[...]
--
/kashyap
1:37 p.m.
New subject: [libvirt] [Qemu-devel] Question regarding Snapshots
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...
[...]
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
2860
days inactive
2860
days old
3 comments
3 participants
participants (3)
-
Eric Blake -
Kashyap Chamarthy -
Stefan Hajnoczi