On 11/12/12 5:57 PM, "Musayev, Ilya" <imusa...@webmd.net> wrote:
>Is there a DB relational map for CS that I can use as reference? Cloud.security_group_vm_map table. > >I run VMWare ESXi - VSphere 5. > >I guess I could write a shell script on the backend to look for destroyed >but not expunged VMs once a day and delete them from DB. > >-----Original Message----- >From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] >Sent: Monday, November 12, 2012 8:23 PM >To: cloudstack-dev@incubator.apache.org >Subject: Re: can i force expunge > >Ilya, > >What hypervisor do you have? CleanupNetworkRules command is invoked by >SecurityGroupManager when clenaup SG for the expunged/crashed User vm. SG >is supported on Xen/KVM machines only. I suspect that in your case SG >mapping was created for the vm although your hypervisor doesn't support >it. Check "security_group_vm_map" to see if there are references to the >vms that fail to expunge. > >And the consistent failure in clenaup process will retain the vm in >Destroyed state forever. As the workaround, I would suggest to delete the >mappings for the VM from the DB table, and then vm expunge thread should >clean up vm successfully. > >Deleting the vm from the DB w/o going through proper cleanup process >might be dangerous as there can be existing DB entries referencing the >object you've removed (or marked as removed). > >-Alena. > >On 11/12/12 2:47 PM, "Musayev, Ilya" <imusa...@webmd.net> wrote: > >>I gave up on the wait, went ahead and deleted destroyed VM (which >>should have been expunged) from DB. >> >>I was then able to delete the network.. >> >>Thanks >>ilya >> >>-----Original Message----- >>From: Musayev, Ilya [mailto:imusa...@webmd.net] >>Sent: Monday, November 12, 2012 5:31 PM >>To: cloudstack-dev@incubator.apache.org >>Subject: RE: can i force expunge >> >>Yeah, that's less than idea - you wont recall what was done to release >>those IPs? >> >>I also notice this in my log when it tries to expunge but fails: >> >>2012-11-12 17:28:12,995 DEBUG [agent.transport.Request] >>(DirectAgent-416:null) Seq 31-1309671426: Processing: { Ans: , MgmtId: >>345051904793, via: 31, Ver: v1, Flags: 10, >>[{"UnsupportedAnswer":{"result":false,"details":"Unsupported command >>issued:com.cloud.agent.api.CleanupNetworkRulesCmd. Are you sure you >>got the right type of server?","wait":0}}] } >> >> >> >>-----Original Message----- >>From: Caleb Call [mailto:calebc...@me.com] >>Sent: Monday, November 12, 2012 4:57 PM >>To: cloudstack-dev@incubator.apache.org >>Subject: Re: can i force expunge >> >>Does it show your instances sitting in an expunge state? I've had it >>before not show the instances in that state (they get cleaned-up, but >>the IPs don't), but it still thinks IPs are used. Infact right now >>this is the case on my management network. It thinks 3 or 4 extra IPs >>are actually used then what really is being used. I've always had to >>go in to the database and clean this up. >> >> >>On Nov 12, 2012, at 2:51 PM, "Musayev, Ilya" <imusa...@webmd.net> wrote: >> >>> Caleb >>> >>> The network gc is already set to 600seconds - which I think is pretty >>>low. >>> >>> The ms has been restarted.. >>> >>> Thanks >>> ilya >>> >>> -----Original Message----- >>> From: Caleb Call [mailto:calebc...@me.com] >>> Sent: Monday, November 12, 2012 4:27 PM >>> To: cloudstack-dev@incubator.apache.org >>> Subject: Re: can i force expunge >>> >>> Make sure you also drop the network.gc.interval and network.gc.wait >>>in addition to expunge.delay and expunge.interval. Also, this may be >>>obvious but you also need to restart the ms for the new intervals to >>>take affect. >>> >>> Thanks >>> >>> On Nov 12, 2012, at 2:11 PM, "Musayev, Ilya" <imusa...@webmd.net> >>>wrote: >>> >>>> Can I force expunge via API call or some other way? >>>> >>>> I lowered the expunge parameters in the GUI to 1800 seconds and 2 >>>>threads, but it hasn't worked for me. >>>> >>>> I have vms that are destroyed but not expunged - that are holding >>>>the IP I need to release to delete the network. >>>> >>>> Thanks >>>> ilya >>> >>> >>> >> >> >> >> >> >> > > > > >
