Re: Virtualized VMS in clusters (general questions)

On Jun 23, 8:30 pm, wins...@xxxxxxxxxxxxxxxxxxxxxx (Alan Winston -
SSRL Central Computing) wrote:
In article <4860077d$0$6017$ba620...@xxxxxxxxxxxxxxxxxxx>, Wilm Boerhout <w6OLD.PAINTboerh...@xxxxxxxxx> writes:



on 23-6-2008 21:47 Alan Winston - SSRL Central Computing wrote...

And can you also configure a host-id, eg
set $9$DUA container[1]="\\.\PhysicalDrive2" ?

Yes, you can, but the $9$ part has to come from VMS, not from CHARON.
I'm sure that the CHARON software could benefit from something like a
SCSI port allocation class, but I don't see how this would fit in the
current architecture. BTW, your controller designation to VMS can be DU,
DG, DI, etc. independent of the actual hardware. I.e. the SRM console
sees DGA0 disks even if it's a container file.

If I'm getting this, for the SAN device you still have to present the VMS
disk to the Windows box, and just be careful that the Windows box never
writes a "harmless signature" on the disk, right? The Windows box has to
have ownership access because it's going to send out the format/init
whatever operations on behalf of the virtualized VMS box.

Please define "ownership". Windows cannot mess with the disk assigned to
CHARON because the CHARON "process" owns the device. All that's done by
the Windows driver is low-level block I/O. VMS can, no *must*
synchronize using the DLM.

So of course you're running nothing but Charon on the Windows box, and nothing
but Charon can do anything to the device. OK.





(But for corresponding coolness, this means you can run your virtualized VAX
off a fast SAN disk and be in the 20th century without having to get an FC
adapter for your BI bus, if those things even exist.)

This is what we CHARON buffs do routinely :-)

Also, Charon knows what the underlying device is, but VMS doesn't. VMS can't
keep Windows from messing up your underlying devices because it doesn't own
them. Am I also correct that you could really mess up VMS by presenting
the same real physical drive under different names to the virtualized
boxes? All the Distributed Lock Manager has to go on is the device name
from the config file.

(It's okay if the answer is "Yes, you just have to be careful"; I'm just
failing to understand how there even could be any other answer than that
based on what I've learned so far about the virtualized environment. There
are certainly non-virtual circumstances where you have to be careful
(dual-ported RA81s with write access from both sides, for example) too, but
not the same circumstances. SAN disks present with actual device names /
unit numbers, and it's on the SAN administrator to present only to members
of the same cluster. Everybody in the cluster who gets the unit presented
by the SAN will see the same unit, so everybody thinks it's the same
device.

On Windows, you can always identify a SAN "disk" (LUN) by is virtual
SCSI ID. Instead of specifying "\\.\PhysicalDrive0" in the CHARON config
file, you specify "\\.\scsi2: 0 2 1". So, the answer is indeed yes, you
have to be careful, but a SAN administrator always is.

This stuff is very cool.

Amen!

Wilm, this is the stuff that I was incoherently trying to ask about in the
session at the Tech Forum. I don't think I made myself clear there, but I
appreciate your patience.

Thanks!

--Alan

Alan,

As one who worked with VM/370 many years ago, I make the observation
that the fidelity of a virtual machine depends on the particular use
and context. From an applications programming standpoint, virtually
everything should be indistinguishable. As one gets closer to hardware
dependencies, such as multi-threading on multi-processors, the precise
model provided by the underlying VM does become visible. In
particular, one must distinguish between the hardware that the machine
is running on, and the virtual hardware provided to the "guest". They
can, and often are, different.

I was in one of the sessions on HPVM at the HP Technology Forum, and
the question of direct accessibility to FC devices was asked. While my
recollection (I would have to check the presentation and other's
recollection of that session for confirmation) is that the question
was along the lines of "Will we have access directly to FC devices?",
I do not recall the question being "Can I limit direct access to (a)
particular guest(s)?".

The Ethernet switching would have to be switching, not routing, so I
have not heard anything along the lines of restrictions to IP only
protocols.

- Bob Gezelter, http://www.rlgsc.com
.

Relevant Pages

  • RE: Virtualized VMS in clusters (general questions)
    ... VMS will let them know that it is running on virtual hardware. ... Disk drives can either be physical disks or container files. ... If the disk is a physical disk then it can be a LUN on a Fibre SAN, ... Also, Charon knows what the underlying device is, but VMS doesn't. ...
    (comp.os.vms)
  • Re: Virtualized VMS in clusters (general questions)
    ... I'm sure that the CHARON software could benefit from something like a SCSI port allocation class, but I don't see how this would fit in the current architecture. ... BTW, your controller designation to VMS can be DU, DG, DI, etc. independent of the actual hardware. ... disk to the Windows box, and just be careful that the Windows box never ... SAN disks present with actual device names / ...
    (comp.os.vms)
  • Re: Virtualized VMS in clusters (general questions)
    ... Yes, you can, but the $9$ part has to come from VMS, not from CHARON. ... disk to the Windows box, and just be careful that the Windows box never ...
    (comp.os.vms)
  • Re: Dynamic Disk
    ... My question is what is recommended for the san disk Dynamic or Basic? ... It is real easy to increase the size of the lun on the san but what is the ... The disks as Windows sees them will have to be basic. ...
    (microsoft.public.exchange.admin)
  • RE: Disk access performance
    ... influence on how the layout or the design of the SAN should look like. ... > Disk Subsystem Performance Analysis for Windows ... >> we are consolidating a bunch of file servers into one virtual server. ...
    (microsoft.public.windows.server.clustering)
Loading