Although this is a relatively old question, the answer is still the same. You have a virtual machine (running on a physical host) and some sort of storage (either shared storage – a FC SAN, iSCSI storage, an NFS share – or local storage).
With virtualisation, many virtual machines try to access the same physical resources at the same time. Due to physical limitations (number of read/write operations – IOPS; throughput; latency) there might be a problem to satisfy all storage requests of all physical machines at the same time. What usually happens: you will be able to see "SCSI retries" and failed SCSI operations in the operating systems of your virtual machines. If you get too many errors/retries in a certain period of time, the kernel will set the mounted filesystems read-only in order to prevent damage to the filesystem.
To cut the long story short: Your physical storage is not "powerful" enough. There are too many processes (virtual machines) accessing the storage system at the same time, your virtual machines do not get the response from the storage fast enough, and the filesystem goes read-only.
There are not terribly many things you can do. The obvious solution is better/additional storage. You can also modify the parameters for SCSI timeouts in the Linux kernel. Details are described, e.g., in:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009465
http://www.cyberciti.biz/tips/vmware-esx-server-scsi-timeout-for-linux-guest.html
However, this will only "postpone" your problems, because the kernel only gets more time before the filesystem will be set read-only. (I.e., you do not solve the cause of the problem.)
My experience (several years with VMware) is that this problem only exists with Linux kernels (we're using RHEL and SLES) and not with Windows servers. Also, this problem occurs on all sorts of storage – FC, iSCSI, local storage. For us, the most critical (and expensive) component in our virtual infrastructure is storage. (We're now using HP LeftHand with 1 Gbps iSCSI connections, and have not had any storage issues ever since. We chose LeftHand (over traditional FC-solutions) for its scalability.
In case anyone ends up here like I did, this command kicked the sync into high gear for me:
echo max | sudo tee /sys/block/md0/md/sync_max
Best Answer
The problem lies in the syntax used in the linked article. To understand what exactly goes wrong, let's have a look at
man wall
:Usage from
man wall
:So
wall
accepts either of two sources for its message.File name argument
Any command line argument given to
wall
has to be a file name. As there isn't a reliable way to tell if the argument is meant as message or file name,wall
will assume it's the latter, ignore anything coming in on standard input, and try to read the message from that file.In the given case, it tries to read from the file
who's out there
and does not find it. Note that reading from a file is usually restricted to the superuser. If you'd executedwall "who's out there"
as an unprivileged user, likely its output would have been,wall: will not read who's out there - use stdin.
Standard input
If it doesn't get a file name argument on its command line, it will start reading from standard input. There are several ways to feed information to the standard input of a command. One is to use a UNIX pipe. A pipeline will connect the standard output of its lefthand-side command to the standard input of its righthand-side command:
Another way is to use a here document. A
here document
is a shell construct that passes a string (up to a specified end marker on a line of its own) directly to the standard input of a command, without the intermediate step of having a distinct command produce that output:This would be a "useless use of here documents", because by default the terminal itself will be connected to
wall
's standard input andwall
will start reading from it until it receives an end-of-file character (Ctrl+D):As Rich Homolka noted in the comments, some shells support
here strings
which allow passing a literal string without command or end markers:All feed something to
wall
's standard input. The difference is that a pipeline connects the output of another command to it, whilehere documents
andhere strings
pass the string directly. The latter two's advantage here is an aesthetic one, as theecho
command from the pipe example is a shell built-in command, so it will be the shell providingwall
's input in all cases.