Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of shadowsor@gmail.com
 designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <C66C814C1ABFA8449FF65CB44953A8B4012CBB65BC93@SJCPMAILBOX01.citrite.net>
References: 
 <CALFpzo5-dFMFnEqW0sgqoR-UdbAA9eovPL8d2zDZE69Kaiuuww@mail.gmail.com>
	<C66C814C1ABFA8449FF65CB44953A8B4012CBB65BC93@SJCPMAILBOX01.citrite.net>
Date: Mon, 10 Sep 2012 11:49:15 -0600
Message-ID: 
 <CALFpzo447uJ=FtAB6bXuR4DfnrbskMQ1gr_qDxRNb8U6szOvjQ@mail.gmail.com>
Subject: Re: cleaning up patch disks
From: Marcus Sorensen <shadowsor@gmail.com>
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

thanks, so this affects all hypervisors/storage backends that use the
patch disk, or should I code my solution specific to KVM?

On Mon, Sep 10, 2012 at 11:43 AM, Edison Su <Edison.su@citrix.com> wrote:
>
>
>> -----Original Message-----
>> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>> Sent: Sunday, September 09, 2012 9:32 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: cleaning up patch disks
>>
>> I've got an issue with the CLVM on KVM support, it seems that the
>> patch disks are created on the fly when a system VM is started. If I
>> reboot a system VM 5 times I'll end up with 5 patch disks. I'm the one
>> who submitted the CLVM patch, and I don't see that there's much
>> difference between what we're doing with CLVM and what it does for
>> everything else, so I thought I'd ask:
>>
>> Is this an issue for other backing stores as well (accumulating patch
>> disks for system VMs)? If not where is it handled?
>
>
> It's a bug, that patch disks are not cleaned up after system vm got stopped.
>
>>
>> Any suggestions on how to go about fixing it? I see I could
>> potentially hack into StopCommand, rebootVM/cleanupVM/stopVM, detect
>> the patch disk and lvremove it, but then again if it doesn't go down
>> on purpose (say a host crash) I'll still be leaking patch disks.
>>
>> Is it safe to assume that any patch disk that's not currently open is
>> safe to delete (these are generated on the fly and not really tracked
>> anywhere in the database, right?)
>
> If it's created on shared storage shared by multiple KVM hosts, then it's not easy to know, this patch disk is opened or not.
> Normally, we can delete that patch disk for every stopcommand/stopvm/rebootvm/cleanupvm command.
> If host is crashed, CS manager will send a command to other hosts in the cluster to clean up the VM, so we have the chance to clean up the patch disk anyway.
> As you said in another mail, we can use the name schema: vm-name-patch-disk for patch disk.
> Patch are welcome!
>