Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of creategui@gmail.com designates
 209.85.220.49 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Import instances from previous deployment
From: =?iso-8859-1?Q?Carlos_Re=E1tegui?= <creategui@gmail.com>
In-Reply-To: <D00EB9F9.43AA3%nitin.mehta@citrix.com>
Date: Mon, 11 Aug 2014 19:57:09 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <EE8ED866-5AE5-4F4C-84CE-3AF29C4AAAEF@gmail.com>
References: <D00EB9F9.43AA3%nitin.mehta@citrix.com>
To: users@cloudstack.apache.org


On Aug 11, 2014, at 6:23 PM, Nitin Mehta <Nitin.Mehta@citrix.com> wrote:

> This is superb Carlos.
thank you
> So you created dummy vms to create records in CS db
> and then changed the volume path to reflect the old vhds.
Exactly.

> Yes, I think it should be fine to delete the dummy vids created with =
the
> new instance.
Thanks for the confirmation.  I was concerned that there is a uuid in =
the volume table and I was not sure how or if that was used in the =
system.
>=20
> Thanks,
> -Nitin
>=20
> On 11/08/14 5:49 PM, "Carlos Reategui" <carlos@reategui.com> wrote:
>=20
>> Hi Nitin,
>> I created a new primary store share in NFS for the new deployment and
>> removed the old one from exports.  The XS hosts where re-used and
>> installed
>> fresh so nothing was using the old primary store.  The new CS =
deployment
>> only knows about the new primary store.
>>=20
>> I used 'vhd-util scan -f -p -v -m old/path/*.vhd' to check the chain =
of
>> vhd
>> and copied over all the ones I needed from the old path to the new =
path.
>> I
>> got the old paths from by db backup.
>>=20
>> Yes I changed the path in the volumes table to point to the 'old' vhd
>> file.
>> I stopped the instances from CS before editing the db. When I started
>> them my old instances were back.
>>=20
>> It was only 10 instances.... any more and I probably would have =
scripted
>> it.
>>=20
>> The vhd files that were created with the new instances are still =
there on
>> the primary store and I am guessing I should be ok to delete them.
>>=20
>> Thanks,
>> Carlos
>>=20
>> PS. I did run into a problem with the primary store scan/cleanup =
process
>> the first time I tried where it cleaned up the parent of one of the =
child
>> vhd before I had a chance to copy the child over.  I stopped =
management
>> server and included all the files in the same copy command which =
seemed to
>> get me past that.
>>=20
>>=20
>> On Mon, Aug 11, 2014 at 5:30 PM, Nitin Mehta <Nitin.Mehta@citrix.com>
>> wrote:
>>=20
>>> Carlos - This looks fine to me. Have a couple of questions though
>>> So you reintroduced the old storage pool back on the new MS instance =
-
>>> make sure the old instances are shutdown and do not access the same
>>> storage else they can corrupt the volumes ?
>>> Did you mean that you changed the path in the volumes table ?
>>>=20
>>> Thanks,
>>> -Nitin
>>>=20
>>> On 11/08/14 11:56 AM, "Carlos Reategui" <creategui@gmail.com> wrote:
>>>=20
>>>> Hi All,
>>>> Follow-up on my recovery process.  After failing to upgrade to 4.4 =
I
>>> did a
>>>> fresh install and decided to go ahead and also do fresh installs of
>>>> XenServer to upgrade those to XS6.2.
>>>>=20
>>>> Instead of importing each of the vhd from all my instances as =
templates
>>>> and
>>>> creating instances from those, I created new instances matching the =
the
>>>> previous ones and then edited the volumes table with the vhd of the
>>>> original instance from the previous deployment (had to make sure to
>>>> include
>>>> parent vhd).  My volumes were all on shared NFS storage.
>>>>=20
>>>> Things appear to be working ok, but want to check if any of you =
foresee
>>>> any
>>>> issues with the method I followed.
>>>>=20
>>>> thanks,
>>>> Carlos
>>>=20
>>>=20
>=20