Please help: I started migrate asm to arm, the validation and prepare completed succesfully but the commit gave me the error "Template deployment failed". I opened support ticket that directs me to retry the migrate but it no longer allows me to do something. The message is now "Committing migration. This operation may take some time to complete." and not allows to retry. And now the Azure it won't let me restart the VM any more because it says that the migration is still in progress.
I currently have the vm asm and arm but neither allows me to start, the vm arm should be deleted to retry the migration but it is not happening
A person had the same problem in this forum but he did not comment how he solved it
Thanks for your help
At the moment it says to wait but I don't notice that the status is going to change
Related
I am trying to use azcopy to copy from Google Cloud to Azure.
I'm following instructions here and I can see in the logs generated that the connectivity to GCP seems fine, the SAS token is fine and it creates the container fine (see it appear in Azure Storage Explorer) but then it just hangs. Output is:
INFO: Scanning...
INFO: Authenticating to source using GoogleAppCredentials
INFO: Any empty folders will not be processed, because source and/or destination doesn't have full folder support
If I look at the log it shows:
2022/06/01 07:43:25 AzcopyVersion 10.15.0
2022/06/01 07:43:25 OS-Environment windows
2022/06/01 07:43:25 OS-Architecture amd64
2022/06/01 07:43:25 Log times are in UTC. Local time is 1 Jun 2022 08:43:25
2022/06/01 07:43:25 ISO 8601 START TIME: to copy files that changed before or after this job started, use the parameter --include-before=2022-06-01T07:43:20Z or --include-after=2022-06-01T07:43:20Z
2022/06/01 07:43:25 Authenticating to source using GoogleAppCredentials
2022/06/01 07:43:26 Any empty folders will not be processed, because source and/or destination doesn't have full folder support
As I say, no errors around SAS token being out of date, or can't find the GCP credentials, or anything like that.
It just hangs.
It does this if I try and copy a single named file or a recursive directory copy. Anything.
Any ideas, please?
• I would suggest you to please check the logs of these AzCopy transactions for more details on this scenario. To collect the logs and analyze them, you will have to check the logs stored in ‘%USERPROFILE%\.azcopy’ directory on Windows. AzCopy creates log and plan files for every job, so you will have to investigate and troubleshoot any potential problems regarding this scenario by analyzing them.
• As you are encountering hang issues with the AzCopy utility during a job execution for transferring files, it might be a network fluctuation issue, timeout issue or server busy issues. Please do remember that AzCopy retries upto 20 times in these cases and usually the retry process succeeds. Try to look for the errors in the logs that are near ‘UPLOADFAILED, COPYFAILED, or DOWNLOADFAILED’.
• The following command will get all the errors with ‘UPLOADFAILED’ status from the concerned log file: -
Select-String UPLOADFAILED .\<CONCERNEDLOGFILE GUID>.log
To show the jobs by status relating to the job ID, kindly execute the below command: -
azcopy jobs show <job-id> --with-status=Failed
• Execute the AzCopy job execution command from your local system with ‘--no-check-certificate’ argument which will ensure that there are no certificate checks for the system certificates at the receiving end. Ensure that the root certificates for the network client device or software are correctly installed on your local system as they are the only ones to block your jobs while transferring files from on-premises to Azure.
Also, once the job starts initially without any parameters, then when it hangs, just press CTRL+C to kill the process and then immediately check the logs in AzCopy as well as in the event viewer for any system issues. It will help you know the exact issue regarding this. It really shows why the process failed and got hung.
For more information, kindly refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-configure
https://github.com/Azure/azure-storage-azcopy/issues/517
Frustratingly, having many calls with Microsoft support, on demoing this to another person the exact same command with exact same SAS token etc that was previously failing just started to work.
I hate problems that 'fix themselves' as it means it will likely occur again.
Thanks to KartikBhiwapurkar-MT for a detailed response too.
I have a published AzureML experiment and now I want to schedule that experiment periodically and also want to give flexibility to admin to run that experiment when he wants.
I tried running experiment periodically using Logic App azure service but getting an error "This session has timed out. To see the latest run status, navigate to the runs history blade.". Can anyone help me out?
I am trying to run Azure Batch with custom VM. Sometime I got the below mentioned error
Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
If I retries booting VMs again it will work fine. It happens sometimes only.
How can I fix it?
This typically means that another process has locked the package database. The simplest method is to add retries around your start task code that is attempting to use the package database (apt or dpkg). If utilizing a custom image, you can look into disabling automatic updates or periodic package list updates. Please understand the consequences of performing the latter.
I am in trouble with the container options of Azure Batch.
To change the hostname of the container to be started, set --hostname="test" to the containerRunOptions of Task.
However, it is an error!
ContainerSettings: --hostname="test" Message: create_container() got an unexpected keyword argument 'hostname '
Even -h test will result in a similar error.
Other options work fine.(--volume etc...)
Pool Infomation:
Publisher:microsoft-azure-batch
OS:centos-container
sku:7-4
image:centos:latest(docker hub)
Is this a bug in Azure Batch?
Is the option to specify it wrong?
Updated answer (2018-08-23):
The fix for this issue has been rolled out.
Previous answer:
This was identified as a service defect and will be addressed in a future version. You can track the Azure Batch Node Agent release notes for when the fix is released.
If you are using Batch to execute tasks without performing deeper integration, e.g., you are using the Azure CLI or similar tooling, you can use Batch Shipyard in "non-native mode" to work around this problem in the meantime. (Disclaimer: I'm a contributor for this code).
As title really, I can't see how you can Roll Back an update to a Windows Azure service/site?
Each "update" has a title, so I'd thought you could see a list of these updates, but I just can't see it listed anywhere?
I use https://manage.windowsazure.com, and these are cloud services.
Details on Rollbacks can be found here: http://msdn.microsoft.com/en-gb/library/windowsazure/hh472157.aspx#RollbackofanUpdate
To quote:
Windows Azure provides flexibility in managing services during an update by letting you initiate additional operations on a service, after the initial update request is accepted by the Windows Azure Fabric Controller. A rollback can only be performed when an update (configuration change) or upgrade is in the in progress state on the deployment. An update or upgrade is considered to be in-progress as long as there is at least one instance of the service which has not yet been updated to the new version. To test whether a rollback is allowed, check the value of the RollbackAllowed flag, returned by Get Deployment and Get Hosted Service Properties operations, is set to true.
Note
It only makes sense to call Rollback on an in-place update or upgrade because VIP swap upgrades involve replacing one entire running instance of your service with another. For more information about swapping VIPs, see How to Deploy a Service Upgrade to Production by Swapping VIPs in Windows Azure.
There is no stack maintained of your previous deployments, if however your present deployment somehow fails than the fabric may use your previous deployment(It tries to initialize previous states). Your roles are just VHD(Virtual hard disk) with a copy of OS and your installation files running virtually, whenever you update, a new VHD is allotted and the previous is destroyed(if update was successful). Thus there is no way to get the previous deployments(its destroyed). You should store your previous builds locally or on a foundation server just in case you need it like you now.