> -----Original Message-----
> From: Marcus Sorensen [mailto:shadow...@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!

Reply via email to