Registered users
Linkedin Twitter Facebook Google+

In order to improve user's experience and to enable some functionalities by tracking the user accross the website, this website uses its own cookies and from third parties, like Google Analytics and other similar activity tracking software. Read the Privacy Policy
33HOPS, IT Consultants
33HOPS ::: Proveedores de Soluciones Informáticas :: Madrid :+34 91 663 6085Avda. Castilla la Mancha, 95 - local posterior - 28700 S.S. de los Reyes - MADRID33HOPS, Sistemas de Informacion y Redes, S.L.Info

<< Return to index

Troubleshooting Windows Quiescing

See also: Troubleshooting Windows snapshots

As we all know, quiescing Windows Operating Systems is something that can become quite of a problem if you are hosting real time busy I/O services, such as SQL Server, Exchange, or some other service that requires atomic I/O operation consistency. Although when hosting Linux or Unix operating systems in VMWare ESXi, quiescing is not a problem most of the times, performing this operation prior to a snapshot in Windows hosted OSs can become a nightmare.

All this techniques are equally applicable to any other OS which lacks VMWare Tools support.

We have already dedicated some posts to this topic, like: Troubleshooting Windows Snapshots where we covered the matter from a more general OS perspective. Still, in some cases, addressing the problem from a perspective focused on individual services might be required.

Windows OSs behave "different" in VMWare ESXi, when you delve into the matter you realize that, in the end, it's all just something relative to the commercial war between MS and VMWare, and how they utilize these matters to manipulate users.

Nevertheless, a sysadmin needs a way to workaround all this shitty things and be able to properly backup his servers. There are a number of different approaches to the matter: from cold/ warm backups, which implies at a minimum an OS stop of some seconds, to more sophisticated solutions, which are the ones we'll be treating in this post.

As stated, simply setting --backup-how=warm to the backup job will instruct XSIBackup to shutdown the operating system, create a snapshot and start the guest OS right after the snapshot creation. This approach is simple, yet powerful, as it makes sure the snapshot data is consistent. The only drawback is that the OS has to be stopped for some seconds, which is not possible on mission critical services.

A better solution to the problem is to use a database proxy that can hold user queries long enough for the snapshot to be taken without the need to quiesce it. Putting the database server in a paused state in the interim, will allow running queries to finish, the proxy will then cache new queries while the database is paused. Once the snapshot is taken after some seconds, you can just resume the database server operation and the proxy will start to execute any pendant queries.

For the above to be possible, you need a way to run some custom script that executes previous to the snapshot creation and another one once the snapshot creation process ends. VMWare Tools provide us with a mechanism that allows to execute some script previous to the snapshot creation operation and another one once the snapshot has been created. This facilitates the management of pre and post snapshot scripts.

You will find all the datails about how this scripted logic can be applied to different VMWare Tools versions in this VMWare post.

Depending on the services you are hosting, you might need to create different scripts, many software vendors provide their own, although we are taking about one liners like the following to pause the SQL Server service per instance.

And the following to resume it.

If you don't count with a database proxy that can cache your queries when the database service is in a paused state, then don't take the burden to employ this mechanism, as there will be "nobody" there to collect your DB transactions and whatever service makes use of the database server will appear as down and will in turn issue the corresponding connectivity errors. In such cases it's better to just use the --backup-how=warm strategy, as all benefit you will achieve by employing this approach will be an application error thrown to clients, instead of the VM being unavailable during the seconds that a snapshot creation usually last.

Still, even in the case of not having a DB proxy, some Sysadmins, specially in big corporation environments, will probably take the time to script something, at least to let users know the service will be down for some seconds.

Daniel J. García Fidalgo

Website Map
IT Manager
In Site
Resources & help
Index of Docs
33HOPS Forum

Fill in to download
The download link will be sent to your e-mail.

            Read our Privacy Policy