{"id":1117,"date":"2020-06-22T17:08:12","date_gmt":"2020-06-23T00:08:12","guid":{"rendered":"http:\/\/blog.nillsf.com\/?p=1117"},"modified":"2020-06-22T17:08:20","modified_gmt":"2020-06-23T00:08:20","slug":"vm-broken-use-os-disk-swap-in-azure-to-fix-and-restore","status":"publish","type":"post","link":"https:\/\/blog.nillsf.com\/index.php\/2020\/06\/22\/vm-broken-use-os-disk-swap-in-azure-to-fix-and-restore\/","title":{"rendered":"VM Broken? Use OS disk swap in Azure to fix and restore"},"content":{"rendered":"\n

I can’t begin to count the amount of times I screwed up a virtual machine that wouldn’t boot anymore. In most cases, that was due to messing up \/etc\/fstab<\/code>, which controls which disks get mounted in Linux. If that file is broken, your machine won’t boot anymore. <\/p>\n\n\n\n

In Azure, there’s an ability to swap the OS disk of a machine. That means you can swap in a working drive to fix the issues with your VM. I hope you never need to use it, but if you need it, it’s there for you.<\/p>\n\n\n\n

In this post, I want to quickly explain how to do this and how you can use OS disk swap to get your VM back to a working state.<\/p>\n\n\n\n

Process for fixing issues<\/h2>\n\n\n\n

Let’s walk through the process I typically use in cases where I need to swap the OS drive:<\/p>\n\n\n\n

  1. Take a snapshot of the broken OS disk.<\/li>
  2. Create a new disk based of this snapshot. <\/li>
  3. Attach new disk to a working VM.<\/li>
  4. Fix issues in working VM.<\/li>
  5. Detach disk.<\/li>
  6. Swap OS disk.<\/li><\/ol>\n\n\n\n

    In summary, I create a copy of the disk, fix the issues and then swap the OS drive. You cannot detach the OS drive from a VM, since a VM always needs to have an OS drive (except for VMs using ephemeral storage). <\/p>\n\n\n\n

    With the process covered, let’s have a look at a working example:<\/p>\n\n\n\n

    Fixing a broken VM using OS disk swap<\/h2>\n\n\n\n

    Breaking my VM<\/h3>\n\n\n\n

    For my test setup, I pre-created 2 VMs running Ubuntu 18.04. Let’s login to the VM we plan to break, and make a change in \/etc\/fstab<\/code>. I’ll remove the last digit of the ID of the boot disk.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    And then I’ll do a reboot of the VM (in my case, from the Azure portal). This will cause the reboot, and this should cause the disk failure to present itself. I wasn’t expecting the VM to actually boot – but it did – and I could still connect to it using SSH. But while working on the VM, I ran into many issues. Just one of those was that I couldn’t restore the fstab file. Apperently the file system was mounted read-only, not read-write. <\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Also, trying to run sudo apt update<\/code> resulted in many errors:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    In summary, not the issue I was expecting, but broken nonetheless. Let’s go ahead and fix it!<\/p>\n\n\n\n

    Take a snapshot of the broken OS disk<\/h3>\n\n\n\n

    First step is to take a snapshot of the OS disk. This can be done either via PowerShell\/CLI or in the portal. For the purpose of this post, I’ll use the portal route. <\/p>\n\n\n\n

    To take the snapshot, first navigate to your broken OS disk. You can get there via the Disks part of the VM blade:<\/p>\n\n\n\n

    \"\"
    Go to the OS disk.<\/figcaption><\/figure>\n\n\n\n

    In the resulting disk blade, you’ll see the ‘Create snapshot’ option. Click that.<\/p>\n\n\n\n

    \"\"
    Create a snapshot<\/figcaption><\/figure>\n\n\n\n

    In the next blade, provide the necesarry details for the snapshot and hit Review and Create.<\/p>\n\n\n\n

    \"\"
    Provide details for the snapshot<\/figcaption><\/figure>\n\n\n\n

    Create a new disk based of this snapshot<\/h3>\n\n\n\n

    Next up, we’ll create a disk from this snapshot. This cannot be done from the snapshot blade itself, you’ll have to navigate to the disk blade for this. To get there, just type disks in the search bar. <\/p>\n\n\n\n

    \"\"
    Look for the disks blade<\/figcaption><\/figure>\n\n\n\n

    Once there, hit the Add button on the top.<\/p>\n\n\n\n

    \"\"
    Create a new disk.<\/figcaption><\/figure>\n\n\n\n

    What you’ll need to do here is set the source type to snapshot, and refer to the snapshot we just created.<\/p>\n\n\n\n

    \"\"
    Create a new disk based on the snapshot.<\/figcaption><\/figure>\n\n\n\n

    Hit create, and give it some time to create. Then we can attach it to the working VM.<\/p>\n\n\n\n

    Attach new disk to a working VM<\/h3>\n\n\n\n

    In the VM blade of the VM that you’ll use to fix this issue, navigate to the disks blade and hit the “Attach existing disks” button. Look for the disk we just created, and hit the save button. <\/p>\n\n\n\n

    \"\"
    Attach the existing disk, and hit the save button.<\/figcaption><\/figure>\n\n\n\n

    Give it a couple seconds to attach the disk. Once the disk is attached, connect to your VM, and mount the new disk. The commands I typically use for this:<\/p>\n\n\n\n

    sudo fdisk -l \n#now look for the \/dev\/sdX of the new disk.\nsudo mkdir \/mnt\/broken-disk\nsudo mount \/dev\/sdX1 \/mnt\/broken-disk<\/code><\/pre>\n\n\n\n
    And with the mount done, we can now fix the issue.<\/p>\n\n\n\n
    Fix issues in working VM.<\/h3>\n\n\n\n
    Fixing the issue in this case is as easy as adding the digit back into the \/etc\/fstab<\/code> file. In this case, that file will be at location \/mnt\/broken-disk\/etc\/fstab<\/code>.<\/p>\n\n\n\n
    I added the ‘3’ back in, and saved the updated file. Let’s move to the next step.<\/p>\n\n\n\n
    Detach disk<\/h3>\n\n\n\n
    To detach the disk, navigate back to the disk blade on the fixing VM. On the line of the disk we just attached, navigate to the right part of the screen, hit the ‘X’ and hit the save button.<\/p>\n\n\n\n
    \"\"
    Detach the disk<\/figcaption><\/figure>\n\n\n\n
    With the disk detached, we can now swap the OS drive.<\/p>\n\n\n\n
    Swap OS disk<\/h3>\n\n\n\n
    Navigate to your broken VM, open the disks section of the VM blade and hit the Swap OS disk button.<\/p>\n\n\n\n
    \"\"
    Hit the Swap OS disk button<\/figcaption><\/figure>\n\n\n\n
    Pick the disk you want to swap in, and confirm the action by typing in the VM name.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Interestingly enough, hitting the OK button for this, will cause Azure to stop your VM first. I was wondering if this was going to create an error because my VM was still running, but Azure was smart enough to first stop the VM.<\/p>\n\n\n\n
    \"\"
    Azure will stop the VM if it is still running.<\/figcaption><\/figure>\n\n\n\n
    Once the VM is stopped, this will trigger the OS disk swap:<\/p>\n\n\n\n
    \"\"
    After the VM is stopped, the swap will happen.<\/figcaption><\/figure>\n\n\n\n
    It doesn’t trigger an automatic start of the VM, so hit the start button to see if our issues have been fixed. And in my case – as expected – everything worked normally again. I could do my apt-get update without issue (where it failed earlier).<\/p>\n\n\n\n
    \"\"
    Everything working fine again.<\/figcaption><\/figure>\n\n\n\n
    Summary<\/h2>\n\n\n\n
    There’s numerous ways in which you could mess up a VM and make it unable to boot. Having the swap OS disk option is a great option to quickly fix issues. This shouldn’t deter you from setting up good back-up and restore capabilities (e.g. Azure backup), however, swapping the OS disk can be a great quick fix to a number of issues.<\/p>\n\n\n\n
    Although I described a Linux focused solution here, you can do the same thing with Windows boxes, if you know which files to fix.<\/p>\n","protected":false},"excerpt":{"rendered":"
    I can’t begin to count the amount of times I screwed up a virtual machine that wouldn’t boot anymore. In most cases, that was due to messing up \/etc\/fstab, which controls which disks get mounted in Linux. If that file is broken, your machine won’t boot anymore. In Azure, there’s an ability to swap the […]<\/p>\n","protected":false},"author":1,"featured_media":1130,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[2,4],"tags":[8,126,125,127],"class_list":["post-1117","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","category-management","tag-azure","tag-backup","tag-disk","tag-snapshot"],"jetpack_featured_media_url":"https:\/\/nillsfblog.blob.core.windows.net\/media\/2020\/06\/image-51.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/1117","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/comments?post=1117"}],"version-history":[{"count":1,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/1117\/revisions"}],"predecessor-version":[{"id":1136,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/1117\/revisions\/1136"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/media\/1130"}],"wp:attachment":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/media?parent=1117"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/categories?post=1117"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/tags?post=1117"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}