VMWare and VMotion

[John.M]

We are using VMware 3.5 enterprise edition in a 3 host cluster configuration running FMSA 10.2.x on Win2003 Server. The database server does not start when Vmotion moves the FM server to another host.

If the VM gets manually moved back to the original host, the db server starts and the databases come up. This becomes an issue if the original host goes down or the load balancer decides to move the FM server VM to another host.

Is anyone else using VMware and have a solution to this?

Thanks,

John

[Hijack]

What is your startup error when you try to start the service on a new host? We have several FM v10 servers (standard and advanced) installed on our VMWare farm and I haven't seen this behavior here.

[John.M]

Hello,

I went through the event log and pulled the related logs during one of the startup attempts.

Type: ERROR, Source: FMSocket_SL5S Event ID: 0 -

The description for Event ID ( 0 ) in Source ( FMSocket_SL55 ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: FMSocket_SL55@localhost,ErrorCode=3021,ErrorMessage=Internal error, unable to load the server configuration file %s..

Type: Warning, Source: Event System, Event ID: 4354 -

The COM+ Event System failed to fire the PostShell method on subscription {E2DFADF6-372C-49DF-9E30-68F1F88FD398}-{00000000-0000-0000-0000-000000000000}-{00000000-0000-0000-0000-000000000000}. The subscriber returned HRESULT 80004001.

Type: Error, Source: Filemaker Server 10; Event ID: 50 -

Registration with directory service failed because of insufficient access.

[John.M]

Are you able to let Vmotion successfully move a VM to a different host?

[Wim Decorte]

We use VMware/Vmotion here on all of our FMS boxes But we did have a bunch of problems with SL_55. To the point that we removed everything that relies on xDBC.

The issues that we experienced was that SL_55 errors would show up in the event log and it would send FMS into a 100% CPU usage funk that it could not recover from. It would also not let the files be closed gracefully.

Open a support ticket with FMI and send them all the event logs and the FMS logs and describe the exact sequence of events. This is important and the more info they get on this the better for us.

[Wim Decorte]

When you talk to FMI, tell them to focus on this part of the SL55 error message:

Hello,

FMSocket_SL55@localhost,ErrorCode=3021,ErrorMessage=Internal error, unable to load the server configuration file %s..

When I talked to them they would tend to focus on the first part of the error description but the real meat is in the last part.

[John.M]

Hi Wim,

It sounds like your issue might be slightly different. Our issue only seems to come up after a maintenance window and the VM's are booting up. I haven't (yet) seen an issue yet where the server gets moved after it's up, but I've been wondering what happens if that were the case.

I already spoke to FMI and the suggestion was to post something in the forums. I'm getting the impression this is something that may need to be escalated?

Thanks for your input.

John

[John.M]

Does anybody know if the server registration is tied to the mac address? The IT guys are theorizing that might be the cause of the problem.

[Wim Decorte]

Does anything seem weird in the

Database ServerExtensionsxDBC Support subfolders?

Not sure if you have another FMS install to compare it with...

[John.M]

I don't know if it's "weird" or not, but when I compare the servers two have a folder under xDBC Support called "Logging" and in that folder, there's a file called "SLSocket55.trc".

Another server has the "Logging" folder but no file. Another server doesn't have the "Logging" file at all.

Three of the four servers are configured the same. The last one doesn't have any web components installed, just ODBC and is the one without the "Logging" folder.

Good catch. Have you spoken to FMI and gotten any response as to what that particular file is? Seems odd that it's not in every install, or at least the ones with the same config.

John

John

[Wim Decorte]

I've just checked our installs and the Logging folder is empty so you can safely archive that trc file. Seems to me it's some sort of debug output. At one point after a crash we literally had thouseands of tiny text files in that logging folder.

Haven't talked to FMI about it though...

[John.M]

Hi Wim,

An update to what's been going on...

We set up a test VM with the same fms configuration as the VM I'm having issue with, but this time giving the test VM a static mac address.

We've been able to start the VM up on any of the three hosts. I also set up a looping script to generate data in a field and validate it, all while migrating the VM to different hosts while the script was running. All of the data was there at the end.

I don't know if the static mac address fixes the problem or if there is some issue with the original VM install.

John