disk_layout: align partitions and disk sizes to 2MB

The VHD format actually uses 2MB blocks internally so the 1MB alignment
used in e77e4e5 wasn't sufficent to prevent other tools from further
adjusting the image size to align it. Additionally a 1MB alignment may
be triggering a bug in OpenStack or XenServer disk resizing that renders
that partial block at the end of the old image size unmapped/unavailabe.

build_library/disk_layout.json

@@ -1,9 +1,9 @@
 {
   "_comment": "See http://www.chromium.org/chromium-os/building-chromium-os/disk-layout-format",
   "metadata":{
-    "_comment": "Partitions are aligned to 1MB (2048 blocks), disks sizes should align to *both* 1MB and a CHS cylender boundry for the common 16H 63S geometry (16*63 = 1008 blocks). The least common multiple of 2048 and 1008 is 129024 blocks.",
-    "part_alignment": 2048,
-    "disk_alignment": 129024,
+    "_comment": "Partitions are aligned to 2MB (4096 blocks). For the sake of VHD disks sizes should align to *both* 2MB and a CHS cylender boundry for the common 16H 63S geometry (16*63 = 1008 blocks). The least common multiple of 4096 and 1008 is 258048 blocks.",
+    "part_alignment": 4096,
+    "disk_alignment": 258048,
     "block_size": 512,
     "fs_block_size": 4096
   },
@@ -64,7 +64,7 @@
       "9":{
         "label":"ROOT",
         "type":"coreos-resize",
-        "blocks":"4302848",
+        "blocks":"4427776",
         "fs_type":"btrfs",
         "fs_subvolume":"root",
         "mount":"/"
@@ -73,19 +73,19 @@
     "vm":{
       "9":{
         "label":"ROOT",
-        "blocks":"12689408"
+        "blocks":"12943360"
       }
     },
     "azure":{
       "9":{
         "label":"ROOT",
-        "blocks":"58752990"
+        "blocks":"58875904"
       }
     },
     "vagrant":{
       "9":{
         "label":"ROOT",
-        "blocks":"33591296"
+        "blocks":"33845248"
       }
     },
     "onmetal":{