I am using Altiris Deployment Solution 6.9 SP5. I want to create a back up image of Linux OS/CentOS. I have created the job using the following tasks:
Reboot to automation
Create Disk Image
Reboot
The jobs is stuck at step 2 as the machine goes on sleep immediately after reboot. It tries to send Wake-on-Lan signal but that doesn't work.
Is there a way to keep the system alive until the job completes successfully.
The machine am trying to take back up of is a B series blade server. I could not find any power setting in the BIOS settings to enable Wake-on-Lan.
Please correct me if the process listed above to create a back-up image in DS 6.9 is incorrect.
A quick help is appreciated. Thanks!!
I used the option "Quick Disk Image" (right click on a computer) when i need to perform a backup. Set the job to do not schedule and then configure the task as needed.
Related
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.
Am trying to setup "AZure VM Agent" plugin in Azure.
Am done with all configurations and first time when i trigger a job, a slave on Azure gets created and it executes the job. But as soon as job execution completes, node goes into offline mode.
Now if I trigger another jenkins job, offline node is not coming online automatically and so jenkins job is stuck on "waiting for agent" or "agent is offline". After sometime, new agent comes and it takes its own time to get ready and all.
How can I configure slaves to go offline when no task and as soon as new task is available, use same slave node?
Node goes offline only after 'n' number of minutes where 'n' is based on the configuration that you have set in your Jenkins dashboard (under Manager Jenkins -> Configure System -> Cloud section). By default it is set to '60' as shown in below screenshot.
You would have to set it to '0' if you want the node to keep running. Also, make sure you tick the box for "Shutdown Only (Do Not Delete) After Retention Time".
I believe that it's better to manually not configure these slaves (i.e., by explicitly making it offline by either deallocating / shutting down the VM or by marking the node offline in Jenkins dashboard / etc.) because if we do so then as the node is supposed to be maintained by the Azure VM Agents Jenkins plugin as per the retention cycle but as it is disturbed manually so we may observe issues like "nodelabel is serviced by 1 node and 1 cloud. Permissions or other restrictions provided by plugins may prevent this job from running on those nodes", etc.
I have 3 agents in Lotus, these agents just update different CSV files on a shared drive. Based on their logs, they are running but only took a second. Checking the CSV files, they are not updating.
I've tried to adjust the schedule time
Tried other servers
Changed the Target
Disable/re-enable the agent
Made a copy of the agent
I haven't edit the code.
Workaround is to run these agents manually. It actually updates the CSV files and its taking at least 5 minutes for the agents to finish running which is expected. These agents just suddenly stop running as scheduled.
As Torsten mentioned, your Domino server does not have enough permissions. Per default it runs as local system, which does not have access to any shares.
See this technote before it disappears https://www.ibm.com/support/pages/domino-server-unable-locate-mapped-drives-when-started-windows-service
I am working on an azure deployment. I am using some templates from github that creates a certain number of VM's based on a 'master image', puts them behind a load balancer, and allows access to them through RDP and ports.
Now, all this is working great. I build my image, then I run sysprep and generalize it, shut it down, and spin up 40 copies.
The issue I am running into is what do I do if I want to update the 'master image'?
It won't let me boot it up, because it says it is generalized. And I am having a hard time setting up a new vm and attaching the OS disk "not sure if this is the right way"
Does anyone have any suggestions? I am coming from a VMware VDI environment, where I would just boot up the master, make changes, shut down, and snapshot and redeploy.
Also I am using the new Azure interface, which I believe is called AzureRM.
Error message: Operation Start VM is not allowed on VM xxx since the VM is generalized.
Like versioning, you have to create a new VM from the image made before, and then repeat the process again after your changes.
Well, its not pretty, but it should work:
Spin up a fresh copy. make your changes, then preform the sysprep / oobe process again, finally, generalize & capture.
I have an Ubuntu 14 VM on Azure to host my developed web sites. (I do not think the OS matters in the point of view the question, but never know)
I've discovered the relatively new Capture button, so for the storage price of a disk size I regularly save a "snapshot" via the Capture function (I am not preparing the image for provisioning, I mean not checking the "I have run 'waagent -deprovision' on the virtual machine" checkbox). Be aware quickly becomes pretty addictive.
The result is an image what I can use when creating new machines, its there in My Images in the wizard. This can function as a backup/rollback worflow. If I delete the VM and create a new from one of resulting image of the previously captured "snapshots". (again, no provisioning will take place)
It is possible to initiate the Capture operation on a running VM. It is not clear for me, if the result will be an image what is a template for a new VM, and that VM will start up and boot, in what state the filesystem etc will be?
Is not it a similar state than sudden power lost? If yes, then it is strongly recommended to always shutdown the VM before capturing, however this such a pain and productivity killer, so no one (including me) wants to do unless it is mandatory.
Accidentally I've switched to the new Azure portal and there the Capture UI says:
Capturing a virtual machine while it's running isn't recommended.