I just upgraded from 11.0.3 to 11.1.3 and now my backups are failing with the following error:
2018-10-31T09:04:51| SyntaxError: invalid syntax
2018-10-31T09:04:51| File "<string>", line 1
2018-10-31T09:04:51| print( + <= 88027955200+52428800 )
2018-10-31T09:04:52| SyntaxError: invalid syntax
2018-10-31T09:04:52| sh: Can't find extent map at /vmfs/volumes/FreeNASStorage/DomainController
2018-10-31T09:04:52| 0: bad number
What have I done wrong?
Mmm, what kind of file system are you hosting the VMs in?
It could be a bug related to not hosting VMs in an VMFS volume, which is an almost mandatory issue, especially if using [https://33hops.com/xsitools-vmfs-deduplication.html]XSITools[/url] to backup your VMs.
We'll check that possibility, in the meanwhile use some other --backup-prog to backup your Virtual Machines.
They are hosted on an NFS file share from a FreeNAS server. They have been working without issue until the upgrade yesterday.
NFS is not a file system, although the acronym stands for Network File System, it's a data transport protocol, a real file system is what maps a recording media such as a HD or SSD. If it's a free NAS device that you are using, the underlying filesystem will most probably be ZFS.
We are making tests right now, as the backup should still be performed. In any case, if you host your VMs in a NAS through NFS and a non-VMFS file system, you are not only narrowing your I/O bandwidth down to 1 gbps and increasing I/O latencies wildly, you are also limiting the possibilities of ESXi in regards to managind data and recovering it. NFS NAS can be a great asset to backup your VMs to, but it's definitely not the best choice by far to host your production VMs.
Please, let us know what your ESXi version and build are and whether you are using [https://33hops.com/xsitools-vmfs-deduplication.html]XSITools[/url] as the backup program or not, we have had to guess so far.
Sorry, the underlying filesystem is ZFS and I am using ESXi version 6.7.0 and build 9484548.
Up until now I have been using XSITools as the backup program without issue and have recovered several VM's without issue.
Yes, you are absolutely right, this is a bug, we'll fix it today.
Nevertheless, we must insist in taking the chance and try to convince you to move your VMs to an VMFS volume for the reasons exposed above.
VMFS has been designed to store VMs, whereas ZFS is a general purpose FS. VMFS keeps track of every extent of data stored in your .vmdk files, this allows to jump over zeroed zones, replicate data and run quick algorithms to check data integrity. You loose all that features by using an NFS volume to run your VMs, on top of that, as estated in the previous post you limit bandwith and increase latencies in disk I/O operations.
Just to pose a real life example: backing up a Linux VM in a single .vmdk disk which is 20 gb in size and contains 2.7 gb of data will take (in one of our test servers, which is an i3 with 16 gb. memory and regular HD with a small SSD acting as a host cache disk) 9 minutes if hosted on an NFS share against 1.5 minutes when hosted in an VMFS5 volume, when using XSITools:z to backup over IP to a Linux server.
Thanks for getting back to me.
Its currently and AIO solution so the FreeNAS is running on the ESXi server which then mounts the FreeNAS volume within ESXi as a datastore.
I will see if I can come up with a better solution utilising VMFS volumes instead.