Consequences of forced migration of resources from the ru-central1-c zone
If you have not migrated your resources from the ru-central1-c availability zone before the deadline, we will migrate them forcibly. For more information about the possible risks of forced migration, see Forced migration risks.
This page explains what you may need to do to restore your infrastructure after a forced migration.
Forced migration of VMs, disks, and subnets
Snapshots have been taken of all your disks. You can find them in the management console, under Yandex Compute Cloud Snapshots.
Where possible, your VMs, disks, and subnets were moved to the ru-central1-d zone. Check whether you can access them and everything works well. However, due to forced migration risks, your resources may not be available. In this case, restore them from the snapshots.
Your static public IP addresses from the ru-central1-c zone may not be available. If required, reserve new static external IP addresses from the ru-central1-d zone and assign them to your resources.
If you are unable to restore your infrastructure after a forced migration, contact technical support.
Forced migration of managed service resources
For a forced migration, we could create special subnets in the ru-central1-a, ru-central1-b, and ru-central1-d zones. Your resources were moved to them from the Yandex Managed Service for Kubernetes, Yandex Instance Groups, Yandex Managed Service for GitLab managed database services located in the ru-central1-c zone. Make sure your resources are working correctly.
However, due to forced migration risks, your resources may not be available: both the public and internal IP addresses of your resources may have changed. If you need help with recovery from backups, contact technical support.
Forced migration of Yandex Application Load Balancer
We have disabled incoming traffic for your L7 load balancers in the ru-central1-c zone. If you need to enable incoming traffic in the ru-central1-d zone, do it yourself.
Forced migration of Yandex Data Transfer
If during forced migration your transfers in Data Transfer stopped working, restart them.
FAQ
Why do I get the Access Denied error?
As long as your VMs, disks, and subnets from the ru-central1-c zone are in the active phase of forced migration, you will not be able to use or modify them. You will get an error if you attempt to modify them: this is to be expected. Wait until the active phase is over and the resources are in the ru-central1-d zone. Then you can modify them again.
The active phase of forced migration can take up to several days. It will begin on an individual schedule for each client after the migration deadline.
If your resources are already in the ru-central1-d zone, but you still cannot modify them, contact technical support.
What will happen to resources on the standard-v1 (Intel Broadwell) platform?
The old standard-v1 (Intel Broadwell) platforms are not supported in the ru-central1-d zone. If we forcibly migrate resources based on such platforms into the ru-central1-d zone, they will not be able to run there. You will get the platform "standard-v1" is unavailable in zone “ru-central1-d” error if you try to run them. If you encounter this, change the VM and select a different platform, preferably standard-v3 (Intel Ice Lake), set the required number of cores and memory size, save the new configuration, and try running the VM again.
If you cannot run the VM after changing the platform, contact technical support.