On a VM, running on VMware vSphere 6.7 and ESXi 6.7, the possibility to extend the virtual hard disk was greyed out:
I checked with a couple of other systems and it was possible on all of them. What would be the difference between this particular VM and the others?
After some minutes of trying to spot a configuration, which would prevent online resizing, the reason was finally found: There was an snapshot on this VM!
Unfortunately in the new web-based vSphere user interface, an active snapshot cannot be seen as fast as in the earlier vSphere days (VMware Infrastructure and vSphere GUI). To check if a virtual machine still holds a snapshot, the "Actions" drop down menu needs to be opened, followed by the "Snapshots" entry to then finally click on "Manage Snapshots". 
And here, finally, the snapshot can be deleted:
Once the snapshot was deleted, the virtual hard disks could be (online) resized again:
Once the virtual hard disk was extended (not shrunk!), the virtual hard drive can be extended within the operating system (here CentOS Linux), without downtime, too! This was already explained in an older article (Dynamically increase physical volume (PV) in an LVM setup on a VM) but for the sake of completeness of this article, here's the info again.
First the correct drive needs to be identified:
[root@vm ~]# pvs
  PV         VG         Fmt  Attr PSize   PFree
  /dev/sda5  vgsystem   lvm2 a--    6.00g 4.00m
  /dev/sdb   vgdb       lvm2 a--  <60.00g    0 
  /dev/sdc   vgtmp      lvm2 a--  <30.00g    0 
  /dev/sdd   vgapp      lvm2 a--  <10.00g    0 
  /dev/sde   vgdbbackup lvm2 a--  <50.00g    0  
In vSphere UI the 5th hard drive had an original size of 50GB and as there is only one physical volume with that size (SDE) the drive is identified!
Note: The order of hard drives in vSphere UI does not forcibly match the order in the OS, watch out!
We can now tell the Kernel to rescan this particular drive (sde). To do this, the exact scsi device path needs to be found first:
[root@vm ~]# ll /sys/block/sde/device
lrwxrwxrwx 1 root root 0 Dec 11 08:13 /sys/block/sde/device -> ../../../0:0:4:0
And then the Kernel is told to rescan this path:
[root@vm ~]# echo 1 > /sys/class/scsi_device/0\:0\:4\:0/device/rescan
With fdisk, the new size can already be seen:
[root@vm ~]# fdisk -l /dev/sde
Disk /dev/sde: 69.8 GB, 69793218560 bytes, 136314880 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Resize the PV:
[root@vm ~]# pvresize /dev/sde
  Physical volume "/dev/sde" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
And voilà, the new space is available in the VG:
[root@vm ~]# vgs
  VG         #PV #LV #SN Attr   VSize   VFree 
  vgapp        1   1   0 wz--n- <10.00g     0 
  vgdb         1   1   0 wz--n- <60.00g     0 
  vgdbbackup   1   1   0 wz--n- <65.00g 15.00g
  vgsystem     1   2   0 wz--n-   6.00g  4.00m
  vgtmp        1   1   0 wz--n- <30.00g     0  
No comments yet.
 
AWS Android Ansible Apache Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Coding Consul Containers CouchDB DB DNS Databases Docker ELK Elasticsearch Filebeat FreeBSD Galera Git GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Influx Internet Java KVM Kibana Kodi Kubernetes LVM LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS Observability Office OpenSearch PHP Perl Personal PostgreSQL PowerDNS Proxmox Proxy Python Rancher Rant Redis Roundcube SSL Samba Seafile Security Shell SmartOS Solaris Surveillance Systemd TLS Tomcat Ubuntu Unix VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder Linux