search for: einh

...you said, here's the output qemu-img info /virtual/APP03-c.qcow2 image: /virtual/APP03-c.qcow2 file format: qcow2 virtual size: 80G (85899345920 bytes) disk size: 987G cluster_size: 65536 Snapshot list: ID TAG VM SIZE DATE VM CLOCK �K�‘�Q�w���q���U��eInh�ik�{K?�M�w {����}���{�l6�z�Sa�ׂP��2ZZ �e�j��~_��� ^.���=I��=n�ӱ��5��^F���*��v�6��Oc�JfH-[,~9�/̫��%O�cn�2��V䴘t n��]m�UC2d� 2.4G 2096-06-18 11:54:302089366:21:24.846 0 1970-01-01 01:00:00 00:00:00.000...

...g info /virtual/APP03-c.qcow2 > image: /virtual/APP03-c.qcow2 > file format: qcow2 > virtual size: 80G (85899345920 bytes) > disk size: 987G > cluster_size: 65536 > Snapshot list: > ID TAG VM SIZE DATE VM CLOCK > �K�‘�Q�w���q���U��eInh�ik�{K?�M�w Ouch. That's a qemu bug. Qemu should never report uninitialized data like that. I don't know if you kept the original file around, but this sort of garbage should be reported to qemu-devel@nongnu.org. Also, be aware that snapshot deletion does NOT shrink the listed disk size...

...irtual/APP03-c.qcow2 > > file format: qcow2 > > virtual size: 80G (85899345920 bytes) > > disk size: 987G > > cluster_size: 65536 > > Snapshot list: > > ID TAG VM SIZE DATE VM > > CLOCK > > �K�‘�Q�w���q���U��eInh�ik�{K?�M�w > > Ouch. That's a qemu bug. Qemu should never report uninitialized > data > like that. I don't know if you kept the original file around, but > this > sort of garbage should be reported to qemu-devel@nongnu.org. I'll pass this on as a bug, certainly no...

Hi, I had a 'domain' called APP03. I was performing auto snapshots each night using /usr/bin/virsh snapshot-create APP03 . I then wanted the domain to be called APP01 for clarity's sake, so I did virsh dumpxml APP03 > APP03.xml, edited the name to APP01 and changed the ID. I then did virsh define APP03.xml to get APP01. I have now realised that the qcow2 images are huge (1.1TB