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
|
Home