<div dir="ltr">I was sure I was doing something wrong as I'm not yet fully aware of QCOW2 snapshot feature and how it interacts with libguestfs.<br><div class="gmail_quote"><div dir="ltr"><div><div><div><br></div>I'll try to explain better the scenario:<br><br></div>I have several hosts running lots of VMs which are generated from few base images, say A, B, C the base images (backing file) and A1, A2, A*, B1, B2, B* clones on top of which the newly spawned VMs are running.<br></div><div>I need to collect the disk states of A*, B*, C* machines and see what has been written there. I don't care about the whole content as the base images content A, B, C are well known to me, only thing it matters are the deltas of the new clones.<br><br></div><div>One more piece in the puzzle is that the inspection does not happen on the hosts running the VMs but on a dedicated server. <br><br></div><div>My idea was to collect those "snapshots" (generic term not the QEMU one) from the hosts and send them to my inspection server. As A, B and C are accessible from that server only thing I need is to rebase those snapshot to correctly inspect them through libguestfs, and it proved to work (I'm using readonly mode as I only care about reading the disks). I'm not really interested in having consistent point-in-time state of the disks as the operation is done several times a day so I can cope with semi-consistent data as it can be easily re-constructed.<br><br></div><div>My real problem comes when I try to inspect the disk snapshot: libguestfs will, of course, let me see the whole content of the disks, which means A + A*. Apart from the waste of CPU time spend on looking at files I already know the state (the ones contained in A), it generates a lot of noise. A Linux base image with some library installed consists in 20+ K files, installing something extra (Apache server for example) just brings some hundreds new files and I'm interested only in those ones.<br><br></div><div>So my real question is: is there a way to distinguish the files contained in the two different disk images (A and A1) or shall I think about a totally different approach?<br><br></div><div>Thank you.<br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-03-24 0:43 GMT+02:00 Richard W.M. Jones <span dir="ltr"><<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Mon, Mar 23, 2015 at 10:41:01PM +0000, Richard W.M. Jones wrote:<br> > On Mon, Mar 23, 2015 at 04:34:21PM +0200, NoxDaFox wrote:<br> > > Greetings,<br> > ><br> > > I have the following typical scenario: given one or more qcow2 base images<br> > > I clone them with COW and start the VMs.<br> > ><br> > > At a certain point I'd like to inspect them in order to see their evolution<br> > > compared to the known base images. To do so I was thinking about taking a<br> > > disk snapshot of each VM and inspect its content through libguestfs (using<br> > > it's Python bindings).<br> > ><br> > > Obviously I need the base image in order for libguestfs to correctly guess<br> > > the OS, the FS structure etc.. Problem is that that point when I inspect<br> > > the disk I get the whole disk state including the base image content (30K+<br> > > files and directories).<br> > ><br> > > This is not an issue but it's a very heavy operation considering that some<br> > > of the snapshots are few megabytes while the base images are several<br> > > gigabytes.<br> > ><br> > > Is there a way to programmatically instruct libguestfs to limit the<br> > > inspection to the sole snapshot?<br> > > Would it work as well with other disk format (vmdk linked clones for<br> > > example)?<br> > ><br> > > For better comprehension I'll show the sequence I'm doing (I might do it<br> > > wrong of course):<br> > ><br> > > virsh -c "qemu:///system" snapshot-create --disk-only <domain-ID><br> > ><br> > > I get the snapshot location from its XML description and then:<br> > ><br> > > qemu-img convert -f qcow2 -O qcow2 base_image.qcow2 snapshot.qcow2<br> ><br> > This makes a copy of the whole disk image. It's also not a consistent<br> > (point in time) copy.<br> <br> </div></div>Oh I see that you're copying the _snapshot_ that you created with<br> libvirt; it's not a whole disk copy. There's still not any point in<br> doing this, and what I said below stands.<br> <div><div><br> > > At that point I mount it through libguestfs and inspect its content.<br> ><br> > As long as you use the 'readonly=1' flag (which is really *essential*,<br> > else you'll get disk corruption), you can just point libguestfs at the<br> > base image:<br> ><br> > g = guestfs.GuestFS (python_return_dict=True)<br> > g.add_drive_opts ("base_image.qcow2", format="qcow2", readonly=1)<br> ><br> > That also doesn't get you a consistent snapshot, but it'll work most<br> > of the time, and give you a clear error in libguestfs when it doesn't<br> > (and won't corrupt your base disk or anything like that, provided<br> > you're using readonly=1).<br> ><br> > The effect of the readonly=1 flag is to create an external snapshot.<br> > It is roughly the equivalent of doing:<br> ><br> > qemu-img create -f qcow2 -b base_image snapshot.qcow2<br> > < point libguestfs at snapshot.qcow2 ><br> ><br> > If you want lightweight, consistent, point-in-time snapshots (which it<br> > sounds like you do), qemu has recently been adding this capability.<br> > See the 'drive-backup' monitor command. I've not tried using that and<br> > I don't know if it is wired up through libvirt, but libguestfs should<br> > be able to consume it since it's just an NBD source.<br> <br> Rich.<br> <br> --<br> Richard Jones, Virtualization Group, Red Hat <a href="http://people.redhat.com/~rjones" target="_blank">http://people.redhat.com/~rjones</a><br> Read my programming and virtualization blog: <a href="http://rwmj.wordpress.com" target="_blank">http://rwmj.wordpress.com</a><br> virt-top is 'top' for virtual machines. Tiny program with many<br> powerful monitoring features, net stats, disk stats, logging, etc.<br> <a href="http://people.redhat.com/~rjones/virt-top" target="_blank">http://people.redhat.com/~rjones/virt-top</a><br> </div></div></blockquote></div><br></div> </div></div></div><br></div>