I guess there have been good reasons to make such a change, but this can potentially have an impact on some managed systems (as it had in our case) and should have been pointed out in capital letters in the release notes IMHO. But anyway.Before v8 we always used SYSTEM account to perform operations in SQL Server.
But starting from v8, we're impersonating under account specified under "Guest processing".
It turned out that in our case the account specified under "Guest processing", while being a local admin on all vms, had been denied the right to log on interactively for security reasons. In this case any backup with guest processing enabled throws the warning:
"Unable to truncate SQL server transaction logs. Details: Failed to process 'TruncateSQLLog' command.
Failed to truncate SQL logs
Failed to logon user [<domain>\<user>]
Win32 error:Logon failure: the user has not been granted the requested logon type at this computer.
The Windows Security Event log shows 3 times for each backup run the event 4625 ("An account failed to log on") with Logon Type 2 (interactive).
Once granted the account the right to log on interactively, all the warnings disappeared.