An error occurred while quiescing the virtual machine. See the virtual machine's event log for details.

[sandroalvesbras]

Hi,

we are studying this event and found some different information.

1 - In windows 2019 versions with build 1809_1012 onwards this problem has been fixed.

This problem actually occurs in previous versions, when you try to take a snapshot on the VMware console using the quiesc option. Therefore backup tool that using this option suffer from the same problem which was corrected by the operating system with the update.

But my scenario is different ...

My VMs are updated with the build of 1809_1012 and another one with more current and the backup routine that uses the quiesc option works perfectly, but on only VMs that have up to 7 disks on a single SCSI controller. When you add the 8 disk on the same controller the same message occurs.

In my researches I found an article that stated that in Windows 2008 VSS had a limitation of 7 disks per controller and failed when trying to run the snapshot using the VMware console.

However, in my case using the VMware console the snapshot is successfully done using the quiesc option with VMs with more than 7 disks on the same controller.

But when the backup routine tries to use quiesc on this same VM that worked with the snapshot via the VMware console, it fails during the operation.

When I add a new controller and move the disks to the new controller the problem does not occur and everything works perfectly.

I've already done tests adding only the controller and it works on some servers, on others I need to move the disks to a new controller.

Strange that! Has anyone ever experienced this? Do you have any idea why the problem only occurs when we use a backup solution?

I understand that if it was an operating system or hypervisor problem, the problem should also occur when I perform the same operation using the VMware console.

Thank you.

[TheBobkin]

Hello sandroalvesbrasil​,

Taking a snapshot (of any kind) via the vSphere Client vs how your backup solution is doing it is not necessarily using the same API calls and/or mechanisms - thus if it doesn't work as reliably via your backup solution then that is a question for the vendor of the backup solution.

As to why it would work on some VMs but not others is likely a case of load and/or whether the Guest-OSes take being quiesced well or not (and even based on what they are doing at the moment you try this).

Any particular reason you are trying to cram so many disks onto each scsi controller? This is not best practice and any storage-intensive or bursty VMs should have vmdks split out onto multiple controllers.

Bob

[sandroalvesbras]

Hi,

yes, I understand. We are in contact with the backup solution team.

Regarding the number of records I have read on some blogs in the past.

Do you have any technical references to inform me?

Thank you.

[TheBobkin]

Hello sandroalvesbrasil​

Sure:

"When you spread the disks among several controllers, you can improve performance and avoid data traffic congestion."

Add a SCSI Controller to a Virtual Machine

If you look into the whitepapers for configuring virtually anything that might be considered Storage-intensive (e.g. practically any databases), they will advise that each vmdk should be on their own controllers as best practice e.g. 10.1.5 here:

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/vmware-oracle-databases-...

I can't think off the top of my head which product it was, but recall one having it as a mandatory requirement for a support configuration (again, I can't recall if this was due to the nature of shared disks or performance but likely the latter).

Bob

[sandroalvesbras]

Hello,

I did several tests before asking the VMware team for help and found that the following is strictly the case:

When we take a snapshot on the console an error is generated but it does not report any warning of quiesc.

When the backup tool performs its task, the same error occurs and generates a quiesc warning.

In research the documentation cites that this is an old problem of Windows 2008 with Esxi 5.5 that can occur in future versions.

It is interesting that when we add the new SCSI controller, the warning does not happen when the backup routine is performed.

Reading further, the VMware documentation says that for cases like SQL PVSCSI is indicated, but we are dependent on the driver and VMtools and this is complicated.

So the questions remain:

Our version is 6.7 U3

1 - How many controllers can I use on the VM? Are there four SCSI?

2 - What would be the best disk organization for an SQL server? We have already found documentation that says that DB on a disk 1 / SCSI 1, LOG disk 2 / SCSI 2 and TEMPDB disk 3 / SCSI 3, in my understanding is very precious. You don't need that much!

Our concern is that we are limited to the number of disks per controller and we will not be able to grow in the future with more disks as we have this restriction of 7 disks per controller to avoid this error in the backup routine.

Thank you.