FreeBSD doing a fsck after migration


we have 4 ESX 3.5u1-servers with VMotion and DRS activated, on these servers we have a lot of FreeBSD 6.3 amd64 version installed as guests, but when a migration is done from one host to another the servers starts to do an fsck. All disks are placed on a storage so the disks are never moved. We even saw that servers that didn't get moved started to do fsck when another server was moved.
So we have currently turned of DRS and they have stoped doing fsck.

What could be causing this behavior and how can we solve it? We havn't installed VmWare tools.
Who is Participating?
gheistConnect With a Mentor Commented:
1) You have to apply patch to ESX to make FreeBSD/amd64 work at all
2) VMWare is unaware of FreeBSD v6.3, so go with 70 or 62 to be on supported path
  1. What kind of shared storage are you using?
  2. How many VMs per LUN?
  3. Any clustered disks?
  4. Any scsi reservation messages in the vmkernel log file of these esx hosts?
Have you shut down FreeBSD completely before migration?
Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

BineroAuthor Commented:
1. We have 2 DELL MD3000i with 15x300GB SAS 15000rpm disks in RAID10 to each MD3000i we have connected a DELL MD1000 with the same disk setup, they're connected to the ESX through 2 dedicated DELL PowerConnect 5424, we're using iSCSI.
2. Not quite shure to be honest but we're trying to keep it low, I think somewhere around 10.
3. No
4. Have to check that up.

Yes and when we do that it works, but we can't keep turning the servers of, the we'll loose the purpose with DRS.

I have 3 theories/thoughts:
1. I get the feeling that this happens when a virtual server is moved  from one host to another host and the hosts don't use the same iSCSI path to the storage.
Only thing to back this theory up is from an incident today. We replaced our switches between the hosts and the storage, from DELL PC 2708 to DELL PC 5424. We replaced one switch and when we saw that all paths could be found on the hosts we replaced the second one and when we did this almost all FreeBSD servers froze.

2. VmWare tools are missing on our FreeBSD-servers. Could this cause the issue, in windows there's a huge difference between with/without the tools, does the tools provide a closer co-operation between the host and guest?

3. We replaced our switches between the storage and ESX-servers today, could the problem have been caused by a to slow connection between the hosts and the storage?
It is obviously DRS problem, not FreeBSD's
> and the hosts don't use the same iSCSI path to the storage.

If the path's don't match you'll have worse problems so that can't be the issue here.
>  could the problem have been caused by a to slow connection between the hosts and the storage?
Yes, indeed.
BineroAuthor Commented:
gheist, thanks I'll have a look at those links.

larstr, each has several paths to the storage for  redundancy.
Several paths is a good thing, but the hosts will need to see these the LUNs at the same path.
BineroAuthor Commented:
Seems like that patch did the trick, thanks gheist
As far as I have seen VMs jumps between ESX-es without problems. We have two of them and never had issues bringing one down correctly.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.