No announcement yet.

I know this is way beyond the scope of this forum but... VMWARE issue.

  • Filter
  • Time
  • Show
Clear All
new posts

  • I know this is way beyond the scope of this forum but... VMWARE issue.

    Once a month one of my clients moves their "data center" from location A to B using some VMWARE magic.
    That "cutover" is "supposed" to be instant and even move memory!
    Thing is I think it is causing one of my programs to hang - and yes I have lots of error trapping.
    Screws up the MS SQL Server too. Until my programs are closed then re started.
    Then another error free month.

    I am wondering if I could use the main thread as a watchdog and move the user interface to another thread...
    I could have a separate watchdog program that kills and re-starts the main program.

    By the way how do you programaticaly kill one program from another?

    I have added LOTS more logging to see if I can catch it - little things like does the clock thread keep running?

    I may stay up next time and watch what it is doing.... SQL Cluster on VMWARE - not so simple!!!!

  • #2
    You normally would not be able to kill one task from another, otherwise malware would walk all over your PC. To do so would require the "killer" app to have elevated rights. Try looking at killProcessByName or TerminateProcess.

    What you SHOULD do is signal the app to close from your other one using any number of ways (TCP client/server, named pipes, shared files, etc.). Using this method you can send a "shut down" command via that channel (or for that matter ANY command you design) .
    <b>George W. Bleck</b>
    <img src=''>


    • #3
      Not sure which tech you use to connect to the SQL Server, but the ADO connection object provides events, which your application can react upon.

      And yes - moving (running) VMWare VDs to another VMWare host is instant.

      That said, while going virtual is really a useful way in terms of maintainance, especially (MS) SQL servers need special considerations, if virtualized. This is due to the way SQL server itself is optimized. I'm not the VMWare admin in our company, but do simple operator tasks, so take the below with a grain of salt. Alos, my terminology is not 100% correct, but I hope you do get the picture.

      In a nutshell, the VMWare server (host), shares its physical memory to all virtual machines (VMs) which are allocated to run on it. The server provides RAM as needed/requested by the (OS of the) VM. That enables you to run VMs set up with a total amount of e.g. 100GB RAM on a server that only has 70GB of RAM installed. by swapping around the RAM as needed/requested, the (virtual) OS of the machine will swap RAM to disc perhaps more often than it normally do. And on a real machine, that ofc slows things down. But a VD's hard drive(s) are also virtual, making a swap much more performant, because there isn't actually a physical disc write/read involved. Or at least very seldom.

      Cue SQL server ... unlike other applications, SQL server operates under the assumption that it should utilize all resources available to it. "Gimma all the RAM you've got, OS, as long as I run." In that special case, the above RAM swapping doesn't work as smoothly as it does for other machines. So if you set up a VD for a SQL server, your clients should follow the best practice recommendations out there. Just do a search for e.g. "vmware virtualizing sql server".


      • #4
        We have a VMWare high availability (HA) environment at work. We move running virtual machines (VMs) from one host to another all the time, with no user application interruptions. The VMotion process (as it's called), takes a few seconds, but in our experience, no one ever notices. Most of the PowerBASIC programs that are connecting to the database servers (both MS/SQL and Sybase) do not ever have trouble. My general programming style is to create the db connection when needed for the user-chosen function, then disconnect. Even programs that run 24x7 work this way, rather than opening the db connection at startup and keeping it open.

        Knuth is correct, reading up on how to configure VMs for SQL servers would be useful. You may also want to review the virtual networking. During the VMotion, I have to think there is some type of "burp" as the networking is handed off from one host server to the other, even if it's its for a nanosecond. Usually, this is handled at some underlying networking layer, but maybe its at the root of your problem.
        Real programmers use a magnetized needle and a steady hand


        • #5
          I have added LOTS more logging to see if I can catch it - little things like does the clock thread keep running?
          SQL Tools will give you an error. React to it accordingly which is to probably re-open a connection and continue with the query.


          • #6
            I have SQL tools logging PLUS other stuff - open and close the DB as needed. Thanks Everybody!