Partitioning in New ESXi 5.0 Installations

In new installations, several new partitions are created for the boot banks, the scratch partition, and the locker. New ESXi 5.0 installations use GUID Partition Tables (GPT) instead of MSDOS-based partitioning. The partition table is fixed as part of the binary image, and is written to the disk at the time the system is installed. Therefore we do not have any option to configure any customized partition in ESXi5.0. The ESXi installer leaves the scratch and VMFS partitions blank, and ESXi creates them when the host is rebooted for the first time after installation or upgrade. The scratch partition is 4GB. The rest of the disk is formatted as a VMFS5 partition.

ESXi5.0 was installed on 40 GB disk. From 40 GB, 4 GB is used for scratch and 4 GB for OS i.e. datastore1. It means dedicated partitions are created.

---

NOTE The installer can create multiple VFAT partitions. The VFAT designation does not always indicate that the partition is a scratch partition. In some cases, a VFAT partition can lie idle.

---

What happens to Partitioning in Upgraded ESXi 5.0 Hosts scenarios

Upgraded systems do not use GUID Partition Tables (GPT), but retain the older MSDOS-based partition label. For most ESXi 4.x hosts, the partition table is not rewritten in the upgrade to ESXi 5.0. The partition table is rewritten for systems that have lopsided bootbanks. Lopsided boot banks can occur in systems that are upgraded from ESXi 3.5 to ESXi 4.x, and then upgraded directly to ESXi 5.0. For ESX hosts, the partitioning structure is changed to resemble that of an ESXi 4.x host. The VMFS3 partition is retained and a new MSDOS-based partition table overwrites the existing partition table.

For classic ESX hosts, any data stored in custom user created partitions inside the Service Console is not preserved in the migration to ESXi 5.0.
Upgraded hosts do not have a scratch partition.

 

Instead, the scratch directory is created and accessed off of the VMFS volume. ESX was installed on 40 GB Disk, 4 GB is used by scratch partition and 4 GB as root partition as Storage1 VMFS as seen below.

Each of the other partitions, such as the bootbanks, locker and vmkcore are identical to that of any other system.

In upgraded hosts, the VMFS partition is not upgraded from VMFS3 to VMFS5. ESXi 5.0 is compatible with VMFS3 partitions.

 

You can upgrade the partition to VMFS5 after the host is upgraded to ESXi 5.0.

---

NOTE The ESXi 5.0 installer cannot detect ESX 2.x instances or VMFS2 datastores. You cannot migrate ESX 2.x instances to ESXi 5.0 or preserve VMFS2 datastores in an upgrade to ESXi 5.0. Instead, perform a fresh installation of ESXi 5.0.

---

For the VMFS partition on the disk to be preserved during an upgrade to ESXi 5.0, the partition must be physically located after the boot partition, which is partition 4, and the extended partition on the disk (8192 + 1835008 sectors). Any system that has a VMFS partition after the 1843200 sector mark can keep that VMFS partition, regardless of whether it was initially installed with ESX 3.5 or 4.x. For systems in which the VMFS partition is placed on a different drive from the boot drive, the entire contents of the boot drive is overwritten during the upgrade. Any extra data on the disk is erased.

migration FROM CLASSIC ESX4.0 TO ESXI5.0 SCREEN CAST-post 02

NETWORKING CHANGES

AFTER MIGRATION SERVICE CONSOLE IS CHANGED TO MANAGEMENT NETWORK

---

DNS & ROUTING CHANGES

DOMAIN INFORMATION WAS LOST DURING MIGRATION

---

FIREWALL CHANGES

 

ALL CHANGES MADE IN FIREWALL GUI GETS CARRIED OVER E.G. NFS CLIENT, SSH CLIENT

---

HOST SUMMARY SCREEN CHANGES

MEMORY UTILIZATION FOUND INCREASED

Networking Changes in ESXi 5.0

Networking Changes in ESXi 5.0
Some ESX 4.x and ESXi 4.x network settings stored in /etc/sysconfig/network are migrated in the upgrade or migration to ESXi 5.0. In the migration to ESXi 5.0, ESX Service Console virtual NICs (vswifs) are converted to ESXi virtual NICs (vmks).The distributed port group or dvPort that the virtual NICs connect to is also migrated. The Service Console port group is renamed as the Management Network port group. When vswifs are migrated to vmks, they are numbered to follow any existing vmk in sequence.

---

For example, if the version 4.x ESX host has virtual NICs vmk0, vmk1, and vswif0, after the migration the new ESXi configuration will be vmk0, vmk1, and vmk2, where vmk2 is the management interface.

---

When you upgrade from ESXi 4.x to ESXi 5.x, the default maximum number of ports for a virtual switch changes from 64 to 128.
ESX hosts have two IP stacks, one for the vmkernel and one for the Service Console. Because ESXi hosts have only one IP stack, the migration cannot preserve both ESX default routes. After migration, the ESX Service Console default route becomes the single ESXi default route, replacing the vmkernel route. The change to a single ESXi default route might cause loss of connectivity for routed non-management traffic that originates from vmkernel. To restore vmkernel networking, you can configure static routes in addition to the default route.
All vswif interfaces are migrated to vmk interfaces. If a conflict is detected between two interfaces, one is left in disabled state. The upgrade disables any conflicting kernel IP addressing in favor of the management interface.
The migration to ESXi 5.0 disables any existing vmk virtual NIC that meets the following conditions.

• The vmk virtual NIC has a manually configured (static) IP address.
• The IP address is in the same subnet as a vswif virtual NIC that is being migrated to a switch containing the vmk virtual NIC.
• The vmk and vswif NICs are both on the same virtual switch.

---

For example, if vswif0, with IP address 192.0.2.1/24 on vswitch1, is migrated to a switch containing vmk0, with IP address 192.0.2.2/24, also on vswitch1, after the migration, vmk0 will be disabled.

---

ESX 4.x Service Console Port Group Removed in Migration to ESXi 5.0

Because ESXi 5.0 has no Service Console, migrating from ESX 4.x to ESXi 5.0 removes the Service Console port group. After the migration to ESXi 5.0, a new port group, the Management Network port group, is created.

Configuration Changes After Migration or Upgrade to ESXi 5.0

Firewall Configuration Changes After Migration or Upgrade to ESXi 5.0

The migration or upgrade from ESX/ESXi 4.x to ESXi 5.0 results in several changes to the host firewall configuration. When you migrate from ESX 4.x to ESXi 5.0, the ESX 4.x rulesets list is replaced by the new rulesets list in ESXi5.0.

The following configuration from the /etc/vmware/esx.conf file is preserved:

• · The existing enabled/disabled status.
• · The allowedip added by esxcfg-firewall.

Ruleset files that are added by the user and customized firewall rules created in ESX 4.x. are not preserved after the migration. In the first boot after the migration, for those rulesets that don’t have entries in the ESX 4.x /etc/vmware/esx.conf file, the ESXi 5.0 firewall loads the default enabled status.

After the migration to ESXi 5.0, the default block policy is set to false (PASS all traffic by default) on ESXi 5.0 only when both blockIncoming and blockOutgoing values of the default policy are false in the ESX4.x /etc/vmware/esx.conf file. Otherwise the default policy is to deny all traffic. Custom ports that were opened by using the ESX/ESXi 4.1 esxcfg-firewall command do not remain open after the upgrade to ESXi 5.0. The configuration entries are ported to the esx.conf file by the upgrade, but the corresponding ports are not opened.

---

IMPORTANT The ESXi firewall in ESXi 5.0 does not allow per-network filtering of vMotion traffic. Therefore, you must install rules on your external firewall to ensure that no incoming connections can be made to the vMotion socket.

---

Resource Pool Settings Affected by the Upgrade from ESX 4.x to ESXi 5.0

After the upgrade to ESXi 5.0, ESX 4.x resource pool settings might be insufficient to start all virtual machines in the pool. The upgrade to ESXi 5.0 affects the amount of memory available to the host system. You can find this alert by pressing Alt + F11 in the ESXi direct console.

SSH Configuration Affected by Upgrading or Migrating to ESXi 5.0

The host SSH configuration is migrated only for upgrades from ESXi 4.1 to ESXi 5.0. SSH configuration is not migrated for ESX 4.x hosts or ESXi 4.0 hosts. For these hosts, SSH access is disabled during the upgrade or migration process. You can re-enable SSH access in the direct console.