Jump to content
Welcome to our new Citrix community!
  • 0

Migrating a Provisioning Services Database - is an outage really needed?


Frank Mazzucco

Question

Hello,

 

We are looking to migrate a Provisioning Services Database from a SQL 2012 server to a SQL 2017 Server. This farm consists of two servers running 1912 LTSR CU1.

 

I have never had the need to migrate a PVS database before, so I referenced this Citrix article for guidance on how to do this: https://support.citrix.com/article/CTX130499 

Unfortunately, it appears that best practice is to shut down all of the Target Devices before the migration.

 

If possible, we would like to avoid an outage for this, so I opened a ticket with Citrix. I was just looking for some reasoning behind the need to shut down the Target Devices. The response was as follows:

 

I did check internally as well, as PVS servers talk to each other, so unsure if having some using one db and some using another could create any problems.You will need to set a cut off time perform this task because the target devices communicate with the PVS streaming service which writes to the PVS database. No records should be written to the database during the DB migration process, therefore we recommenced to shutdown the target devices during the time you are pointing the PVS servers to the new SQL server.

 

Taking this into consideration, it does not appear that this would affect existing machines that are already online. Especially when you consider that we have enabled Offline Database Support. I do not mind if new VMs cannot power on during this time. The outage itself will be brief, perhaps 10-15 minutes. Also, we were planning on shutting down the second server before the migration. Then once the first server has been migrated, and we have tested powering on/powering off target devices, we would power on the second server and point it to the new database location. Then once again deal with any VMs that are conflict.

 

So my question is has anyone performed a migration before, without shutting down all of the Target Devices? If so, were they any major problems as a result? Minor problems with VMs now having a correct power state, being incorrectly marked as locked, etc. - that can be fixed by rebooting the affected VMs are not a huge deal, when the alternative is shutting down every session in the environment.

 

Any help is appreciated.

Thank you

 

Frank

 

Link to comment

6 answers to this question

Recommended Posts

  • 0

Shutting down all target devices is more of a requirement from a support perspective, rather than a best practive.

Leaving the environment up may have potential to lead to environment instability, and then first action support would follow, would be to shut down all target devices.
Perhaps some scenarios and instances this would go through without difficulty, but for a production environment it may carry too much risk to not have scheduled down time, as opposed to the possibility of having unscheduled down time.

 

 

Link to comment
  • 0

Hello, 

 

We came up with a list of steps that we thought made sense with regards to keeping the PVS site online(target devices) during the migration. We migrated the PVS database in our less critical site first. It went well. Based off of that success we did the same for our main PVS site. 

 

In summary, we were able to migration multiple PVS databases while keeping the environments online.

Link to comment
  • 0
On 8/31/2020 at 8:49 AM, Frank Mazzucco said:

Hello, 

 

We came up with a list of steps that we thought made sense with regards to keeping the PVS site online(target devices) during the migration. We migrated the PVS database in our less critical site first. It went well. Based off of that success we did the same for our main PVS site. 

 

In summary, we were able to migration multiple PVS databases while keeping the environments online.

 

Hey Frank, what was the process you followed for the upgrade? Did you rebalance devices after upgrading each PVS server? My concern is having too many VMs run on a single PVS server. I was considering taking the existing DB offline and letting offline db support run. Then migrate the first PVS server, rebalance, rinse and repeat.

Link to comment
  • 0

just for the record because apparently there are no answers to this on the whole internet.

I don't think its supported but wasn't a problem whatsoever with 3 PVS Servers and ~250 running Targets:

 

-copy the database to your new SQL Server

-stop streaming service on your first PVS

-run the provisioning configuration wizard and join an existing farm

-obviously enter your new SQL Server(s)

-the Servers overview (on the migrated PVS) should show your first PVS online with the others offline

(-restart some targets, they should connect to your first PVS in the "new" Farm)

-stop streaming service on the next PVS, all targets should connect to the first (or third) PVS without any hickups

-run the provisioning configuration wizard and join an existing farm

-and so on, repeat this until you are done

 

cheers

Link to comment
  • 0

The above steps still require us to reboot all our target devices. As devices are in use this isn't an option for us. We are a hospital and cannot have any downtime.

 

Has anyone migrated the PVS database without having to shutdown/reboot the Target Devices during the migration?

Link to comment
  • 0
On 3/8/2023 at 12:22 AM, Steven Mudde said:

The above steps still require us to reboot all our target devices. As devices are in use this isn't an option for us. We are a hospital and cannot have any downtime.

 

Has anyone migrated the PVS database without having to shutdown/reboot the Target Devices during the migration?

I just used the instructions this evening on two environments.  Didn't have to reboot my target devices.  As I stopped the streaming services the streams slowly bump over to the migrated servers.  For example.. Say you have (4) PVS servers with 100 targets each. 

  • Stop PVS1, point to new SQL server, the remaining 3 PVS servers on the first DB server now have 133 targets each. 
  • Stop PVS2, point it to new SQL server, the remaining 2 PVS servers on the first DB had around 150 targets each, but PVS1 on the new SQL server ended up with ~50 targets. 
  • Stop stream on PVS3, point to new SQL server.  The remaining PVS server on the first DB had around 200 targets, PVS1-2 now had about 100 targets. 
  • When you do the 4th, they will load balance across the 3 that were already on the new SQL server. 
  • After the 4th is done, do a rebalance and they'll spread out evenly. 

 

I did end up rebooting a couple just for sanity checks to prove it worked and pvs targets boot.  Didn't seem to be necessary though. 

 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...