Thanks, my concern was to be sure that the vdisk was assigned to the guest and won't affect the others, which you clarified. We have this same definition for all users.
MDISK 203 FB-512 V-DISK 409600 MR READ WRITE MULTIPLE MDISK 204 FB-512 V-DISK 2097152 MR READ WRITE MULTIPLE If it weren't for this list and google, I would be digging ditches. -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Scott Rohling Sent: Wednesday, April 20, 2011 11:27 AM To: [email protected] Subject: Re: vdisk To clarify.. the vdisk is specified in number of 512 byte blocks. CP manages where these virtual disks start/end in memory -- you don't need to be concerned about managing them, if this is what you meant. You may want to consider setting system/user limits though, to ensure you don't use up all your memory with vdisks. Scott Rohling On Wed, Apr 20, 2011 at 9:21 AM, Scott Rohling <[email protected]>wrote: > Yes - each vdisk is assigned to the guest.. anything done to it won't > affect other guests. Not sure what you mean by fixed block definitions > being the same .. they can be the same or different if what you mean is > formatting? > > Scott Rohling > > > On Wed, Apr 20, 2011 at 8:56 AM, Dean, David (I/S) > <[email protected]>wrote: > >> Thanks to all for the information. Now that I have your attention, is it >> ok for the fixed block definitions be the same for all users, i.e. the vdisk >> definition (the memory address) lives within the user definition, and not >> the entire zvm? Resetting one user will have no affect on others? >> >> -----Original Message----- >> From: Linux on 390 Port [mailto:[email protected]] On Behalf Of >> Scott Rohling >> Sent: Wednesday, April 20, 2011 10:38 AM >> To: [email protected] >> Subject: Re: vdisk >> >> Exactly - vdisk is in memory and will be lost if the guest is logged off >> -- >> so must be formatted for swap and mounted as swap by Linux when the guest >> is started.. >> >> Scott Rohling >> >> On Wed, Apr 20, 2011 at 8:15 AM, RPN01 <[email protected]> wrote: >> >> > Since it's a fresh disk every time, you'd have to do the mkswap every >> time >> > you log in, so my guess is that's why you'd need the mkswap and >> subsequent >> > swapon in the boot.local. The vdisk wouldn't be formatted when you get >> it >> > at >> > each fresh logon. >> > >> > -- >> > Robert P. Nix Mayo Foundation .~. >> > RO-OC-1-18 200 First Street SW /V\ >> > 507-284-0844 Rochester, MN 55905 /( )\ >> > ----- ^^-^^ >> > "In theory, theory and practice are the same, but >> > in practice, theory and practice are different." >> > >> > >> > >> > On 4/20/11 9:06 AM, "Dean, David (I/S)" <[email protected]> wrote: >> > >> > > Ok, we have it working. Defined it in User Directory, formatted it >> for >> > swap, >> > > added it to fstab, and added it to boot.local -> mkswap and swapon. >> > > >> > > Why did I have to add it boot.local? why does it not act like a >> normal >> > DASD >> > > drive and come on at boot? >> > > >> > >> > ---------------------------------------------------------------------- >> > 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 >> > ---------------------------------------------------------------------- >> > For more information on Linux on System z, visit >> > http://wiki.linuxvm.org/ >> > >> >> ---------------------------------------------------------------------- >> 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 >> ---------------------------------------------------------------------- >> For more information on Linux on System z, visit >> http://wiki.linuxvm.org/ >> ----------------------------------------------------- >> Please see the following link for the BlueCross BlueShield of Tennessee >> E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm >> >> ---------------------------------------------------------------------- >> 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 >> ---------------------------------------------------------------------- >> For more information on Linux on System z, visit >> http://wiki.linuxvm.org/ >> > > ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ ----------------------------------------------------- Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
