Urgent - Error migrating VM and disks to new datastore

[Westy]

Am trying to migrate a VM (w2k3 DC) from the SAN based storage to the local ESX host disk storage so I can reconfigure the luns on the SAN. Have moved other VM's ok but on this one I continously get the same error which is "field to buffer serialization error". I have tried to look at the VM files inside the datasore folder but it just hangs on "Searching datastore". Even in a CLI session it just hangs if I do an ls command from within the VM datastore folder. The VM fires up ok even after the error.

Has anyone any ideas as to what or why I get this error. Another thing to note is that recently the server name has a (1) appended to the name in VC. I do not know why this appeared.

Cheers

30 minutes later

A bit of an update - the ls command through the CLI has finally come back and I apparently have over 17,000 log files (VMWARE-17649.log etc) Why or how I do not know? I have never done a snapshot on this VM or anything unusual. Can I safely do a "rm*.log" comand from the CLI.

[thesimpsons]

Do you have to run the Storage VMotion live to move the VM to the local storage? if not, I think you can shutdown your VM and try to relocate it. I had similar issue while trying to Storage VMotion one of the VM but it kept returning with error. So, I decided to schedule down time for this VM and relocate it to different data store without any issue. This only thing you need to concern is the down time of this VM while it's being relocated to another data store. It sounds like you have corrupted vmfs conataing this VM. This is just me guest.

[wila]

Can I safely do a "rm*.log" comand from the CLI.

Are those error logfiles in the same folder as your VM? That's how it sounds like... I would not "just" delete them, but actually look inside them, maybe even tar them and/or download them for inspection. Chances are it tells you why you 17000 of them... ?

All these logfiles do indicate your VM does have a problem, it could be traced down to the host, but it really depends. Have you checked the host logfiles?

If you are not able to clone the VM from command line but the VM still runs... you might want to use the ability in vmware converter to install in the guest and hot-clone it that way.

But surely inspect some of those logfiles. If it doesn't give you enough information, then attach one of those logfiles to your reply here and I'm sure someone here is able to understand a bit more of your issue.

--

Wil

Message was edited by: wila, oops forgot to really answer that question.

Yes you can safely delete all those log-files, but beware that you will then never know why it happened (unless you find another 17k files in your VM folder)

[mike_laspina]

Hi,

Thats good advice from wila.

There is something wrong if you have 17000 log files. You need to resolve the issue or at least find out if you are at serious risk or not.

[Westy]

Wila (and others)

Thanks for the replies. Have got rid of log files (eventually) after doing them in batches as reconfiguring luns higher priority. Did an "ls -l" and all log file dates except the current vmware.log were from Dec/Jan/Feb. Cannot remember any problems from then so a bit of a mystery but have attached one of the logs here just for interest as I am not an expert on log files.

Migrated VM ok and has fired up fine.

Thanks again.

[mike_laspina]

It looks like it was failing to power on due to a missing or failed to create the swap file. Could be due to out of disk space on the vmfs volume at the time.

Dec 04 00:57:56.210: vmx| Msg_Post: Error

Dec 04 00:57:56.210: vmx| msg.vmmonVMK.creatVMFailed Could not power on VM : No swap file.

Dec 04 00:57:56.210: vmx| msg.monitorLoop.createVMFailed Failed to power on VM

[Westy]

Cheers Mike.

From memory we did have a power failure at our DR site where this VM & SAN reside and it resulted in a disk failure so maybe that had something to do with it.

Been up and running all afternoon on new luns so hopefully all ok.

[wila]

Just above what Mike highlights, there's this line:

Dec 04 00:57:51.799: vmx| LogBackupByRenumber: failed to remove /vmfs/volumes/456b1ca5-d76d0427-9592-0018fe8025f2/GLO-DC01/vmware-16.log failed: Device or resource busy

Which basically says to me that vmware was unable to perform a rollover of your logs which could explain why you had so many of them.

So I would definately check if you still see the number of logfiles rise to a high number over time and if it does, then their might be a rights issue, although I had expected that the process handling this had enough rights..

--

Wil