I made a VM for making a Image in Azure.
After I made the linux vm(Redhat), I stop the vm and made image.
But I failed making the vm from image.
Both cases have the same problems
-1st case:I didn't install anything.
-2nd case:I install something and made ssh key(rsa)
If i execute this command 'sudo waagent -deprovision+user', there is no error.
BUT my ssh key disappear so my VMs from image cannot connect each other, which means that I cannot generate a cluster by using Ambari.
Is there any way to solve this problem?
this is error I got when I failed making a VM from image.
--------error---- Provisioning failed. OS Provisioning for VM 'master0' did not finish in the
allotted time. However, the VM guest agent was detected running. This
suggests the guest OS has not been properly prepared to be used as a
VM image (with CreateOption=FromImage). To resolve this issue, either
use the VHD as is with CreateOption=Attach or prepare it properly for
use as an image: * Instructions for Windows:
https://azure.microsoft.com/documentation/articles/virtual-machines-windows-upload-image/
* Instructions for Linux: https://azure.microsoft.com/documentation/articles/virtual-machines-linux-capture-image/.
OSProvisioningTimedOut
Before you create a image, you should execute sudo waagent -deprovision+user. If you don't do it, you will get this error.
According to your scenario, you could configure Provisioning.RegenerateSshHostKeyPair=n (/etc/waagent.conf). According this official document
deprovision: Attempt to clean the system and make it suitable for
re-provisioning. This operation deleted the following:
All SSH host keys (if Provisioning.RegenerateSshHostKeyPair is 'y' in
the configuration file)
If it does not work for you, I suggest you could add publickey to your VMs by using Azure Portal.
Related
So I am converting custom built .iso to .raw. Deployed a VM on OpenStack using this .raw but I am unable to ssh into this machine.
I used GUI console and was able to login to this OpenStack VM using username and password. Once I am logged in, I restarted the cloud-init service and that resolved the ssh issue. I can ssh into the machine just fine.
Now the question is how do I make sure that enabling and restarting the cloud-init service are as part of first boot when deploying VMs on OpenStack.
I know I can pass the script when using UI to deploy VMs on OpenStack website but the requirement is this should be as part of the image itself. That means, I should just deploy a vm using .raw and the enabling and starting of cloud-init service should be part of the .raw image itself.
I am new to Linux or IT in general. Any suggestions are much appreciated.
Welcome to SO.
Maybe the keypoint is that cloud-init system which is an open-source package from Ubuntu that is available on various Linux distributions was installed or configured wrong. You should be sure that the cloud-init system which running in .iso image was working before convert to .raw format.
how do I make sure that enabling and restarting...
If you want to find it out, you could create instance with --user-data parameter.
VM is set to start every morning at 8am. This morning I got the following error : -
'Fatal error C0000034 applying update operation 63 of 82641' in the Boot Diagnostics section in the VM Console
Every previous occurrence I found googling the error did not relate to an Azure VM but a standalone laptop. All of these suggest starting from a different partition or rescue disk which is not possible in my case.
Tried re-starting the VM
Redeploying the VM
Resizing the VM
Whatever I try I still can't RDP to the VM.
I can't restore the C: drive as I can't connect to the VM to do it.
Any ideas how I can recover from this or rescue the VM ? All greatly appreciated.
Thanks,
Dan.
I've managed no to resolve this so will post the Solution in here for anyone else
Found the error in the Microsoft Docs here :-
https://learn.microsoft.com/en-gb/troubleshoot/azure/virtual-machines/troubleshoot-stuck-updating-boot-error?WT.mc_id=Portal-Microsoft_Azure_Support
This advised taking a copy of the OS Disk and attaching it as a Data Disk to a 'Rescue VM'
Running the following Powershell command against the Disk in
dism /image::\ /get-packages > c:\temp\Patch_level.txt
Open the file , scroll to the bottom and look for updates that are Install Pending or Uninstall Pending
Running the following Powershell command
dism /Image::\ /Remove-Package /PackageName: where PackageName is the Package Identity in the text file
Detach the now repaired OS Disk from the Repair VM and Attach it to the Original VM
Start the VM - it may take a while to start.
With the oncoming tide of Managed Disks, I don't suppose there will be much call for this solution , but it's here if anyone needs it.
I have a Azure VM and Im experiencing a slow connection to VM via SSH.
I can connect using ssh or putty, but after some time VM drop the connection. Sometimes I get a connection timeout when I'm trying to connect to VM.
To try to identify the problem I created a new VM and tried to connect through the private interface, but I'm still having the same problem.
To illustrate the problema see the scp command:
escola#othervm:~$ scp escola#10.0.0.4:backup/backup.dmp.gz .
backup.dmp.gz 1% 1520KB 144.7KB/s 12:45 ETA
the command is executed and after a while download stops.
Any Help ?
Based on my experience, you may increase the VM size to provide more memory for your VM. If it does not make sense. You could try the following solutions and refer to this.
Edit /etc/ssh/sshd_config to set the a large value of ClientAliveCountMax. The value is per minute. Then restart ssh service with service sshd reload.
On the user .ssh directory, add ServerAliveInterval 60 in the config file in /user/.ssh/config
For more information, you could read detailed SSH troubleshooting steps for issues connecting to a Linux VM in Azure.
I'm trying to deploy the current version of Elastic Search in an Azure Container Instance using the Docker image, however, I need to set vm.max_map_count=262144. Although since the container continually tries to restart on max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144] I can't hit the instance with any commands. Trying to disable restarts or continuing on Errors causes the container instance to fail.
From the comments it sounds like you may have resolved the issue. In general for future readers a possible troubleshooting guide is:
If container exits unsuccessfully
Try using EXEC for interactive debugging while container is running. This can be found in the Azure portal as well on the "Containers" tab.
Attempt to run to success on local docker if EXEC did not help.
Upload new container version after local success was found to your registry and try to redeploy to ACI.
If container exits successfully and repeatedly restarts
Verify you have a long-running command for the container.
Update the restart policy to Never so upon exit you can debug the terminated container group.
If you cannot find issues, follow the local steps and get a successful run with local Docker.
Hope this helps.
After upgrading my Ubuntu 14.04 LTS machine hosted on Azure (previous update was two weeks ago on Feb. 22nd), it now warns me about changed server SSH key when I try to connect to it.
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
I am ruling out the Ubuntu update triggering this change because this happened with my (only) Azure machine, but not the rest of about a dozen Linux servers that run either locally or on AWS with nearly identical configuration that were updated at the same time. I have also checked the host key algorithm as reported by ssh -v and it is unchanged (ECDSA-SHA2-NISTP256).
Is there anything specific about the way Azure handles SSH connections, or something particular about the Ubuntu image provided by Azure that could have led to the change in the server key?
P.S. I am downloading the VHD to check the machine locally, but this will take at least 24 hours with my connection. I was just wondering, maybe somebody has run into the same issue before.
It turns out that the keys were regenerated by cloud-init. As far as I can tell it was due to this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1551419
I would like to be able to provide a less painful solution than downloading the VHD and checking the server fingerprint, but unfortunately the Azure portal still displays the fingerprint for the original key that was created when the instance was first provisioned.