FreeBSD doing a fsck after migration
Hi,
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.
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.
larstr
- What kind of shared storage are you using?
- How many VMs per LUN?
- Any clustered disks?
- Any scsi reservation messages in the vmkernel log file of these esx hosts?
Have you shut down FreeBSD completely before migration?
ASKER
larstr:
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.
gheist:
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?
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.
gheist:
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 another fsck against FreeBSD 6.3:
http://pubs.vmware.com/guestnotes/wwhelp/wwhimpl/common/html/wwhelp.htm?context=guestnotes&file=GuestOS_install.3.3.html
http://pubs.vmware.com/guestnotes/wwhelp/wwhimpl/common/html/wwhelp.htm?context=guestnotes&file=GuestOS_install.3.3.html
> 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.
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.
ASKER
gheist, thanks I'll have a look at those links.
larstr, each has several paths to the storage for redundancy.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.