After attending the session Christos hosted at VMware Explore, Frank and I felt it would be a good idea to record a podcast with him. In this episode, we discuss the two relatively unknown products and projects, Project Moneta and VMware Data Service Manager. For those who don’t know, Christos used to be the CTO for Storage and Availability, and now is one of the two Fellow’s at VMware. Christos mainly focusses on data management, and how VMware can help customers solve their problems in this space. Listen via Spotify spoti.fi/3RvSniF, Apple , or just use the embedded player below. apple.co/3SxMFOn
Server
vSAN File Services fails to create file share with error Failed to create the VDFS File System.
Last week on our internal slack channel one of the field folks had a question. He was hitting a situation where vSAN File Services failed when creating a file share with the error “Failed to create the VDFS File System”. We went back and forth a bit and after a while I jumped on Zoom to look at the issue, and troubleshoot the environment. After testing various combinations of policies I noticed that a particular policy worked, whole another policy did not. At first it looked like that stretched cluster policies would not work but after creating a new policy with a different name it did work. One thing left, the name of the policy. It appears that the use of special characters in the VM Storage Policy name results in the error “Failed to create the VDFS File System”. In this particular case the VM Storage Policy that was used was “stretched – mirrored FTT=1 RAID-1”. The character that was causing the issue was the “=” character.
How do you resolve it? Simply change the name of the policy. For instance, the following would work: “stretched – mirrored FTT1 RAID-1”.
Cleaning up old vSAN File Services OVF files on vCenter Server
There was a question last week about the vSAN File Services OVF Files, the question was about the location where they were stored. I did some digging in the past, but I don’t think I ever shared this. The vSAN File Services OVF is stored on vCenter Server (VCSA) in a folder, for each version. The folder structure looks as show below, basically each version of an OVF has a directory with required OVF files.
root@vcsa-duncan [ ~ ]# ls -lha /storage/updatemgr/vsan/fileService/ total 24K vsan-health users 4.0K Sep 16 16:09 . vsan-health root 4.0K Nov 11 2020 .. vsan-health users 4.0K Nov 11 2020 ovf-7.0.1.1000 vsan-health users 4.0K Mar 12 2021 ovf-7.0.2.1000-17692909 vsan-health users 4.0K Nov 24 2021 ovf-7.0.3.1000-18502520 vsan-health users 4.0K Sep 16 16:09 ovf-7.0.3.1000-20036589 root@vcsa-duncan [ ~ ]# ls -lha /storage/updatemgr/vsan/fileService/ovf-7.0.1.1000/ total 1.2G vsan-health users 4.0K Nov 11 2020 . vsan-health users 4.0K Sep 16 16:09 .. vsan-health users 179M Nov 11 2020 VMware-vSAN-File-Services-Appliance-7.0.1.1000-16695758-cloud-components.vmdk vsan-health users 5.9M Nov 11 2020 VMware-vSAN-File-Services-Appliance-7.0.1.1000-16695758-log.vmdk vsan-health users 573 Nov 11 2020 VMware-vSAN-File-Services-Appliance-7.0.1.1000-16695758_OVF10.mf vsan-health users 60K Nov 11 2020 VMware-vSAN-File-Services-Appliance-7.0.1.1000-16695758_OVF10.ovf vsan-health users 998M Nov 11 2020 VMware-vSAN-File-Services-Appliance-7.0.1.1000-16695758-system.vmdk
I’ve asked the engineering team, and yes, you can simply delete obsolete versions if you need the disk capacity.
VMware Converter is back!
William already reported on it a few days ago, and I just noticed it on VMTN that VMware vCenter Converter Standalone is back, or better said in beta! If you are a customer who already has access to the beta community, simply go to this link: vCenter Convert Beta Community to get access to the community and the download/releasenotes. If you don’t have access to the beta community, register for it via the following registration page: https://www.vmware.com/learn/1645300_REG.html, and download vCenter Converter!
<update>Available now: https://www.vmware.com/products/converter.html
I just went to the community and looked at the release notes and wanted to share some details with you:
- VMware vCenter Converter Standalone 6.3.0 (GA) | 11 October 2022
- You cannot upgrade to VMware vCenter Converter Standalone 6.3.0 from previous versions. If you have a previous version of Converter Standalone installed, uninstall it and then install Converter Standalone 6.3.0
- You can install Converter on:
- Windows Server 2012 (64-bit
- Windows 8.1 (32-bit and 64-bit)
- Windows Server 2012 R2 (64-bit)
- Windows 10 (32-bit and 64-bit)
- Windows Server 2016 (64-bit)
- Windows Server 2019 (64-bit)
- Windows 11 (64-bit)
- Windows Server 2022 (64-bit)
- VMware Converter Standalone can convert offline virtual machines from the following Hyper-V servers:
- Windows Server 2012 (64-bit)
- Windows Server 2012 R2 (64-bit)
- Windows 10 (64-bit)
- Windows Server 2016 (64-bit)
- Windows Server 2019 (64-bit)
- Windows 11 (64-bit)
- Windows Server 2022 (64-bit)
- VMware Converter Standalone can convert offline virtual machines from the following VMware products and versions:
- VMware vSphere 6.5 (Update 3)
- VMware vSphere 6.7 (Update 3)
- VMware vSphere 7.0 + Update 1 + Update 2 + Update 3
- VMware Workstation 16.x
- VMware Fusion 12.x
Of course I downloaded the build and installed it on my Windows host, and it is up and running. Time to convert some machines!
As mentioned by William, the focus was very much on getting a new version out which was fully supported and developed using the latest frameworks. Next, the focus will be on adding new functionality and support for other platforms. I can’t wait for the next version!
VMware announces Ransomware Recovery as a Service and Data Protection vision!
At VMware Explore there was a whole session (CEIB1236US) dedicated to the vision for Data Protection and Ransomware Recovery as a Service. Especially the Ransomware Recovery as a Service had my interest as it is something that keeps coming up with customers. How do I protect my data, and when needed how do recover? Probably a year ago or so I had a conversation with VMware CTO for Cloud Storage and Data (Sazzala) on this topic, and we met up with various customers to gather requirements. Those discussions ultimately led to the roadmap for this new service and new features. Below I am going to summarize what was discussed in this session at VMware Explore, but I would urge you to watch the session as it is very valuable, and it is impossible for me to capture everything.
VMware’s Disaster Recovery as a Service solution is a unique offering as it provides the best of both worlds when it comes to Disaster Recovery. With DR you typically have two options:
- Fast recovery, relatively high cost.
- Traditionally most customers went for this option, they had a “hot standby” environment that provided full capacity in case of emergency. But as this environment is always up and running and underutilized, it is a significant overhead.
- Slower recovery, relatively low cost.
- This is where VMs are replicated to cheap and deep storage and compute resources are limited (if available at all). When a recovery needs to happen, data rehydration is required and as such, it is a relatively slow process.
With VMware’s offering, you now have a 3rd option: Fast recovery, at a relatively low cost! VMware provides the ability to store backups on cheap storage, and then recover (without hydration) directly in a cloud-based SDDC. It provides a lot of flexibility, as you can have a minimum set of hosts constantly running within your prepared SDDC, and scale out when needed during a failure, or you can even create a full SDDC at the time of recovery.
Now, this offering is available in VMware Cloud on AWS in various regions. During the session, the intention was also shared to deliver similar capabilities on Azure VMware Solution, Oracle Cloud VMware Solution, Google Cloud VMware Engine, and/or Alibaba Cloud VMware Service. Basically all global hyper-scalers. Maybe even more important, VMware also discussed additional capabilities that are being worked on. Scaling to tens of thousands of VMs, managing multi-petabytes of storage, providing 1-minute RPO levels, proving multi-VM consistency, having end-to-end SLA observability, providing advanced insights into cost and usage, and probably most important… a full REST API.
All of those enhancements are very useful for those aiming to recover from a disaster, not just natural disasters, but also for Ransomware attacks. Some of you may wonder how common a ransomware attack is, but unfortunately, it is very common. Surveys have revealed that 60% of the surveyed organizations were hit by ransomware in the past 12 months, 92% of those who paid the ransom did not gain full access to the data, and the average downtime was 16 days. Those are some scary numbers in my opinion. Especially the downtime associated with an attack, and the fact that full access was not regained even after paying a ransom.
In general recovery from ransomware is complex as ransomware typically remains undetected for larger periods of time before you are exposed to it. Then when you are exposed you don’t have too many options, you recover to a healthy point in time or you pay the ransom. When you recover, of course, you want to know if the set you are recovering is infected or not. You also want to have some indication of when the environment was infected, as no one wants to go through 3 months of snapshots before you find the right one. That alone would take days, if not weeks, and downtime is extremely expensive. This is where VMware Ransomware Recoveryfor VMware Cloud DR comes in.
The aim for the VMware Ransomware Recoveryfor VMware Cloud DR solution is to provide the ability to recover to an Isolated Recovery Environment (including networking). This first of all prevents reinfection at the time of recovery. During the recovery process, the environment is also analyzed by a next-generation anti-virus scanner for known/current threats. Simply to prevent a situation where you recover a snapshot that was infected. What I am even more impressed by is that the plan is to also include a visual indication of when most likely an environment was infected, this is done by providing an insight into the data change rate and entropy. Now, entropy is not a word most non-native speakers are familiar with, I wasn’t, but it refers to the randomness of the data. Both the change rate and the entropy could indicate abnormal patterns, which then could indicate the time of infection and help identify a healthy snapshot to recover!
As mentioned, during recovery the snapshot is scanned by a Next-Gen AV, and of course, when infections are detected they will be reported in the UI. This then provides you the option to discard the recovery and select a different snapshot. Even if no vulnerabilities are found the environment can be powered on fully isolated, providing you the ability to manually inspect before exposing app owners, or end-users, to the environment again.
Now comes the cool part, when you have curated the environment, when you are absolutely sure this is a healthy point in time that was not infected, you have the choice to fallback to your “source” environment or simply remain running in your VMware Cloud while you clean up your “source” site. Before I forget, I’ve been talking about full environments and VMs so far, but of course, it is also the intention to provide the ability to restore files and folders of course! All in all, a very impressive solution that should be available in the near future.
If you are interested in these capabilities and would like to stay informed, please fill out this form: https://forms.office.com/r/yh69Npq7nY.