Showing posts with label VMware vSphere/ESXi. Show all posts
Showing posts with label VMware vSphere/ESXi. Show all posts

Shrink a VMware Virtual Machine Disk (VMDK)



In fact, increasing the size of a VMware Virtual Machine Disk (VMDK) is straightforward, and is supported in the vSphere Client, by selecting the virtual hard disk, and increasing the size using the up arrow. or typing in a new value.

However, you cannot shrink the disk in this way, it’s not supported. The only supported method of shrinking a VMware virtual machine disk (VMDK) is to use VMware vCenter Converter Standalone and create a virtual to virtual (V2V)
conversion, a similar process to a Physical to Virtual (P2V) conversion.

The following procedure should be followed to shrink the VMware VM Disk:

1.      RDP to the VM for which the disk size is to be reduced.
2.      Select Disk Management, and select the partition you need to shrink.
3.      Right Click the Volume/Partition to shrink, and select Shrink.
4.      Enter a size to reduce the OS partition.
5.      In this example the VMware virtual machine disk (VMDK) is 30GB, and we would like to reduce the size of the VMware virtual machine disk (VMDK) to 20GB.
6.       Enter the figure 20 (GB) x 1024 = 20480
7.       Now you can see an unallocated 20 GB space on the virtual disk
8.       Power OFF the Virtual Machine, and navigate to the datastore path where the VMware virtual machine disk (VMDK) is located using Putty
9.       We need to edit the *.vmdk, which is the descriptor file, which contains the variables for the size of the *.-flat.vmdk.
10.  The number mentioned under the heading #Extent description, after the letters RW, defines the size of the VMware virtual disk (VMDK).
11.  We wanted to reduce the size of the VMware virtual machine disk (VMDK) from 40 GB to 20 GB. So the value we need to enter into the descriptor file is:-

20 GB = 20 * 1024 * 1024 * 1024 / 512 = 41943040

12.   Using vi, edit the descriptor file, and change the number from 125829120 to 41943040, and save the file.

125829120 is calculated from 80 GB = 80 * 1024 * 1024 * 1024 / 512 = 125829120

13.   Migrate or Copy the virtual machine to another datastore.
14.   After the virtual machine disk (VMDK) has been moved, you will notice the disk size reflects the desired size of 20GB.
15.   After restarting the virtual machine, and checking with Disk Management, you will notice the 20 GB unallocated storage space, has been removed, and disappeared.

How to copy a VM host to host without vCenter


Login to both ESXi hosts that you are copying from and copying to and make sure SSH is enabled.

Make sure the SSH service is started and allowed in ESXi Firewall on both the hosts.

Now ssh into the esxi host 1 which has the VM that needs to be transferred.

Lets give that host ip 10.1.1.1 and the Host 2 that’s going to receive the file will be 10.2.2.2.

You can SSH into the host 1 using putty(win) or terminal (mac)

#ssh root@10.1.1.1
The authenticity of host '10.1.1.1 (10.1.1.1)' can't be established.
RSA key fingerprint is b2:d6:00:34:aa:cc:62:95:8f:d7:f3:1d:59:1e:c3:54.
Are you sure you want to continue connecting (yes/no)? yes

then it will prompt for Password: so enter that.

Start transferring folder:

nohup scp -rv /vmfs/volumes/data-store1/vm-folder-name root@10.2.2.2:/vmfs/volumes/data-store2/

For Multiple VMs (Folders)

First change directory to the Datastore folder

cd /vmfs/volumes/data-store1/

nohup scp -rv vm-folder-1 vm-folder-2 root@10.2.2.2:/vmfs/volumes/data-store2/

Then it’s better to enter multiple VMs leave just a single space between the VM folder name. No quotes or commas.
Now you will be prompted for “host 2” password. enter that and the file transfer will start. The flags used here are -rv, where r is for folder tranfer and v for verbos to watch the progress.

Note: Adding nohup before scp will allow the command to run in background even if you close Terminal/Putty window.

Purpose of Native VLAN in Cisco UCS

Issue:

We have created a service profile that contains 1 vNIC and it is placed in VLAN XX.  I have installed Windows 2008 on a blade using this service profile.  In the OS I have assigned static IP for the NIC in VLAN XX.  From the OS, we cannot ping another device that is in VLAN XX. We cannot ping a host on another VLAN as well.  If we place a check on VLAN 1 as the native VLAN, we still cannot ping anything.  If we place the check for native VLAN to VLAN XX, I can ping hosts within the same VLAN as well as outside the VLAN.  So, why do I need to place VLAN XX as the native VLAN when all my trunks are set up as VLAN 1 being the native VLAN?

Solution:
When allowing certain VLANs on your Service Profile vNICs, you need to set the native VLAN. This is because the way you have it configured currently you're only "allowing VLAN XX, but you're not tagging it. This would work fine for ESXi or any other Hypervisor where you can assign the dot1q tag at the host.  With Windows unless you have specific drivers doing the tagging for you, you'll need to do this at the vNIC level within UCS.
Two ways to see this in action.  When creating a service profile in the "Basic" method - not "Expert", you will select a single VLAN for your interfaces.  This will treat the interfaces pretty much like an "Access Port".  Conversely when you use the "Expert mode you're enable the vNIC as a trunk, in which you will "allow" all the VLANs you'd like access to. Sounds like this is the method you have performed.
For a Windows OS, set the VLAN as Native for the VLAN you want it to access and you'll be sweet.  Unchecking that "Native VLAN" option box is allowing the traffic to traverse out of UCS on the Native VLAN of your network - VLAN 1, which is why it's MAC appears on the other fabric under VLAN1


vSphere 5.x Storage vMotion does not rename virtual machine files on completing migration

Symptoms
  • You rename a virtual machine in the VMware vSphere Client, but the .vmdk disks are not renamed following a successful Storage vMotion task.
  • You perform a Storage vMotion of the virtual machine to have its folder and associated files renamed to match the new name. The virtual machine folder name changes, but the virtual machine file names do not change.
Resolution
  1. Log in to the vSphere Client as an Administrator.
  2. Click Administration > vCenter Server Settings.
  3. Click Advanced Settings.
  4. Add this advanced parameter key:

    provisioning.relocate.enableRename
  5. Set the value to:

    true
  6. Click Add.
  7. Click OK.
  8. Restart the VMware VirtualCenter Server service for the changes to take effect. For more information, see Stopping, starting, or restarting vCenter services (1003895).

Extend System Partition on a Windows Server 2003 VM using Dell ExtPart

There is no native tool that enables extending system partitions (C:\ drives) on Server 2003. There are multiple ways to perform this task using Third party tools, however, the only method that can be done online utilizes a Dell utility called ExtPart. It can perform the extension of the system partition with no downtime although sometimes booting into Safe Mode and then running ExtPart is necessary to clear locks on the disk.
NoteThis applies to Server 2003 only, newer versions of Windows do not suffer from this limitation, Disk Management as well as the diskpart are able to extend system partitions on-the-fly.
1.   The first step is to download the ExtPart utility from this link. Click on the Download File link and save it to your desktop. The file is a self-extracting zip file called ExtPart.exe per the below:
2.   Double-click on it and accept the default path it will extract the utility to.
3.   Click on Unzip and the files will be extracted successfully.
To demonstrate how useful ExtPart is we will use an example whereby our demo VM has a 12 GB C:\ drive and it needs to be increased to 25 GB. A screenshot of the the current state of the C:\ drive is below: 

Ensure that you have 13 GB of unallocated space to next to C drive to extend the partition.
Now we need to run the ExtPart utility expand the C:\ drive so that it utilizes the 13 GB of unallocated space. To proceed, open the command prompt and go to the location where you extracted the ExtPart utility, in my case, C:\dell\ExtPart:
C:\>cd C:\dell\ExtPart

Then run ExtPart.exe:
C:\dell\ExtPart>extpart.exe

Enter the volume that is being expanded, in this example it is the C:\ drive so enter just C: without the backslash:
Volume to extend (drive letter or mount point): C:

Then enter the amount in MB to increase the volume by, I entered 13312:
Size to expand the volume (MB): 13312

The output will confirm the new size of the volume (C:\ drive), which is 25101 MB:
New volume size          :25101 MB (26320895488 bytes)

The full sequence of commands can be seen in the screenshot below:

When going back into Disk Management and re-scanning the disks you can see that the C:\ drive is using all of the provisioned space in the disk:


If the utility returns an error such as “the disk is not accessible” or “unable to connect to C:” then reboot the VM into Safe Mode and then run the same ExtPart commands. This is caused by various services locking the disk and preventing ExtPart from extending the volume. Booting into Safe Mode starts up the OS in a clean state, so only minimal services and drivers will run, thereby allowing ExtPart to expand the volume without interruption.

Link to download DELL Basic Disk Expansion, v.1.0.4, A01


Issue:

We may get “Access denied error” on a VMware Virtual Machine, while configuring a folder in IIS Manager or when you try to access a remote folder using any tool like Backup Exec, etc.

Resolution:
1.       Power off the VM and once powered off, right click the VM and click “Edit Settings”

2.       Under “Options” select “general” and configuration parameters.


3.       3. Select “Add Row” and in the name field enter “devices.hotplug” with the value “false”


Please see below the VMware KB article detailing the steps to disable to the VMware hot add functionality.




Determining OS type with a Ping

TTL=58 = VMware ESXi host
TTL=64 = *nix - the hop count so if you’re getting 61 then there are 3 hops and its a *nix device. Most likely Linux.
TTL=128 = Windows - again if the TTL is 127 then the hop is 1 and it is a Windows box.
TTL=254 = Solaris/AIX - again if the TTL is 250 then the hop count is 4 and it is a Solaris box.

Updating ESXi hosts to 6.0 Update 2 using VUM:

Prior Updating ESXi hosts to 6.0 Update 2
1
1.       Enable Anti-Affinity rules per requirements.
2.       Ensure Clusters have HA enabled with single host loss.
3.       Ensure DRS is enabled and fully automated with enough resources to balance Anti-Affinity rules.
4.       Create Baseline via Update Manager with Critical and Important Patches, including the Full Update 2 Patch.
1. Create a new Host Upgrade Baseline
2. Click Next
3. Select the extension baselines to include the baseline group
4. Click Finish

Updating ESXi hosts to 6.0 Update 2

1)      Taken care of in the Prior to Update, but do check resources are still sufficient to support a host down and the anti-affinity rules.

2)      Place a host into MX mode allowing DRS to migrate all VMs off of the host to be updated. Templates and powered off VMs can stay on the host. *However, they migrate quickly and should have no impact on the upgrade.

3)      Many Options to update ESXi. For this process we are utilizing Update Manager.

4)      Disable any alerts / monitoring to avoid any false alarms.

5)      Select the object (Host) click Update Manager Tab

6)      Click Attach

7)      In the Attach Baseline or Group Window, select the baseline that was previously created.

8)      Click Attach.

9)      Right Click the host and “Scan for Updates”

10)   Select the type of Upgrade à Patches and Extensions

11)   Click Scan

12)   ReSelect the Host, click Update Manager and Click Remediate.

13)   Select Upgrade Baselines, Accept the terms and click Next

14)   Select Immediately to begin the process

15)   Select the power state of VMs (Since the Host was already placed in MX mode and no VMs live on the host, this does not matter, but please choose Do Not Change VM power State.

16)   Select Retry entering MX mode in case of failure

17)   Click Next

18)   You should not get to the cluster screen since we are doing a single host at once, so click Finish.

19)   Once the host remediation is completed, Sanity check the host:

a.       Change DRS to manual (Only first upgraded host, afterwards sanity checks should be quick – Suggestion).
b.      Place the host out of MX mode.
c.       Move one VM to the newly updated host.
d.      Have Infosys verify network connectivity and authentication (If required).
e.      Have a customer to check the VM, once the VM is checked, turn DRS back to fully automated to allow the cluster to become evenly balanced.  
                                                               i.      If any issue is found, follow the backout plan:
                                                             ii.      Migrate the VM back to another host.
                                                            iii.      Place host back into MX mode.

Back out plan

If any issue arises after applying the patches to the first ESXi host then stop any further remediation of patches until the problem is rectified. We will engage VMware support immediately. 
If no resolution is found within the window, we will schedule for a re-install of the Host back to ESXi 6.0 (Same build number previously).  As the vCenter is not a part of this specific part of the upgrade no rollback plan is required for it. 

Upgrading vSphere Update Manager (VUM) to 6.0 Update 2

To upgrade an instance of Update Manager that is installed on a 64-bit machine, you must first upgrade vCenter Server to a compatible version.

Things to have ready

·         Download the VMware vCenter Server 6.0 Update 2 and Modules for Windows ISO
·         Disable any alerts or monitoring so that we don't get false alerts during the update process.
·         Before updating the vCenter Appliance take a clone of the image and also take a snapshot before the update 

Procedure:  

1.          Mount the ISO on the virtual machines on which Update manager installed

2.          In the software installer directory, double-click the autorun.exe file and select vSphere Update Manager > Server.

3.          Run autorun.exe

4.          Select a language for the installer and click OK.

5.          In the upgrade warning message, click OK.

6.          Review the Welcome page and click Next.

7.          Read and accept the license agreement, and click Next.

8.          Review the support information, select whether to delete old upgrade files, select whether to download updates from the default download sources immediately after installation, and click Next.

9.          Type the vCenter Server system credentials and click Next.

10.      To keep the Update Manager registration with the original vCenter Server system valid, keep the vCenter Server system IP address and enter the credentials from the original installation.

11.      Type the database password for the Update Manager database and click Next.

12.      The database password is required only if the DSN does not use Windows NT authentication.

13.      On the Database Upgrade page, select Yes, I want to upgrade my Update Manager database and I have taken a backup of the existing Update Manager database, and click Next.

14.      (Optional) On the Database re-initialization warning page, select to keep your existing remote database if it is already upgraded to the latest schema.

15.      If you replace your existing database with an empty one, you lose all of your existing data.

16.      Specify the Update Manager port settings, select whether you want to configure the proxy settings, and click Next.

17.      Click Install to begin the upgrade.


18.      Click Finish.

Upgrading vCenter Server Appliance to 6.0 Update 2:


Current Version Info
·         VCSA Appliance version – 6.0.0.10000 Build Number 3018521
·         vCenter Server version – 6.0.0 Build 3018523

Target version after update
·         vCenter Server Appliance 6.0 Update 2 | 15 MARCH 2016 | ISO Build 3634788
·         vCenter Server 6.0 Update 2 on vCenter Server Appliance Build 3634794

Pre-Requisites for the Change:
·         Download the VMware vCenter Server 6.0 Update 2 Appliance ISO VMware-VCSA-all-6.0.0-3634788.iso
·         Disable any alerts or monitoring so that we don't get false alerts during the update process.
·         Before updating the vCenter Appliance take a clone of the image and also take a snapshot before the update

Impact during Change Windows

·         Down time required for the vCenter update. The update will take about 1 to 2 hours.
·         All Cloud configuration changes will be impacted during this change. However, this change will not impact existing production VMs hosted on the Cloud platform.

Updating the appliance


1. We need to access the VAMI at https://fqdn:5480

2. Now we Navigate to the Update page, mount the “update ISO image” and click “check updates -> check CDROM”

3. Now we can see there are patches outstanding. 

4. Use the "Install Updates" button to install all patches.

5.  It will start and we can see some status of the update.

6. The appliance will need to be restarted at the end. Reboot is on the Summary screen.

7. The appliance will come back fast.  Log in and check for the new version – should be 6.0.0.20000 Build 3634788.

8. It will take the vSphere Web Client longer to be back but when it does it will look different.

9. When you can log in and check the vCenter version.  It should be 6.0 build 3634794.

Post update testing

·         Check the VCSA system configuration and make sure that all nodes and services are healthy and no issues reported.

·         Check by logging in to vSphere Web Client that all hosts are connected and no issues reported.

·         Check by logging in to vSphere Desktop Client that all hosts are connected and no issues reported.

·         Customer / Infosys to check customer's Virtual machines. 

vCenter Rollback Plan


Once update test is successful remove the snapshot and leave the clone of VCSA for 7 days. If there are any major issues after updating the appliance we can go back to the old version from Snapshot or Cloned VM.