That query (removed column in nics table is null is empty. mysql> select * from nics where removed is null; Empty set (0.00 sec)
Thanks On Jul 4, 2012, at 6:28 PM, Ahmad Emneina wrote: > On 7/4/12 2:11 PM, "Caleb Call" <calebc...@me.com> wrote: > >> @Edison - That's the state we're currently in. The zone is disabled. We >> basically removed everything starting with secondary storage. So we >> removed Secondary storage, Primary storage, Hosts, and Clusters. We now >> can't remove the pod (or zone) because of this error. >> >> @Sailaja - That query returns ~2800 rows, but no private IPs are >> assigned. However, it looks like all of them are stuck in an Expunging >> state. Can I just remove those from the database? >> >> mysql> select state,COUNT(*) from cloud.vm_instance; >> +-----------+----------+ >> | state | COUNT(*) | >> +-----------+----------+ >> | Expunging | 2803 | >> +-----------+----------+ >> 1 row in set (0.02 sec) > > Expunging state is the final state for VM's. Check to see if the VM's have > been removed (removed column in vm_instances will have a timestamp). Can > you check the nics table? Check the results from 'select * from nics > where removed is null;' this might yield the nic's that are still tying up > the process. > >> >> @Geoff - See above, we have been able to remove everything up to the pod >> level, including system VMs and even the hypervisors (hosts). >> >> At this point, with no hosts added, I can't see any possible way an IP is >> actually being used. >> >> Thanks guys for the quick responses. >> >> On Jul 4, 2012, at 1:14 AM, Geoff Higginbottom wrote: >> >>> Ensure all System VMs and Virtual Routers have been destroyed so they >>> release their IPs. When deleting a Zone, I always put all Primary >>> Storage and Hosts into Maintenance, then destroy all VMs, but I find >>> sometimes you have repeat the destroy process as the System VMs get >>> recreated even when everything is in maintenence mode. >>> >>> >>> >>> >>> On 4 Jul 2012, at 05:49, "Sailaja Mada" <sailaja.m...@citrix.com> wrote: >>> >>> Hi, >>> >>> Can you check the records of vm_instance table with query :> select >>> id,name,instance_name,private_ip_address,pod_id from cloud.vm_instance; >>> >>> This table gives the information about private_ip_address usage within >>> the POD . POD deletion will fail If there are any system VM entries with >>> the state of expunging . >>> >>> Thanks and Regards, >>> Sailaja.M >>> >>> -----Original Message----- >>> From: Caleb Call [mailto:calebc...@me.com] >>> Sent: Wednesday, July 04, 2012 9:17 AM >>> To: cloudstack-users@incubator.apache.org >>> Subject: Re: Removing a Zone >>> >>> >>> On Jul 3, 2012, at 3:20 PM, Caleb Call wrote: >>> >>>> >>>> On Jul 3, 2012, at 3:10 PM, Ahmad Emneina wrote: >>>> >>>>> On 7/3/12 1:50 PM, "Caleb Call" <calebc...@me.com> wrote: >>>>> >>>>>> We're setting up a cloudstack install and one of our guys setup the >>>>>> first zone as a basic zone. We need the vlan support the advanced >>>>>> provides so we're trying so remove the basic zone and recreate an >>>>>> advanced one. >>>>>> However, ever after removing system VMs, we are not able to remove >>>>>> the pod. We get an error that says "There are private IP addresses >>>>>> allocated for this pod". This isn't the case though (atleast not >>>>>> that we can see). >>>>>> Is there anyway to see where the IPs are supposedly being used, >>>>>> and/or forcibly remove this pod or zone? >>>>>> >>>>>> Thanks, >>>>>> Caleb >>>>>> >>>>> >>>>> What you might want to do is disable the zone and set the various >>>>> process intervals for cleanup (found in the global settings section) >>>>> to run more often. The params you will want to change are the >>>>> following: >>>>> - expunge.interval >>>>> - expunge.delay >>>>> - network.gc.interval >>>>> - network.gc.wait >>>>> >>>>> These will require a service restart. I believe you have vm's that >>>>> have yet to be expunged. This will speed up the process. >>>>> >>>>> -- >>>>> Æ >>>>> >>>>> >>>>> >>>> >>>> Excellent, We'll give that a shot and see if that clears them up (I'm >>>> assuming it will). Thanks >>>> >>>> Thanks, >>>> Caleb >>>> >>> >>> >>> We applied these changes and we still get the same error. We changed >>> everything down to 1 sec and still no luck. We tried restarting the >>> service, nothing, we even rebooted the server with no luck. The odd >>> thing is the only VMs even built were the system VMs, we haven't even >>> attempted to build or spin-up any instances ourselves. Like I said, >>> we're still trying to get the networking piece configured properly. Are >>> there any other suggestions on what we could try? It wouldn't be a big >>> deal to just rebuild the management server but I'd like to figure this >>> out for when it's a prod machine and I have something like this crop up. >>> >>> Thanks, >>> Caleb >>> >>> >>> >>> ShapeBlue provides a range of strategic and technical consulting and >>> implementation services to help IT Service Providers and Enterprises to >>> build a true IaaS compute cloud. ShapeBlue¹s expertise, combined with >>> CloudStack technology, allows IT Service Providers and Enterprises to >>> deliver true, utility based, IaaS to the customer or end-user. >>> >>> ________________________________ >>> >>> This email and any attachments to it may be confidential and are >>> intended solely for the use of the individual to whom it is addressed. >>> Any views or opinions expressed are solely those of the author and do >>> not necessarily represent those of Shape Blue Ltd. If you are not the >>> intended recipient of this email, you must neither take any action based >>> upon its contents, nor copy or show it to anyone. Please contact the >>> sender if you believe you have received this email in error. Shape Blue >>> Ltd is a company incorporated in England & Wales. >> >> > > > -- > Æ > > >
