Re: [Xen-users] Recovering resources from old guests

[Caleb Call <caleb@xxxxxxxxxxx>]

OK, that sounds correct and makes sense.  The Xen world is a new thing to me, I have a background with OpenVZ and VMWare...and now I'm getting to learn Xen.  Thanks!

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

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