Tracker item #3485535, was opened at 2012-02-07 16:25
Message generated for change (Comment added) made by adroit
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3485535&group_id=204462
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: guestd
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Troy Bowman (adroit)
Assigned to: Nobody/Anonymous (nobody)
Summary: vmtoolsd quiesce for snapshot and multiple root mtab entries
Initial Comment:
I don't know if the previous "quiescing fails on ubuntu" bug has anything to do
with this, but here is what I am seeing on Gentoo.
A feature of the 2.6 kernel is that rootfs is inherent and gets overmounted by
the real root later in the boot process.
From: /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt
"Rootfs is a special instance of ramfs (or tmpfs, if that's enabled), which is
always present in 2.6 systems. You can't unmount rootfs for approximately the
same reason you can't kill the init process; rather than having special code
to check for and handle an empty list, it's smaller and simpler for the kernel
to just make sure certain lists can't become empty.
"Most systems just mount another filesystem over rootfs and ignore it. The
amount of space an empty instance of ramfs takes up is tiny."
This is the very thing that is happening on my Gentoo system, as I have two
rootfs entries:
# cat /etc/mtab | head -2
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,noatime,errors=continue,barrier=0,data=ordered 0 0
And as I strace vmtoolsd during a vm snapshot with filesystem quiescing on, I
can see that it is trying to FIFREEZE both root entries, only to fail on the
second one and then and the entire operation aborts.
open("/etc/mtab", O_RDONLY) = 20
fstat(20, {st_mode=S_IFREG|0644, st_size=985, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fdbe1ec7000
read(20, "rootfs / rootfs rw 0 0\n/dev/root"..., 1024) = 985
read(20, "", 1024) = 0
close(20) = 0
munmap(0x7fdbe1ec7000, 4096) = 0
open("/", O_RDONLY) = 20
ioctl(20, FIFREEZE, 0x14) = 0
open("/", O_RDONLY) = 21
ioctl(21, FIFREEZE, 0x15) = -1 EBUSY (Device or resource busy)
close(21) = 0
ioctl(20, FITHAW, 0x3) = 0
close(20) = 0
sendto(16, "<12>Feb 7 17:09:26 vmsvc[3013]:"..., 84, MSG_NOSIGNAL, NULL, 0) =
84
I tested the same operation on the same system using the official tools
binaries from VMWare, and they do not suffer from this problem.
I wonder if Open Virtual Machine tools could be more intelligent about
freezing filesystems, by not trying to freeze the same filesystem more than
once.
Thanks.
----------------------------------------------------------------------
>Comment By: Troy Bowman (adroit)
Date: 2012-03-14 18:02
Message:
For what it's worth, my current workaround is to edit /etc/init.d/mtab, and
change the line from:
grep -v "^[^ ]* / tmpfs " /proc/mounts > /etc/mtab
to:
egrep -v "^[^ ]* / tmpfs|rootfs" /proc/mounts > /etc/mtab
Although, I would much rather have open-vm-tools be more intelligent.
----------------------------------------------------------------------
Comment By: Eric Johnson (ericejohnson)
Date: 2012-03-13 04:16
Message:
I can confirm that I see this problem as well on Gentoo Linux. I see no
problems with kernel version 2.6.33. Subsequent kernels that I've tested,
however, don't work.
This is particularly problematic, because the latest stable gentoo uses a
udev version that frowns upon kernel versions before 2.6.33, and the
earliest stable version after that - as of this comment - is 3.0.17
(http://packages.gentoo.org/package/sys-kernel/gentoo-sources)
So for Gentoo, this really needs a fix, because there's currently no way to
bring up a new stable Gentoo system and use the open-vm-tools without
running into this problem.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3485535&group_id=204462
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
open-vm-tools-devel mailing list
open-vm-tools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
