I was trying to access the vRA Appliance VAMI and i was unable to root user in vRA and the error was "Server reports that it is from cimom" This is Known Issue (KB 2103604)
Cause:- This issue occurs when the root password expires. The appliance root account password expiration is defined to be 365 days. If the password is not changed before this time passes the root user cannot log in to the Appliance management console.
Solution:-
Log in to vRA Appliance using root account
Execute passwd command to reset the password
passwd root
enter new password
This resets the password for another 365 days.
You can also extend the root password expiry date by running this command:
chage -M numOfDays root Note: This may pose a security risk so ensure that you verify with your internal policies prior to setting.
Yesterday someone asked me this question "What is the impact on the vRA VM? if Owner Account is directly deleted from Active Directory"
Answer:- If Owner account is deleted from AD this does not the VM. vRA VM keeps on using the old account until and unless it is changed to new owner by the support user. Here is screenshot of how one can change the vRA VM Owner Login with Support User Account > Items Tab > Select Deployment > Actions > Change Owner > Search New Owner > Submit.
Whenever the VM is connected with distributed vSwitch, one folder is created in its datastore with the name .dvsdata this folder is created to keep the VM port information (port information means in dvSwitch is "which port is allocated to vm").
Hierarchy of .dvsdata folder:- .dvsdata UUID of dvSwitch Small file created with port number name.
Small file with port number name
This file keeps the information like port state, MTU, run time packet stats.
Updated by hostd after every 5 minutes with vds port information.
Contains the data of VM vNIC that is attached to dvSwitch.
dvsdata.db file
This file location on esxi host is /etc/vmware/dvsdata.db
It is updated by hostd after every 5 minutes
It contains the data of persistent vds ports (vmkernel)
Last week i faced the issue where i was able to execute the vicfg commands against my esxi host but esxcli commands execution was getting failed with error "connect to esxi failed". This was quite weird issue as there was no hint why it is getting failed. then with some investigation i came to know ESXi thumbprint that is present in vCenter Certificate store is incorrect.
Now for replacing the incorrect thumbprint in vCenter Certificate Store following command execution is required in vma:-
/usr/lib/vmware-vcli/apps/general/credstore_admin.pl add -s server -t thumbprint
For every powered on VM a .vswp file is created in VM's datastore, this file is needed by the hypervisor to satisfy the VM memory demand in case of over-commitment is done and as well as when vm memory limit is configured. This gets created when the VM is powered on and deleted when VM is powered off. Size of this file is calculated with formula given below:- (VM configured memory - VM Memory Reservation )
Lets take an example, VM configured memory is 4GB and Reservation is 1GB. Now the .vswp file size would be 3GB.
As we all know we can change the memory reservation of the powered on VM.
Now the question is If the powered on VM reservation is changed then what would be the impact on .vswp filesize?
.vswp file can only grow in powered on VM, to shrink it you have to power off and power on the VM is required. Lets take an example:- Screnario:-
VM Configured Memory = 988MB
VM Memory Reservation = 0
I started my VM, .vswp file is created with 988MB.
In this case VM Reservation is changed to 988MB when it was powered on. This will not impact .vswp size as it cannot shrink. Power off and Power on and then you can see the .vswp file of zero size in datastore. Yes it is created even if configured memory and reservation value is same
Now as you can in above screenshot it is created but size is 0kb. Now in this powered on vm i changed the reservation from 988MB to again zero, now i can see this change in .vswp file size without being powere cycled as it can grow in the running vm,
vmx-xxxxxxxxxxxxxxxx.vswp file
This vmx-xxxxxxx.vswp file is dedicated to memory overhead and will be used when there is memory contention for the host memory. When the virtual machine is created the memory overhead is defined, however the VM and the VMkernel will not use the whole reserved memory until required.
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.
