I have a QEMU image snapshot:
$ sudo qemu-img info /var/lib/libvirt/images/Windows10.qcow2 image: /var/lib/libvirt/images/Windows10.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 backing file: /home/poc/Win10/win10.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false
However when I try to restore the virtual disk I get:
$ sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 /home/poc/Win10/win10.qcow2 qemu-img: Could not apply snapshot '/var/lib/libvirt/images/Windows10.qcow2': -2 (No such file or directory)
I must be doing something obviously wrong, but can't see what it is. Hints would be appreciated.
poc
On Mon, Mar 27, 2017 at 11:31 AM, Patrick O'Callaghan <pocallaghan@gmail.com
wrote:
I have a QEMU image snapshot:
$ sudo qemu-img info /var/lib/libvirt/images/Windows10.qcow2 image: /var/lib/libvirt/images/Windows10.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 backing file: /home/poc/Win10/win10.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false
However when I try to restore the virtual disk I get:
$ sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 /home/poc/Win10/win10.qcow2 qemu-img: Could not apply snapshot '/var/lib/libvirt/images/Windows10.qcow2': -2 (No such file or directory)
I must be doing something obviously wrong, but can't see what it is. Hints would be appreciated.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
You have all the required permissions I'm sure, yes?
On Mon, 2017-03-27 at 12:00 -0600, InvalidPath wrote:
On Mon, Mar 27, 2017 at 11:31 AM, Patrick O'Callaghan <pocallaghan@gmail.com
wrote: I have a QEMU image snapshot:
$ sudo qemu-img info /var/lib/libvirt/images/Windows10.qcow2 image: /var/lib/libvirt/images/Windows10.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 backing file: /home/poc/Win10/win10.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false
However when I try to restore the virtual disk I get:
$ sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 /home/poc/Win10/win10.qcow2 qemu-img: Could not apply snapshot '/var/lib/libvirt/images/Windows10.qcow2': -2 (No such file or directory)
I must be doing something obviously wrong, but can't see what it is. Hints would be appreciated.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
You have all the required permissions I'm sure, yes?
I'm using sudo, so yes.
poc
On Mon, Mar 27, 2017 at 1:31 PM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2017-03-27 at 12:00 -0600, InvalidPath wrote:
On Mon, Mar 27, 2017 at 11:31 AM, Patrick O'Callaghan <
pocallaghan@gmail.com
wrote: I have a QEMU image snapshot:
$ sudo qemu-img info /var/lib/libvirt/images/Windows10.qcow2 image: /var/lib/libvirt/images/Windows10.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 backing file: /home/poc/Win10/win10.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false
However when I try to restore the virtual disk I get:
$ sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 /home/poc/Win10/win10.qcow2 qemu-img: Could not apply snapshot '/var/lib/libvirt/images/
Windows10.qcow2':
-2 (No such file or directory)
I must be doing something obviously wrong, but can't see what it is. Hints would be appreciated.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
You have all the required permissions I'm sure, yes?
I'm using sudo, so yes.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Gotcha, Just making sure ;)
Can you create a new VM, attaching that image and use it successfully?
On Mon, 2017-03-27 at 13:35 -0600, InvalidPath wrote:
You have all the required permissions I'm sure, yes?
I'm using sudo, so yes.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Gotcha, Just making sure ;)
Can you create a new VM, attaching that image and use it successfully?
I'll try that, but I'd still like to figure out why it didn't work. Note that the VM suffered a crash (forced power-down) so its filesystem needs fixing. However a Windows DVD in rescue mode didn't work, so I was hoping a snapshot would do the trick. However I'm not entirely sure if this is supported, or if snapshots are only useful as a rollback mechanism.
poc
On Mar 28, 2017 6:28 AM, "Patrick O'Callaghan" pocallaghan@gmail.com wrote:
On Mon, 2017-03-27 at 13:35 -0600, InvalidPath wrote:
You have all the required permissions I'm sure, yes?
I'm using sudo, so yes.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Gotcha, Just making sure ;)
Can you create a new VM, attaching that image and use it successfully?
I'll try that, but I'd still like to figure out why it didn't work. Note that the VM suffered a crash (forced power-down) so its filesystem needs fixing. However a Windows DVD in rescue mode didn't work, so I was hoping a snapshot would do the trick. However I'm not entirely sure if this is supported, or if snapshots are only useful as a rollback mechanism.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Sure, by all means. However performing this test, will hopefully shed light and verify the image is solid.
On 03/27/2017 12:31 PM, Patrick O'Callaghan wrote:
I have a QEMU image snapshot:
$ sudo qemu-img info /var/lib/libvirt/images/Windows10.qcow2 image: /var/lib/libvirt/images/Windows10.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 backing file: /home/poc/Win10/win10.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false
However when I try to restore the virtual disk I get:
$ sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 /home/poc/Win10/win10.qcow2 qemu-img: Could not apply snapshot '/var/lib/libvirt/images/Windows10.qcow2': -2 (No such file or directory)
I must be doing something obviously wrong, but can't see what it is. Hints would be appreciated.
What you have is not a snapshot. A snapshot is created with "qemu-img snapshot -c <snapshot-name> <imagename>", and that is _not_ a separate file. That "<snapshot-name>" is not a file name but just a tag to identify one of possibly several snapshots within that "<imagename>" file.
What you made was a copy-on-write image using /home/poc/Win10/win10.qcow2 as a backing file. You can make changes in /var/lib/libvirt/images/Windows10.qcow2 and not affect the backing file, but the backing file _must_not_be_changed_ during the lifetime of that dependent image. That c-o-w image cannot be restored to its original state. The way you do that is to throw it away and create a new one with the same backing file.
On Tue, 2017-03-28 at 09:13 -0500, Robert Nichols wrote:
On 03/27/2017 12:31 PM, Patrick O'Callaghan wrote:
I have a QEMU image snapshot:
$ sudo qemu-img info /var/lib/libvirt/images/Windows10.qcow2 image: /var/lib/libvirt/images/Windows10.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 backing file: /home/poc/Win10/win10.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false
However when I try to restore the virtual disk I get:
$ sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 /home/poc/Win10/win10.qcow2 qemu-img: Could not apply snapshot '/var/lib/libvirt/images/Windows10.qcow2': -2 (No such file or directory)
I must be doing something obviously wrong, but can't see what it is. Hints would be appreciated.
What you have is not a snapshot. A snapshot is created with "qemu-img snapshot -c <snapshot-name> <imagename>", and that is _not_ a separate file. That "<snapshot-name>" is not a file name but just a tag to identify one of possibly several snapshots within that "<imagename>" file.
I did create it with the above line. Clearly I didn't understand where it was, or perhaps I inadvertently deleted it.
Currently 'qemu-img snapshot -l <filename>' gives no output, so it looks like it's gone assuming it was ever there.
(BTW the "no such file or directory" message could not be less helpful).
What you made was a copy-on-write image using /home/poc/Win10/win10.qcow2 as a backing file. You can make changes in /var/lib/libvirt/images/Windows10.qcow2 and not affect the backing file, but the backing file _must_not_be_changed_ during the lifetime of that dependent image. That c-o-w image cannot be restored to its original state. The way you do that is to throw it away and create a new one with the same backing file.
I'm going to try to attach it to another Windows instance to see if it can be repaired. Otherwise, it looks like I'm screwed.
Thanks for the information.
poc
On Tue, Mar 28, 2017 at 8:13 AM, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
On 03/27/2017 12:31 PM, Patrick O'Callaghan wrote:
I have a QEMU image snapshot:
$ sudo qemu-img info /var/lib/libvirt/images/Windows10.qcow2 image: /var/lib/libvirt/images/Windows10.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 backing file: /home/poc/Win10/win10.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false
However when I try to restore the virtual disk I get:
$ sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 /home/poc/Win10/win10.qcow2 qemu-img: Could not apply snapshot '/var/lib/libvirt/images/Windows10.qcow2': -2 (No such file or directory)
I must be doing something obviously wrong, but can't see what it is. Hints would be appreciated.
What you have is not a snapshot. A snapshot is created with "qemu-img snapshot -c <snapshot-name> <imagename>", and that is _not_ a separate file. That "<snapshot-name>" is not a file name but just a tag to identify one of possibly several snapshots within that "<imagename>" file.
What you made was a copy-on-write image using /home/poc/Win10/win10.qcow2 as a backing file. You can make changes in /var/lib/libvirt/images/Windows10.qcow2 and not affect the backing file, but the backing file _must_not_be_changed_ during the lifetime of that dependent image. That c-o-w image cannot be restored to its original state. The way you do that is to throw it away and create a new one with the same backing file.
-- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Ahh interesting. Thanks for this info Patrick.
On 03/28/2017 10:28 AM, Patrick O'Callaghan wrote:
On Tue, 2017-03-28 at 09:13 -0500, Robert Nichols wrote:
On 03/27/2017 12:31 PM, Patrick O'Callaghan wrote:
I have a QEMU image snapshot:
$ sudo qemu-img info /var/lib/libvirt/images/Windows10.qcow2 image: /var/lib/libvirt/images/Windows10.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 backing file: /home/poc/Win10/win10.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false
However when I try to restore the virtual disk I get:
$ sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 /home/poc/Win10/win10.qcow2 qemu-img: Could not apply snapshot '/var/lib/libvirt/images/Windows10.qcow2': -2 (No such file or directory)
I must be doing something obviously wrong, but can't see what it is. Hints would be appreciated.
What you have is not a snapshot. A snapshot is created with "qemu-img snapshot -c <snapshot-name> <imagename>", and that is _not_ a separate file. That "<snapshot-name>" is not a file name but just a tag to identify one of possibly several snapshots within that "<imagename>" file.
I did create it with the above line. Clearly I didn't understand where it was, or perhaps I inadvertently deleted it.
That output from "qemu-img info ..." says otherwise. That /var/lib/libvirt/images/Windows10.qcow2 file was created with "qemu-img create -b /home/poc/Win10/win10.qcow2 /var/lib/libvirt/images/Windows10.qcow2". There is no other way that "backing file: /home/poc/Win10/win10.qcow2" could appear in the output.
In order for the .../Windows10.qcow2 file to be valid, that backing file _must_ exist and be unchanged since that new file was created.
Currently 'qemu-img snapshot -l <filename>' gives no output, so it looks like it's gone assuming it was ever there.
There should not be any output. You simply do not have anything that qemu-img calls a "snapshot".
(BTW the "no such file or directory" message could not be less helpful).
Agreed, 100%.
What you made was a copy-on-write image using /home/poc/Win10/win10.qcow2 as a backing file. You can make changes in /var/lib/libvirt/images/Windows10.qcow2 and not affect the backing file, but the backing file _must_not_be_changed_ during the lifetime of that dependent image. That c-o-w image cannot be restored to its original state. The way you do that is to throw it away and create a new one with the same backing file.
I'm going to try to attach it to another Windows instance to see if it can be repaired. Otherwise, it looks like I'm screwed.
That backing file _must_ exist, or else you have nothing. If the backing file exists, but has changed, then the only valid image is what is currently in the backing file. If an unchanged backing file exists, you have the option to (a) throw away that /var/lib/libvirt/images/Windows10.qcow2 file and create it anew from that backing file, or (b) merge the changes that have been made in the /var/lib/libvirt/images/Windows10.qcow2 file back into the backing file. You do the latter with "qemu-img commit /var/lib/libvirt/images/Windows10.qcow2".
On Tue, 2017-03-28 at 12:38 -0500, Robert Nichols wrote:
What you have is not a snapshot. A snapshot is created with "qemu-img snapshot -c <snapshot-name> <imagename>", and that is _not_ a separate file. That "<snapshot-name>" is not a file name but just a tag to identify one of possibly several snapshots within that "<imagename>" file.
I did create it with the above line. Clearly I didn't understand where it was, or perhaps I inadvertently deleted it.
That output from "qemu-img info ..." says otherwise. That /var/lib/libvirt/images/Windows10.qcow2 file was created with "qemu-img create -b /home/poc/Win10/win10.qcow2 /var/lib/libvirt/images/Windows10.qcow2". There is no other way that "backing file: /home/poc/Win10/win10.qcow2" could appear in the output.
I can only say I have no recollection of typing that, and that I did want to create a snapshot as a test. But it was a few days ago so I may be wrong.
In order for the .../Windows10.qcow2 file to be valid, that backing file _must_ exist and be unchanged since that new file was created.
OK, though I can't guarantee it hasn't changed since I did run the VM afterwards.
Currently 'qemu-img snapshot -l <filename>' gives no output, so it looks like it's gone assuming it was ever there.
There should not be any output. You simply do not have anything that qemu-img calls a "snapshot".
(BTW the "no such file or directory" message could not be less helpful).
Agreed, 100%.
What you made was a copy-on-write image using /home/poc/Win10/win10.qcow2 as a backing file. You can make changes in /var/lib/libvirt/images/Windows10.qcow2 and not affect the backing file, but the backing file _must_not_be_changed_ during the lifetime of that dependent image. That c-o-w image cannot be restored to its original state. The way you do that is to throw it away and create a new one with the same backing file.
I'm going to try to attach it to another Windows instance to see if it can be repaired. Otherwise, it looks like I'm screwed.
That backing file _must_ exist, or else you have nothing. If the backing file exists, but has changed, then the only valid image is what is currently in the backing file. If an unchanged backing file exists, you have the option to (a) throw away that /var/lib/libvirt/images/Windows10.qcow2 file and create it anew from that backing file, or (b) merge the changes that have been made in the /var/lib/libvirt/images/Windows10.qcow2 file back into the backing file. You do the latter with "qemu-img commit /var/lib/libvirt/images/Windows10.qcow2".
OK, I'll look into that.
Thanks again.
poc
On Tue, Mar 28, 2017 at 12:48 PM, Patrick O'Callaghan <pocallaghan@gmail.com
wrote:
On Tue, 2017-03-28 at 10:21 -0600, InvalidPath wrote:
Ahh interesting. Thanks for this info Patrick.
I think you meant to thank Robert.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Wow Im having a hard tie reading today :(
Thanks Robert!
On Tue, 28 Mar 2017 19:56:48 +0100 Patrick O'Callaghan pocallaghan@gmail.com wrote:
I can only say I have no recollection of typing that, and that I did want to create a snapshot as a test. But it was a few days ago so I may be wrong.
If you use bash, and have bash history enabled, at a command line you could type a CTRL-R and then type qemu to search back through history for commands with qemu in them that you've run. Each time you hit CTRL-R it will look back one more time.
Or, you can just do less ~/.bash_history, type G to go to the bottom, and look for qemu using ?qemu.
On 03/28/2017 01:56 PM, Patrick O'Callaghan wrote:
On Tue, 2017-03-28 at 12:38 -0500, Robert Nichols wrote:
What you have is not a snapshot. A snapshot is created with "qemu-img snapshot -c <snapshot-name> <imagename>", and that is _not_ a separate file. That "<snapshot-name>" is not a file name but just a tag to identify one of possibly several snapshots within that "<imagename>" file.
I did create it with the above line. Clearly I didn't understand where it was, or perhaps I inadvertently deleted it.
That output from "qemu-img info ..." says otherwise. That /var/lib/libvirt/images/Windows10.qcow2 file was created with "qemu-img create -b /home/poc/Win10/win10.qcow2 /var/lib/libvirt/images/Windows10.qcow2". There is no other way that "backing file: /home/poc/Win10/win10.qcow2" could appear in the output.
I can only say I have no recollection of typing that, and that I did want to create a snapshot as a test. But it was a few days ago so I may be wrong.
In order for the .../Windows10.qcow2 file to be valid, that backing file _must_ exist and be unchanged since that new file was created.
OK, though I can't guarantee it hasn't changed since I did run the VM afterwards.
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.
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.
On Tue, 2017-03-28 at 12:20 -0700, stan wrote:
On Tue, 28 Mar 2017 19:56:48 +0100 Patrick O'Callaghan pocallaghan@gmail.com wrote:
I can only say I have no recollection of typing that, and that I did want to create a snapshot as a test. But it was a few days ago so I may be wrong.
If you use bash, and have bash history enabled, at a command line you could type a CTRL-R and then type qemu to search back through history for commands with qemu in them that you've run. Each time you hit CTRL-R it will look back one more time.
Or, you can just do less ~/.bash_history, type G to go to the bottom, and look for qemu using ?qemu.
Or use grep on .bash_history directly. However this still doesn't show any instance of "qemu-img create -b ...". What it does show is:
$ grep "sudo qemu-img * create" .bash_history $ grep "sudo qemu-img * snapshot" .bash_history sudo qemu-img snapshot -c test win10 sudo qemu-img snapshot -c test Windows10.qcow2 sudo qemu-img snapshot -l Windows10.qcow2 sudo qemu-img snapshot -l sudo qemu-img snapshot -l win10 sudo qemu-img snapshot -l Win10 sudo qemu-img snapshot -l Windows10.qcow2 sudo qemu-img snapshot -l test sudo qemu-img snapshot -l test sudo qemu-img snapshot -l win10.qcow2 sudo qemu-img snapshot -l /home/poc/Win10/win10.qcow2 sudo qemu-img snapshot info /home/poc/Win10/win10.qcow2 sudo qemu-img snapshot info win10.qcow2 sudo qemu-img snapshot info /var/lib/libvirt/images/Windows10.qcow2 sudo qemu-img snapshot -a /home/poc/Win10/win10.qcow2 win10.qcow2 sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 /home/poc/Win10/win10.qcow2 sudo qemu-img snapshot -a /home/poc/Win10/win10.qcow2 /var/lib/libvirt/images/Windows10.qcow2 sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 win10.qcow2 sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 /home/poc/Win10/win10.qcow2 sudo qemu-img snapshot -a /home/poc/Win10/win10.qcow2 /var/lib/libvirt/images/Windows10.qcow2 sudo qemu-img snapshot -a /var/lib/libvirt/images/Windows10.qcow2 /home/poc/Win10/win10.qcow2 sudo qemu-img snapshot -l /var/lib/libvirt/images/Windows10.qcow2
I'm afraid this is more confusing than it needs to be because I was basically in "try anything" mode, but as you can see I did create a snapshot labelled 'test' (and the '-l' option listed it), but did not delete it nor use 'create -b' at any point.
Anyway, I don't expect anyone to try and decipher the above.
Thanks.
poc
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.
poc
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.
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
On 03/29/2017 09:40 AM, Patrick O'Callaghan wrote:
On Wed, 2017-03-29 at 08:44 -0500, Robert Nichols wrote:
"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.
Indeed! The manpage does say, "If the option backing_file is specified, ..." in the section for the "create" command, but does not, in that section, mention how to specify it.
...
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?
You don't _create_ the backing file. You _use_ an existing image _as_ a backing file. What you create is a new file, let's call it a "virtual image", which you can then use just like any other disk image in a VM. If you're using virt-manager, you can create a new VM and select "Import existing disk image" as the source. Or, you can edit your existing VM instance and substitute the new "virtual image" file for whatever it is using now.
On Wed, 2017-03-29 at 13:20 -0500, Robert Nichols wrote:
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.
Indeed! The manpage does say, "If the option backing_file is specified, ..." in the section for the "create" command, but does not, in that section, mention how to specify it.
Quite ...
...
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?
You don't _create_ the backing file. You _use_ an existing image _as_ a backing file. What you create is a new file, let's call it a "virtual image", which you can then use just like any other disk image in a VM. If you're using virt-manager, you can create a new VM and select "Import existing disk image" as the source. Or, you can edit your existing VM instance and substitute the new "virtual image" file for whatever it is using now.
Right, I'll give that a go.
poc
-
InvalidPath -
Patrick O'Callaghan -
Robert Nichols -
stan