Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

It's just a warning, you can ignore it.

We have checked XSIBackup with a number of e-mail servers, Microsoft's is among them.
You have two choices:

1 - Use GMail, Hotmail, Yahoo, etc...
2 - Debug your SMTP session to find out which is the exact cause.

[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.

You have mixed two things here:

1 - Only one process is allowed at a time. "This execution request will be ignored." means, I will stop here.
2 - XSIBackup will probe the port before sending the e-mail. I'm afraid you'll need to debug your SMTP session. The server is responding, but by some reason it might stop waiting for some command.

That behaviour is totally normal. ESXi's cron (/var/spool/cron/crontabs/root) is not persistent.
Don't ask us why, if you are interested in this subject, just open a topic at VMWare's forum and see if they give you a proper answer.

You do not need to deal with that, XSIBackup offers [b]--install-cron[/b] argument to install and uninstall the crontab with just a keystroke. If you experience problems like the one you are describing, please read this post thoroughly
[url]https://33hops.com/xsibackup-cron-how-to.html[/url]

The first thing to take on account is, not to use custom ESXi builds distributed by server manufacturers. We have found them to be very buggy, some of them plainly remove some ESXi features or basic design principles.

On the other side, you have to take on account that ESXi's cron service is not very refined, to put it mildly. You may need to reboot the server once you have installed it. So, what I would do is to:

- Install cron via the [b]--install-cron[/b] argument.
- Check that the [b]/etc/rc.local.d/local.sh[/b] file contains the line to push the xsibackup cron call into the [b]/var/spool/cron/crontabs/root[/b] file.
- Reboot the server.
- Check that the [b]/var/spool/cron/crontabs/root[/b] file contains the xsibackup-cron call.

If your cron file is still not working:

- Check that the [b]crond[/b] service is loaded.
- Check that you have execute permissions on the [b]xsibackup-cron[/b] file.

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.

We fixed that already in the Free version of the install script

In some weeks...

The crontab file is not called [b]xsi-backup-cron[/b], but [b]xsibackup-cron[/b]

Just set the variable [b]xsidefaultpath[/b] accordingly to your needs at the top of the script.

O.K., this is something for us to check. I guess you left the CD .iso file attached to the VM

/vmfs/volumes/59a55e51-23ebeea2-f574-001b214be631/****ISO***/debian-8.9.0-i386-netinst.iso

On the other side the asterisks in the path may be causing the sed regexp to fail.
Now I'm wondering if this could be causing side effects in regards to the first empty 50M.
Please, remove that .iso file and give feedback.

Please, upgrade to latest version. We have fixed many non critical bugs lately.