Re: Import instances from previous deployment
UUID is just an external facing id to reference this volume with from CS APIs. It isn't used to reference the volume on the hypervisor. That¹s what path is used for. Thanks, -Nitin On 11/08/14 7:57 PM, "Carlos Reátegui" wrote: > >On Aug 11, 2014, at 6:23 PM, Nitin Mehta 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. >> >> Thanks, >> -Nitin >> >> On 11/08/14 5:49 PM, "Carlos Reategui" wrote: >> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> It was only 10 instances any more and I probably would have >>>scripted >>> it. >>> >>> 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. >>> >>> Thanks, >>> Carlos >>> >>> 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. >>> >>> >>> On Mon, Aug 11, 2014 at 5:30 PM, Nitin Mehta >>> wrote: >>> 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 ? Thanks, -Nitin On 11/08/14 11:56 AM, "Carlos Reategui" wrote: > 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. > > 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. > > Things appear to be working ok, but want to check if any of you >foresee > any > issues with the method I followed. > > thanks, > Carlos >> >
Re: Import instances from previous deployment
On Aug 11, 2014, at 6:23 PM, Nitin Mehta 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. > > Thanks, > -Nitin > > On 11/08/14 5:49 PM, "Carlos Reategui" wrote: > >> 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. >> >> 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. >> >> 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. >> >> It was only 10 instances any more and I probably would have scripted >> it. >> >> 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. >> >> Thanks, >> Carlos >> >> 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. >> >> >> On Mon, Aug 11, 2014 at 5:30 PM, Nitin Mehta >> wrote: >> >>> 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 ? >>> >>> Thanks, >>> -Nitin >>> >>> On 11/08/14 11:56 AM, "Carlos Reategui" wrote: >>> 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. 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. Things appear to be working ok, but want to check if any of you foresee any issues with the method I followed. thanks, Carlos >>> >>> >
Re: Import instances from previous deployment
This is superb Carlos. So you created dummy vms to create records in CS db and then changed the volume path to reflect the old vhds. Yes, I think it should be fine to delete the dummy vids created with the new instance. Thanks, -Nitin On 11/08/14 5:49 PM, "Carlos Reategui" wrote: >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. > >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. > >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. > >It was only 10 instances any more and I probably would have scripted >it. > >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. > >Thanks, >Carlos > >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. > > >On Mon, Aug 11, 2014 at 5:30 PM, Nitin Mehta >wrote: > >> 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 ? >> >> Thanks, >> -Nitin >> >> On 11/08/14 11:56 AM, "Carlos Reategui" wrote: >> >> >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. >> > >> >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. >> > >> >Things appear to be working ok, but want to check if any of you foresee >> >any >> >issues with the method I followed. >> > >> >thanks, >> >Carlos >> >>
Re: Import instances from previous deployment
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. 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. 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. It was only 10 instances any more and I probably would have scripted it. 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. Thanks, Carlos 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. On Mon, Aug 11, 2014 at 5:30 PM, Nitin Mehta wrote: > 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 ? > > Thanks, > -Nitin > > On 11/08/14 11:56 AM, "Carlos Reategui" wrote: > > >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. > > > >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. > > > >Things appear to be working ok, but want to check if any of you foresee > >any > >issues with the method I followed. > > > >thanks, > >Carlos > >
Re: Import instances from previous deployment
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 ? Thanks, -Nitin On 11/08/14 11:56 AM, "Carlos Reategui" wrote: >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. > >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. > >Things appear to be working ok, but want to check if any of you foresee >any >issues with the method I followed. > >thanks, >Carlos
