error OVMXCHK1: VMX file check

noobstyle · 2017-09-28 14:05:48

HI,
i have this error when i lunch again onediff :
VMX file check 1 fail, details: first line in .vmx file is not [.encoding = "UTF-8"], has this file been manually modified/edited?

But when i check .vmx file :

/vmfs/volumes/59a686f4-234c75aa-ca39-001b214be630/debian # vi debian.vmx
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "8"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"

So, is someone had the same error ? or know how to deal with it?

Thx.

admin · 2017-09-28 19:13:08

You probably edited it and some invisible characters are present

noobstyle · 2017-09-29 07:15:25

Never touched this file. This is the original file.

admin · 2017-10-01 16:52:25

The thing is obvious, XSIBackup reads the first line and matches it against [b].encoding = "UTF-8"[/b]
If the match does not succeed, then you get that error. If the match was buggy, there would be, at least, hundreds of posts about this issue, but yours is the only one so far.

I would regenerate the .vmx from scratch by adding the .vmdk disks to a new template.

bheide · 2017-10-04 15:01:46

If you want to check what's exactly stored in the first line you could run:
cat vm.vmx | tail -n1 | od -c

The output should look similar to this:

# cat "vmvc.vmx" | head -n1 | head -n1 | od -c
0000000   .   e   n   c   o   d   i   n   g       =       "   U   T   F
0000020   -   8   "  \n
0000024

noobstyle · 2017-10-05 07:40:18

Hi, i tried your command, and i have same results with all my VM.

roberto · 2017-10-15 18:16:52

We really don't know how to help you with this, nobody else seems to have this problem. On the other side, the matter is quite obvious.

noobstyle · 2017-10-15 19:24:45

my first line is what it should be, but still doesn't work, so i don't see what is obvious. I bought your software and nothing works as it should. One diff = full only, XSItools = can't hash, XSIdiff = can't backup. The only thing i can do with your sowtfare is normal full backup. I tried on different server, with different ESXi, with different VM and everytime, something goes wrong. When i post, there is no answer but "you are the only one, deal with it".

But ok, thx for the joke.

sistemi · 2017-10-16 13:51:38

you should investigate for a common denominator, i was in trouble with some of your symptoms, and i'm now almost sure that is the NFS file system on a QNAP NAS or the NSF timeouts on ESXI...

admin · 2017-10-16 17:09:43

[b]noobstyle[/b], we have the big picture. If there was some sign that there could be a bug on our side, we would be the first to react and fix it. The truth is that nobody else has reported this issue.

We have checked the code that is raising the error for you and we can't reproduce it. If we say it's obvious, it's because it is a string comparison that is failing, so you just have to compare both strings at runtime and find out why they don't happen to be equal to that comparison sentence.

You can also remove the check, which is not absolutely necessary, just remove this lines starting at line 475 in [b]src/onediff[/b] module

VMXCONTENTCHCK="$( cat "$VMXFILECONTENTPATH" | head -n1 | head -n1 | openssl md5 2>/dev/null | awk -F '=' '{print $2}' | sed -e 's/^ *//g' -e 's/ *$//g' )"
if [ "$VMXCONTENTCHCK" != "1077300a4a48cc94a3f8c3bf78d77e3a" ]
then
    writeout "\033[0;31m[$NAM] error OVMXCHK1: VMX file check 1 fail, details: first line in .vmx file is not [.encoding = \"UTF-8\"], has this file been manually modifie
    ERR OVMXCHK1 "[$NAM] error: VMX file check 1 fail"
fi

So as an excerpt, your issue seems to be local to your server/s, the only way we could offer some further help, would be to login to your system and debug the problem for you. But if the problem was due to some cause other than an xsibackup bug, we would charge the time taken as consultancy.

You try to put the blame on the other side, but you are forgetting about some thousands of users that are using those very same features. Please, try to be positive and focus on finding out why that comparison is not succeding.

You can add the following lines before line 475 to delve into the problem:

VMXFIRSTLINE="$( cat "$VMXFILECONTENTPATH" | head -n1 | head -n1 )"
VMXCONTENTHASH="$( cat "$VMXFILECONTENTPATH" | head -n1 | head -n1 | openssl md5 2>/dev/null | awk -F '=' '{print $2}' )"
echo "VMXFIRSTLINE: |$VMXFIRSTLINE|"
echo "VMXCONTENTHASH: |$VMXCONTENTHASH|"
echo "HARDCODED VALUE: 1077300a4a48cc94a3f8c3bf78d77e3a"
exit 0

This will halt execution, print the first line of the .vmx file, its hash and the value it is compared with.
After running these checks and finding where the problem is, you should delete the remote [b]Onediff[/b] copy and reinitialize the backup job.

support@vom.com · 2018-01-25 23:13:06

We are seeing that also

The First line is >>>>>>> #!/usr/bin/vmware

The Second line is >>>>> .encoding = "UTF-8"

Seems to show up more on our HP servers than our Dell

admin · 2018-01-26 17:16:54

That first line

#!/usr/bin/vmware

Does not follow ESXi standards. Beware of custom builds distributed by manufaturers, they are commercial traps mainly. Always use official ESXi builds, unless you have no other choice. In case of the latter, you'll have to assume you are using a custom build and call your hardware manufaturer with a credit card at hand.

To solve your particular issue, you can disable that check, or delete that first line in your .vmx file, of course, at your own risk. We do not offer support for custom builds.

freephos · 2019-07-07 20:25:37

You are probably using openssl version 0.9.x (which is included with esxi 5.x) where 'openssl sha1' output contains hash only:

esxi-5 # openssl version
   OpenSSL 0.9.8y 5 Feb 2013
esxi-5 # echo  aaa | openssl sha1 
972a1a11f19934401291cc99117ec614933374ce

At esxi-6 openssl output is slightly different and consists of two tokens:

esxi-6 # openssl version
  OpenSSL 1.0.2k-fips  26 Jan 2017
esxi-6 # echo aaa | openssl sha1
(stdin)= 972a1a11f19934401291cc99117ec614933374ce

Regards,
John

admin · 2019-07-09 12:10:04

Extra content is filtered.
That extra line

#!/usr/bin/vmware

is out of place .vmx files do not start by a sheebang.
Start asking yourself what has added that line to the header of the .vmx file

Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

#1 2017-09-28 14:05:48

error OVMXCHK1: VMX file check

#2 2017-09-28 19:13:08

Re: error OVMXCHK1: VMX file check

#3 2017-09-29 07:15:25

Re: error OVMXCHK1: VMX file check

#4 2017-10-01 16:52:25

Re: error OVMXCHK1: VMX file check

#5 2017-10-04 15:01:46

Re: error OVMXCHK1: VMX file check

#6 2017-10-05 07:40:18

Re: error OVMXCHK1: VMX file check

#7 2017-10-15 18:16:52

Re: error OVMXCHK1: VMX file check

#8 2017-10-15 19:24:45

Re: error OVMXCHK1: VMX file check

#9 2017-10-16 13:51:38

Re: error OVMXCHK1: VMX file check

#10 2017-10-16 17:09:43

Re: error OVMXCHK1: VMX file check

#11 2018-01-25 23:13:06

Re: error OVMXCHK1: VMX file check

#12 2018-01-26 17:16:54

Re: error OVMXCHK1: VMX file check

#13 2019-07-07 20:25:37

Re: error OVMXCHK1: VMX file check

#14 2019-07-09 12:10:04

Re: error OVMXCHK1: VMX file check

Board footer