I had the pleasure (?) recently of troubleshooting some backup issues on my vSphere Data Protection Advanced (VDPA) setup. To be honest, I had not spent a great deal of time on this product recently, other than a few simple backup and restores. However, in my new role I now have a number of other projects which requires me to understand this product’s functionality a bit more. When things were not going right for me though, I spent a lot of time searching for some log files which might give me some clue as to the nature of my problem. After some assistance from some of the GSS guys based in Cork, we narrowed it down.
For me, the install and configure part went fine. I could also create backups with relative ease. The issue related to running the backups in certain environments, which were failing. So how then could I determine why this was happening?
I thought it was about time that I looked at some of the larger storage vendors closer to home. One of these is of course Bull. This company is probably more familiar to those of us based in Europe rather than those of you based in the Americas or Asia Pacific. However VMware customers in EMEA will have seen them in the Solutions Exchange at VMworld Europe, where they have a reasonably large presence. After some conversation with my good pal Didier Pironet, whom I’ve met at a couple of recent VMUGs, I was introduced to Philippe Reynier who is a manager in the Bull StorWay Competence Center and Solution Center. Philippe provided me with a lot of good detail on Bull’s storage solutions which I will share with you here.
There are many occasions where the information displayed in the vSphere client is not sufficient to display all relevant information about a particular storage device, or indeed to troubleshoot problems related to a storage device. The purpose of this post is to explain some of the most often used ESXCLI commands that I use when trying to determine storage device information, and to troubleshoot a particular device.
Following on from my recent post on how to reclaim disks that were previously used by VSAN, I was asked how one can remove a disk group from a host that is participating in a VSAN cluster. This is quite straight forward, but there is one minor caveat and it relates to whether the VSAN cluster has been setup in Automatic Mode or Manual Mode. If you want to learn more about the behaviour of the different modes, you can read up on it here.
A number of customers have raised this question. How do you reclaim disks which were once used by VSAN but you now wish to use these disks for other purposes? Well, first off, if you are using some of the later builds of VSAN and you place the host into maintenance mode and remove the disk group from the host, this will automatically remove the partitions from the disks and you are good to go with reusing these disks for some other purpose. However, if you do something such as reinstall ESXi on the host but do not go through the appropriate VSAN clean up steps first, then there may still be VSAN partition information on the disks. So how do you go about cleaning up these disks?
I was going to make this part 11 of my vSphere 5.5 Storage Enhancements series, but I thought that since this is such a major enhancement to storage in vSphere 5.5, I’d put a little more focus on it. vFRC, short for vSphere Flash Read Cache, is a mechanism whereby the read operations of your virtual machine are accelerated by using an SSD or a PCIe flash device to cache the disk blocks of the application running in the Guest OS of your virtual machine. Now, rather than going to magnetic disk to read a block of data, the data can be retrieved from a flash cache layer to improve performance and lower latency. This is commonly known as write-through cache, as opposed to write-back cache, where the write operation is acknowledged when the block of data enters the cache layer.