cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Higginbottom <>
Subject Re: Removing a Zone
Date Wed, 04 Jul 2012 07:14:57 GMT
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" <> wrote:


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,

-----Original Message-----
From: Caleb Call []
Sent: Wednesday, July 04, 2012 9:17 AM
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" <> 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
>>> 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.


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.
View raw message