VMware Cloud Community
hbowlin
Contributor
Contributor

Error when running vSphere v4.1 Data Migration Script

I am trying to migrate my vCenter and database to vSphere v4.1, but when running the backup.bat script, I am getting the following error.

Msg 8114, Level 16, State 1, Server VCENTER\SQLEXP_VIM, Line 1

Error converting data type bigint to int.

Msg 3013, Level 16, State 1, Server VCENTER\SQLEXP_VIM, Line 1

RESTORE FILELIST is terminating abnormally.

Error: vCenter Server DB backup failed

Exiting...

Any ideas?

0 Kudos
10 Replies
GReddy5
Contributor
Contributor

Did you remember to stop the vCenter server service? Also if you are using windows 2008, make sure to run the command prompt "administrator" if you aren't log on as the local administrator.

0 Kudos
hbowlin
Contributor
Contributor

Yes, both the vCenter service and the Update Manager service were stopped and the script was being run on Windows 2003.

0 Kudos
hooch1964
Contributor
Contributor

Did you find a resolution to this issue? I have exactly the same scenario here.

0 Kudos
PhilMarsden
Contributor
Contributor

I'm also having same problem - anyone got any ideas?

0 Kudos
hooch1964
Contributor
Contributor

We eventually raised a support call on this. The support guy said it was a known issue and that they are working to resolve it. He did not have any details on the possible cause of the issue, but we have a hunch (our hunch, not VMware) that that it may be something to do with the database having been upgraded to 4.0 from the original 3.5 installation.

Although no fix was offered, we didn't need it - the data migration method was not applicable to our upgrade (vCenter 4.0, 32-bit on a physical server backed by SQL 2005 Express -> vCenter 4.1, 64-bit on a virtual server backed by SQL 2008 Standard). We had to migrate the databases manually before running the 4.1 installer and pointing DSN to the new database. We also had to manually copy the certificates from the old to the new server.

Although this does not answer the original problem, there is a way around it.

0 Kudos
spaceboy2011101
Contributor
Contributor

Looks like VMWare guys think our databases are max int bytes long (2GB), so the db upgrade helper script vpx/db/dbrestore.sql defines the temporary table with

BackupSizeInBytes int null,

I've changed it to bigint

BackupSizeInBytes bigint null,

and my upgrade went a few steps further

Just wonder why this isn't fixed in VMware-VIMSetup-all-4.1.0-345042

0 Kudos
dornfm94
Contributor
Contributor

hooch1964,

I actually have to perform the exact same upgrade.

(vCenter 4.0, 32-bit on a physical server backed by SQL 2005 Express -> vCenter 4.1, 64-bit on a virtual server backed by SQL 2008 Standard).

Could you possibly e-mail me your complete list of steps that worked for you?  dornfm94 -at- hotmail -dot- com.

Thank you,

Matt

0 Kudos
moise7864
Contributor
Contributor

spaceboy wrote:

Looks like VMWare guys think our databases are max int bytes long (2GB), so the db upgrade helper script vpx/db/dbrestore.sql defines the temporary table with

BackupSizeInBytes int null

I've changed it to bigint

BackupSizeInBytes bigint null

and my upgrade went a few steps further

Just wonder why this isn't fixed in VMware-VIMSetup-all-4.1.0-345042

The above solution worked great for us.

1. Restoring a DB backup on the old host via SQLExpress tools (there is one in datamigration/data/vc/vc_source_orig_db if you forgot to make one).

2. Modify the dbrestore.sql as mentionned above.

3. Try the procedure again and everything should be fine.

Thanks!

0 Kudos
PhilMarsden
Contributor
Contributor

Hi, I am out of the office, returning on Monday 6th June and will answer your query on my return.

0 Kudos
gparker
Enthusiast
Enthusiast

Hi all,

I just ran into exactly the same issue and found this discussion and followed moise7864's solution and it worked! 🙂

I think that the moral to the story is that even though you might be running SQL-Express, you should still try doing some sort of DB maintanence plan and if your VCDB grows to > 2GB, migrate it to full-blown SQL Server.

George.

0 Kudos