Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-users@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of calebcall@me.com designates
 17.158.236.242 as permitted sender)
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Subject: Re: Removing a Zone
From: Caleb Call <calebcall@me.com>
In-reply-to: <4C478694-02B7-4B72-BE79-D5770D6DB7E9@me.com>
Date: Tue, 03 Jul 2012 21:46:41 -0600
Content-transfer-encoding: quoted-printable
Message-id: <BC34F2AA-4914-49BB-AC9C-1FB34B14D23C@me.com>
References: <CC18ACFC.653C%Ahmad.Emneina@citrix.com>
 <4C478694-02B7-4B72-BE79-D5770D6DB7E9@me.com>
To: cloudstack-users@incubator.apache.org


On Jul 3, 2012, at 3:20 PM, Caleb Call wrote:

>=20
> On Jul 3, 2012, at 3:10 PM, Ahmad Emneina wrote:
>=20
>> On 7/3/12 1:50 PM, "Caleb Call" <calebcall@me.com> wrote:
>>=20
>>> 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?
>>>=20
>>> Thanks,
>>> Caleb
>>>=20
>>=20
>> 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
>>=20
>> These will require a service restart. I believe you have vm's that =
have
>> yet to be expunged. This will speed up the process.
>>=20
>> --=20
>> =C6
>>=20
>>=20
>>=20
>=20
> Excellent, We'll give that a shot and see if that clears them up (I'm =
assuming it will).  Thanks
>=20
> Thanks,
> Caleb
>=20


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