Hi, On Mon, Apr 19, 2010 at 12:44:20PM +0200, Lars Ellenberg wrote: > On Mon, Apr 19, 2010 at 11:07:31AM +0200, Florian Haas wrote: > > On 2010-04-19 11:02, Cristian Mammoli - Apra Sistemi wrote: > > > On 04/16/2010 08:56 AM, Marko Potocnik wrote: > > >> Hi, > > >> > > >> we're also using vmware resource agent at out company and we found > > >> problems with stopping virtual machines and unmounting underlaying > > >> filesystem right afterwards. Filesystem was still in use and umount > > >> failed. > > >> Solution was to call "sync" after virtual machine was stopped. Here is > > >> the diff against latest version: > > >> > > >> 293c293,295 > > >> < ocf_log info "Virtual machine $VM is stopped" > > >> --- > > >> > ocf_log info "Virtual machine $VM is stopped. Syncing Disks." > > >> > sync > > >> > ocf_log info "Sync Completed." > > >> > > >> Sync would take from a few seconds to a minute or two. Could this "fix" > > >> be added to official vmware resource agent? Does anybody have any other > > >> solution? > > >> > > > > > > That should be a job for the Filesystem resource agent, you should raise > > > timeouts there imho... Anyway it doesn't hurt at all. Ask Florian to add > > > your patch in the next release. > > > > No, that is indeed a job for the Filesystem RA.
The VM resource doesn't have to be on a filesystem, right? ... > Umount _implies_ a "sync", namely of the pages backed by the file system > to unmounted. Yes that may take considerable time, if it is a huge file > system, the amount of dirty pages is allowed to grow to an extend that > writing them all out simply takes some time. ... and umount must do a sync beforehand. > I'd really expect of a VM (guest) and Virtualization platform (host) > that dirty pages corresponding to VM data are safely on disk (synced) > once it is stopped, so the implicit syncing of the umount should > not have anything to do anyways. I'm not sure about this. The virtualization may just rely on the host disk subsystem to do the right thing. Though my experience is very limited with the virtualization technology. > If you really got a "file system is still in use" problem, > I don't think sync was the solution, but simply changed the > timing so much that who ever was using it, stopped doing so > once the sync was done. > > If you simply ran into the timout of "Filesystem stop", > incease it. Right. Would that help? Cheers, Dejan > If there has been some user of the filesystem, and that > was a normal process not doing anything fancy, > it should be killed implicitly by the "Filesystem stop". > > If in fact some part of the virtualization stuff still uses the device > even after the "stop" action was "completed sucessful", then the > probably the stop action of the VM should be fixed. But I doubt that, > and I don't think "sync" at that place solves anything, really, even > though it may be a valid workaround for you for the time being. > > -- > : Lars Ellenberg > : LINBIT | Your Way to High Availability > : DRBD/HA support and consulting http://www.linbit.com > > DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
