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

[Matej Zary <zary@xxxxxxxxx>]

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