On Wed, 2017-03-29 at 08:44 -0500, Robert Nichols wrote:
> On 03/29/2017 06:02 AM, Patrick O'Callaghan wrote:
> > On Tue, 2017-03-28 at 18:16 -0500, Robert Nichols wrote:
> > > Did you really run the VM from the file in /home/poc/Win10/ ? It would be unusual to run a VM from a file in your home directory and not from one in the /var/lib/libvirt/images/ directory. Check the modification times on the files. If /home/poc/Win10/win10.qcow2 really has changed, then the /var/lib/libvirt/images/Windows10.qcow2 file is pretty much worthless.
> >
> > In fact the /var/lib/libvirt/images file is timestamped as later than
> > the .../Win10/win10.gcow2 file, so I think you're right.
> >
> > > If you want to test that backing file, create _another_ file using /home/poc/Win10/win10.qcow2 as a backing file and see if that new file can run or be made to run. You can do that safely and know that the backing file is not being affected.
> >
> > Do you with "qemu-img create -b ..." or with "qemu-img snapshot -c
> > ..."? I'm not clear on the difference and the man page is anything but
> > clear.
>
> "Backing file" implies "qemu-img create -b ...". I agree that the manpage is horribly unclear. The snapshots from "qemu-img snapshot {-c|-a|-d}" are not separate files. They are maintained _within_ that single image file. The two constructs are very different.
>
> A backing file can have multiple dependent images, and all can be active simultaneously. That setup is typically used when you want to have multiple independent Windows 10 VMs (for example) all running simultaneously, probably for different users. It's like having separate copies of the base image, but each VM only uses disk space to record the _differences_ from that backing file. That backing file can never be changed while any dependent image exists, so the way it might be handled would be to create the dependent image anew when the user connects and give that user persistent storage elsewhere.
>
> A qemu-img snapshot, OTOH, maintains a record of the state the base image was in at a point in time. A snapshot is _never_ "active" and cannot be written to. There can be multiple snapshots, each representing what was in the base image at the time the snapshot was created. It is like having read-only copies of the base image, but with each needing only enough disk space for the information needed to undo whatever changes occurred in the base image since the snapshot was created. The only way to access the content of a snapshot is to run "qemu-img snapshot -a ...", which is saying, "Make the base image look like it was when this snapshot was created."
>
> It can be quite hard to understand until you have played with it for a bit. Note that LVM snapshots are a third variant, and are quite different from either of the above. With LVM snapshots, both the base and the snapshot can be simultaneously active read/write, with the snapshot keeping track of the differences.
>
OK, I think I get the idea. The manpage is not only unclear, it's
actually inconsistent with what you say. There is no mention of a '-b'
option to 'create'. The --help option doesn't say anything about it
either, but I tried it and it works.
My overall impression of the whole KVM/QEMU/libvirtd shebang is that
it's great technology that seriously needs someone to document it
properly. I've used VMware and VirtualBox with nothing like as much
trouble, but of course they don't offer the same flexibility.
OK, once I've created the backing file, how do I use it? I've been
running virt-manager for everything but it's not clear how to do this.
Do I need to run qemu-kvm from the command line?
poc
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
