Actually, V-DISK space can be shared. We use it to share the VSE lock file among several VSE guests. The V-DISK space is defined with an MDISK statement to one virtual machine, and the others have to LINK to it, same as any other minidisk. In our case, the V-DISK is owned by AUTOLOG1, who formats it during system IPL. As a protection against unusual conditions, each VSE guest checks the disk in their PROFILE EXEC to see if it is formatted, and if not, they format it.
Sharing or V-DISK, while possible, is only useful and safe in a very, very small set of circumstances. I strongly doubt that Linux would qualify for this in any way shape or form. -----Original Message----- From: Adam Thornton [mailto:[EMAIL PROTECTED] Sent: August 12, 2004 15:21 To: [EMAIL PROTECTED] Subject: Re: V-DISK Swap - allocation size - Our VM guy has this to ask: On Aug 12, 2004, at 2:03 PM, James Melin wrote: > 1) V-DISK blocks appear to be 512 byte blocks & are created in 8-block > pages. True? Dunno about the 8-block pages. But they are 512-byte blocks. > 2) Will all Linux guests, that contain "MDISK 300 FB-512 V-DISK 256000 > MWV" share the same V-DISK space? If so is one 256000 block area > allocated > & shared or (256000 x #-of-Linux's) allocated & all shared? Each VDISK space is private to the guest. VDISK is not shareable. > 3) How will you automatically know when a given Linux is the first and > therefore needs to format the area, if area(s) are shared? You won't: each guest has its own space. > 4) SuperValu Red Paper suggests V-DISK size 15% of VM size, what's up > with > this formula 2 x VM size + 32M ?? > I don't remember the paper in any detail. If that's *all* the swap they have, I'd be concerned that either they fail to allocate memory pretty often, or that they have too much virtual storage defined for their guests and they're wasting a lot of storage in file caching. If that's high-priority swap backed by low-priority swap on real DASD it sounds reasonable. If their applications cause very little fluctuation in the amount of memory the system uses (for example, a select-based (not fork-and-exec or thread-creating) server, fixed-size preallocated buffers) then 15% might be adequate. David's recommendation basically comes from the old-school Unix 2.5 x physical memory rule-of-thumb; I usually start at 1-to-1.5 times physical memory, assuming that the memory has been squeezed down enough that very little is used for file or buffer cache. Adam ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ______________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon, this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error, please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail, or for the consequences of any actions taken on the basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
