vSphere Update Manager is not migrated. If you use Update Manager in your environment, there are more steps you must perform to manually move Update Manager to a new destination machine.
Local Windows OS users and groups are not migrated to the SLES OS of the vCenter Server Appliance 6.0. If you assigned vCenter Server permissions to any Local Windows OS users and groups, remove the permissions assignments before the migration. You can re-create Local OS users and groups on the SLES OS of the vCenter Server Appliance 6.0 after the migration.
The migration process migrates only one network adapter settings to the target vCenter Server Appliance. If the hostname of the source vCenter Server resolves to multiple IP addresses across multiple network adapters, you have the option to select which IP address and network adapter seĴings to migrate. After the migration, you can add the rest of the network adapters and seĴings to the target vCenter Server Appliance.
Migration of deployments that use custom ports for services other than Auto Deploy, Update Manager, and vSphere ESXi Dump Collector are not supported.
After the migration, the source vCenter Server is turned off and cannot be turned on to avoid network ID conflicts with the target vCenter Server Appliance. After the source vCenter Server is turned offǰ all solutions that are not migrated become unavailable.
You cannot use the source virtual machine display name as a display name for the target appliance. You can change the display name after the migration is complete.
What if somebody downloaded entire VM or just vmdk file to a removable media. Oops.....your organization data might be in the wrong hands. What is the solution to strengthen the security. So the answer is VM Encryption. It is one of the method that can be used to get the required protection for the VM.
VM Encryption is a VM-agnostic method of encryption for VMs that is scalable, easy to implement, and easy to manage. With vSphere Virtual Machine Encryption, you can create encrypted virtual machines and encrypt existing virtual machines. Because all virtual machine files with sensitive information are encrypted, the virtual machine is protected. Only administrators with encryption privileges can perform encryption and decryption tasks.
Two types of keys are used for encryption.
■ The ESXi host generates and uses internal keys to encrypt virtual machines and disks. These keys are used as DEKs and are XTS-AES-256 keys.
■ vCenter Server requests keys from the KMS. These keys are used as the key encryption key (KEK) and are AES-256 keys. vCenter Server stores only the ID of each KEK, but not the key itself.
■ ESXi uses the KEK to encrypt the internal keys, and stores the encrypted internal key on disk. ESXi does not store the KEK on disk. If a host reboots,vCenter Server requests the KEK with the corresponding ID from the KMS and makes it available to ESXi. ESXi can then decrypt the internal keys as needed. What Is Encrypted vSphere Virtual Machine Encryption supports encryption of virtual machine files, virtual disk files, and core dump files.
virtual machine files
Most virtual machine files, in particular, guest data that
are not stored in the VMDK file, are encrypted. This set of files includes
but is not limited to the NVRAM, VSWP, and VMSN files. The key that vCenter
Server retrieves from the KMS unlocks an encrypted bundle in the VMX
file that contains internal keys and other secrets.
If you are using the vSphere Web Client to
create an encrypted virtual machine, all virtual disks are encrypted by
default. For other encryption tasks, such as encrypting an existing virtual
machine, you can encrypt and decrypt virtual disks separate from virtual
machine files.
Note
You cannot associate an encrypted virtual disk with a
virtual machine that is not encrypted.
virtual disk files
Data in an encrypted virtual disk (VMDK) file is never
written in clear text to storage or physical disk, and is never transmitted
over the network in cleartext. The VMDK descriptor file is mostly clear text,
but contains a key ID for the KEK and the internal key (DEK) in the encrypted
bundle.
You can use the vSphere API to perform either a shallow
recrypt operation with a new KEK or deep recrypt operation with a new
internal key.
core
dumps
Core
dumps on an ESXi host that has encryption mode enabled are always
encrypted.
Note
Core
dumps on the vCenter Server system are not encrypted. Be sure to
protect access to the vCenter Server system.
Advantages of VM Encryption
1. Because encryption occurs at the hypervisor level and not in the VM, VM Encryption works with any guest OS and datastore type.
2. Encryption is managed via policy. The policy can be applied to many VMs, regardless of their guest OS. Verifying that the VM is encrypted can be done by confirming that the policy is applied. The policy framework being used leverages vSphere Storage Policy Based Management (SPBM).
3. Encryption is not managed “within” the VM. This is a key differentiator. There are no encryption “special cases” that require in-guest configuration and monitoring. Encryption keys are not contained in the memory of the VM or accessible to the VM in any way.
4. Key Management is based on the industry-standard Key Management Interoperability Protocol (KMIP). We are qualifying against KMIP version 1.1.vCenter Server is considered a KMIP client, and it works with many KMIP 1.1 key managers. This provides customers with choice and flexibility. It also provides a separation of duty between key usage and key management. In a large enterprise, key management would be done by the security team, and key usage would be done by IT, in this example via vCenter Server.
5. VM Encryption leverages the latest CPU hardware advances in AES-NI encryption. Advanced Encryption Standard Instruction Set is an extension to the x86 instruction set and provides accelerated encryption and decryption functions on a per-core basis in the CPU. General Best Practices
Follow these general best practices to avoid problems.
■ Do not encrypt any vCenter Server Appliance virtual machines.
■ If your ESXi host crashes, retrieve the support bundle as soon as possible. The host key must be available if you want to generate a support bundle that uses a password, or if you want to decrypt the core dump. If the host is rebooted, it is possible that the host key changes and you can no longer generate a support bundle with a password or decrypt core dumps in the support bundle with the host key.
■ Manage KMS cluster names carefully. If the KMS cluster name changes for a KMS that is already in use, any VM that is encrypted with keys from that KMS enters an invalid state during power on or register. In that case, remove the KMS from the vCenter Server and add it with the cluster name that you used initially.
■ Do not edit VMX files and VMDK descriptor files. These files contain the encryption bundle. It is possible that your changes make the virtual machine unrecoverable, and that the recovery problem cannot be fixed.
■ The encryption process encrypts data on the host before it is written to storage. Backend storage features such as deduplication and compression might not be effective for encrypted virtual machines. Consider storage tradeoffs when using vSphere Virtual Machine Encryption.
■ Encryption is CPU intensive. AES-NI significantly improves encryption performance. Enable AES-NI in your BIOS. VM Encryption Configuration
1. Register KMS with vCenter
2. Create Storage Policy for VM Encryption
3. Apply the Storage Policy on the VM to encrypt it
Select VM > Right Click > VM Policies > Edit VM Storage Policies > Select New Policy > Click on Apply to all > Click Ok
4. Verify the VM Encryption Status. You can check it from VM Summary Tab
Limitations
Consider the following caveats when you plan your virtual machine encryption strategy.
■ When you clone an encrypted virtual machine or perform a storage vMotion operation, you can attempt to change the disk format. Such conversions do not always succeed. For example, if you clone a virtual machine and attempt to change the disk format from lazy-zeroed thick format to thin format, the virtual machine disk retains the lazy-zeroed thick format.
■ You cannot encrypt a virtual machine and its disks by using the Edit Settings menu. You have to change the storage policy. You can perform other encryption tasks such as encrypting an unencrypted disk of an encrypted virtual machine, by using the Edit Settings menu or changing the storage policy.
■ When you detach a disk from a virtual machine, the storage policy information for the virtual disk is not retained.
■ If the virtual disk is encrypted, you must explicitly set the storage policy to VM Encryption Policy or to a storage policy that includes encryption.
■ If the virtual disk is not encrypted, you can change the storage policy when you add the disk to a virtual machine.
■ Decrypt core dumps before moving a virtual machine to a different cluster.
The vCenter Server does not store KMS keys but only tracks the key IDs. As a result, vCenter Server does not store the ESXi host key persistently.
Under certain circumstances, for example, when you move the ESXi host to a different cluster and reboot the host, vCenter Server assigns a new host key to the host. You cannot decrypt any existing core dumps with the new host key.
■ OVF Export is not supported for an encrypted virtual machine. Virtual Machine Locked State
If the virtual machine key or one or more of the virtual disk keys are missing, the virtual machine enters a locked state. In a locked state, you cannot perform virtual machine operations.
■ When you encrypt both a virtual machine and its disks from the vSphere Web Client, the same key is used for both.
■ When you perform the encryption using the API, you can use different encryption keys for the virtual machine and for disks. In that case, if you attempt to power on a virtual machine, and one of the disk keys is missing, the power on operation fails. If you remove the virtual disk, you can power on the virtual machine.
A vCenter HA cluster consists of three vCenter Server Appliance instances. The first instance, initially used as the Active node, is cloned twice to a Passive node and to a Witness node. Together, the three nodes provide an active-passive failover solution.
Deploying each of the nodes on a different ESXi instance protects against hardware failure. Adding the three ESXi hosts to a DRS cluster can further protect your environment.
When vCenter HA configuration is complete, only the Active node has an active management interface (public IP). The three nodes communicate over a private network called vCenter HA network that is set up as part of configuration. The Active node and the Passive node are continuously replicating data.
Image thanks to VMware
vCenter HA Nodes
Node
Description
Active
■
Runs the active vCenter
Server Appliance instance
■
Uses a public IP address for the
management interface
■
Uses the vCenter HA network for
replication of data to the Passive node.
■
Uses the vCenter HA network to
communicate with the Witness node.
Passive
■
Is initially a clone of the
Active node
■
Constantly receives updates from
and synchronizes state with the Active node over the vCenter HA network
■
Automatically takes over the
role of the Active node if a failure occurs
Witness
■
Is a lightweight clone of the
Active node
■
Provides a quorum to protect
against a split-brain situations
Configuring vCenter HA Steps
1. Select vCenter > Configure Tab > vCenter HA > Configure
2. Choose either Basic or Advanced Option
3. Configure IP details
4. Configure Deployment Configuration for Passive and witness node
5. Review your Configuration and Click on Finish
6. Once Enabled you can check the status under Configure Tab
If you want to test the failover, click on Initiate Failover.
