So regardless of MDC settings, it doesn't matter where the guest runs
when IO is required. Only when moving guests around MDC could be a
potential problem. That is not the case, at least not at the moment.

Thanks, Berry.

-----Original Message-----
From: Linux on 390 Port [mailto:[email protected]] On Behalf Of
Rob van der Heij
Sent: maandag 23 maart 2009 13:20
To: [email protected]
Subject: Re: Share DASD in 4 VM's

2009/3/23 van Sleeuwen, Berry <[email protected]>:

> Now let's look at the sharing of DASD volumes and with multiple
> (non-CMS) minidisks on them. What, if any, would be the penalty if the

> DASD is shared on multiple VM's with linux minidisks? Like I stated 
> before, VSE can't handle this if DASD is not set to SHARED (either 
> minidisk or fullpack volumes). Would we get some unexpected IO queuing

> or even locks when two minidisks are accessed at the same time from 
> different VM's? (Or to put it like this: if we start a guest om VM1 
> would the guest on VM2 still be able to access his minidisk that lives

> on the same pack?)

With reserve / release it's different because the protocol is to ensure
exclusive access to the real volume while the reserve is held.
If you would put other data on the same volume, you risk being locked
out too long or even risk a deadly embrace.
When a real volume is just shared between two systems in that users on
both systems use different mini disks on it, then it's up to the DASD
control unit to review the I/O's and see which can be done in parallel.
Each guest I/O specifies the range of cylinders that it operates on,
worst case the full mini disk. So to the control unit it will be clear
that different virtual machines don't interfere and could go in
parallel.

In your case, spreading the virtual machines over multiple z/VM LPARs
may even be an advantage. When the virtual machines run in the same
z/VM, then CP will queue the I/O from the users for that volume and it
requires work from CP to start the next I/O in the queue once the
previous one completed. When you're on different LPARs, the I/O will
queue in the DASD control unit and is performed without any CP
intervention.

Re your idea to have MINIOPT to disable MDC: be aware when you have also
overlapping full pack MDISK definitions (for backup for example).
Unless those also have the MINIOPT on that MDISK (which you probably
should) then that would still get data in MDC and may surprise the guest
when he travels.

Rob
--
Rob van der Heij
Velocity Software
http://www.velocitysoftware.com/

----------------------------------------------------------------------
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 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
ÿþDit bericht is vertrouwelijk en kan 
geheime informatie bevatten enkel

bestemd voor de geadresseerde. Indien 
dit bericht niet voor u is bestemd,

verzoeken wij u dit onmiddellijk aan 
ons te melden en het bericht te

vernietigen.

Aangezien de integriteit van het 
bericht niet veilig gesteld is middels

verzending via internet, kan Atos 
Origin niet aansprakelijk worden 
gehouden

voor de inhoud daarvan.

Hoewel wij ons inspannen een virusvrij 
netwerk te hanteren, geven

wij geen enkele garantie dat dit 
bericht virusvrij is, noch aanvaarden 
wij

enige aansprakelijkheid voor de 
mogelijke aanwezigheid van een virus in 
dit

bericht.

 

Op al onze rechtsverhoudingen, 
aanbiedingen en overeenkomsten 
waaronder

Atos Origin goederen en/of diensten 
levert zijn met uitsluiting van alle

andere voorwaarden de 
Leveringsvoorwaarden van Atos Origin 
van toepassing.

Deze worden u op aanvraag direct 
kosteloos toegezonden.

 

This e-mail and the documents attached 
are confidential and intended solely

for the addressee; it may also be 
privileged. If you receive this e-mail

in error, please notify the sender 
immediately and destroy it.

As its integrity cannot be secured on 
the Internet, the Atos Origin group

liability cannot be triggered for the 
message content. Although the

sender endeavours to maintain a 
computer virus-free network, the sender

does not warrant that this transmission 
is virus-free and will not be

liable for any damages resulting from 
any virus transmitted.

 

On all offers and agreements under 
which Atos Origin supplies goods and/or

services of whatever nature, the Terms 
of Delivery from Atos Origin

exclusively apply. 

The Terms of Delivery shall be promptly 
submitted to you on your request.

 

Atos Origin Nederland B.V. / Utrecht

KvK Utrecht 30132762

Reply via email to