On 3/16/07, Jeff Gribbin, EDS <[EMAIL PROTECTED]> wrote:
To allow complete virtualisation of minidisks of any size up to and including full-pack. Virtualising a full-pack minidisk makes it intrinsically impossible to save hypervisor-related information on the physical pack that's being virtualised - there's nowhere to put it!
Indeed. But VM does not virtualize full-pack mini disks because we share the volser and some more that is found from there. This is why in general we do not hand out mini disks that start at cylinder 0, including full pack mini disks. As the world is today, cylinder 0 is something of the hypervisor. I don't see a problem in using that for hypervisor things (like CSE tracks).
Remember - one is virtualising HARDWARE - so there's no scope for, "agreement" with the (software running in the) guests to not use part of the pack - at best this would lead to a less-than-complete virtualisation.
I beg to differ slightly, SIr. (warning, long post follows) Virtualization is never perfect and differences will always shine through at the edges (most obvious is low-level timing, but there is more). The cost of virtualization (hardware, overhead) gets higher with increased perfection. The reason this still works is because we have an abstraction of the real hardware, and the guest is such that it does not care about details beyond the abstraction (some guests are better than others in that aspect). It gets expensive to achieve a high perfection at low level of abstraction. And unless one specifically cares about those low level details, the guest is better off not to face the real world (e.g. be isolated from hardware errors). Also remember that we have a mix of server virtualization and resource virtualization which blurs the picture. The mini disk is an imperfect (but cheap) implementation of a low level abstraction. The main "defect" is the number of cylinders, but for many purposes the virtualization is good enough because the guest can live with that. But at considerable additional cost, VM could have been designed to span a mini disk over multiple volumes. With such support, you could give out more perfect 3390's (i.e. not being restricted by the actual models on the hardware). And VM could have played tricks not to allocate real disk space for unused tracks. This is exactly what was done in the RAMAC Virtual Array. All VM configuration is in-band in that it lives on VM itself. VM is its own hostage. This is a good thing because that's what allows us to run VM under VM, why you cannot run LPAR within LPAR. Suppose IBM would come up with something on the HMC to maintain the CP directory. An easy-to-use GUI application that talked to CP through some new hack in the SCLP area. That would make it impossible to run VM under VM unless also major parts of the HMC were virtualized (unlikely, at best you would have an option to deal with multiple VM images). PS There's of course hierarchical directories (e.g. LDAP) that would implicitly support such virtualization. I can see some way cool things when a 2nd level VM system would inherit most of the host, except for the parts that you made different. Rob
