Xen project Mailing List

On Tue, Apr 6, 2010 at 2:53 PM, Matej Zary <zary@xxxxxxxxx> wrote:

Hi,

maybe I'm following this thread incorrectly, but - these old tap:aio: guest VMs had file based HDD images right? In that case they were stored probably on some of the LVs. So if you deleted the img files, the free space increased on that particular LVs. But that particular LVs are still the same size as they were before (just there's more free space on them), so they still "occupy" the same number of PE (physical extents), so number of free/unallocated PE will remain also the same. If you want more free/unallocated space in your VG, you have to shrink or remove some of the existing LVs.

In case I missed the point completly - I'm sorry. :)

Regards

Matej

-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Caleb Call
Sent: Tuesday, April 06, 2010 6:39 PM
To: Fajar A. Nugraha
Cc: Xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Recovering resources from old guests

Thanks. However, I tried to get rid of one of them, made sure it wasn't running, removed the disk image and then removed the config file. I ran a vgdisplay before and after and I didn't gain the disk space back that I should have. Any thoughts?

Thanks again

##### Before I removed the disk image #####
--- Volume group ---
VG Name vmvol01
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 38
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 18
Open LV 7
Max PV 0
Cur PV 2
Act PV 2
VG Size 455.99 GB
PE Size 4.00 MB
Total PE 116734
Alloc PE / Size 56832 / 222.00 GB
Free PE / Size 59902 / 233.99 GB
VG UUID s96CmA-1d2x-O1Oo-rrCr-M7n6-dvRQ-AEJjcI

##### After I removed the disk image #####
--- Volume group ---
VG Name vmvol01
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 38
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 18
Open LV 7
Max PV 0
Cur PV 2
Act PV 2
VG Size 455.99 GB
PE Size 4.00 MB
Total PE 116734
Alloc PE / Size 56832 / 222.00 GB
Free PE / Size 59902 / 233.99 GB
VG UUID s96CmA-1d2x-O1Oo-rrCr-M7n6-dvRQ-AEJjcI

On Tue, Apr 6, 2010 at 3:55 AM, Fajar A. Nugraha <fajar@xxxxxxxxx> wrote:

On Tue, Apr 6, 2010 at 4:27 AM, Caleb Call <caleb@xxxxxxxxxxx> wrote:
> We currently have several old guests that we are removing from the inventory
> and recovering their resources. I've ran in to a minor (probably very
> simple) issue. Instead of using logical volumes like the rest of our
> guests, these ones are using tap:aio: The main question is, is there
> anything special I need to do to reclaim the resources from these disks, or
> is it as simple as just deleting these images?

That's pretty much it. Make sure the guest is not running, then you
can delete the file images.

> My second(ary) question is,
> what is tap:aio:? I've been searching but have been unable to find
> anything definitive on what they are. Is it just a disk image used by Xen,
> or is there something special about it? How is a tap:aio: disk created,
> etc?

The image itself is basically just a raw disk image. What makes
tap:aio:/ different from file:/ (or manually creating loopback
devices) is that tap:aio is supposed to be more reliable and have
better performance, not effected by dom0 caching effect, thus reducing
possible data loss. This is different from (for example) tap:qcow,
which uses its own (not raw) file format. See
http://wiki.xensource.com/xenwiki/blktap for details

--
Fajar

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users