PIF: Physical [network] InterFace
SR: Storage Repository / Share Repository
VBD: Virtual Block Device
VDI: Virtual Disk Image
VHD: Virtual Hard Disk (Microsoft)
VIF: Virtual Network Device
| VM | A VM object represents a particular virtual machine instance on a XenServer host or pool. Example methods include "start", "suspend", "pool_migrate"; example fields include "power_state", "memory_static_max", "name_label". (In the previous section we saw how the VM class is used to represent both templates and regular VMs) |
| Host | A host object represents a physical host in a XenServer pool. Example methods include "reboot" and "shutdown". Example fields include "software_version", "hostname" and [IP] "address". |
| VDI | A VDI object represents a Virtual Disk Image. Virtual Disk Images can be attached to VMs, in which case a block device appears inside the VM through which the bits encapsulated by the Virtual Disk Image can be read and written. Example methods of the VDI class include "resize" and "clone". Example fields include "virtual_size" and "sharable". (When we called VM.provision on the VM template in our previous example, some VDI objects were automatically created to represent the newly created disks, and attached to the VM object.) |
| SR | An SR (Storage Repository) aggregates a collection of VDIs and encapsulates the properties of physical storage on which the VDIs' bits reside. Example fields include "type" (which determines the storage-specific driver a XenServer installation uses to read/write the SR's VDIs) and "physical_utilisation"; example methods include "scan" (which invokes the storage-specific driver to acquire a list of the VDIs contained with the SR and the properties of these VDIs) and "create" (which initializes a block of physical storage so it is ready to store VDIs). |
| Network | A network object represents a layer-2 network that exists in the environment in which the XenServer instance lives. Since XenServer does not manage networks directly this is a lightweight class that serves merely to model physical and virtual network topology. VM and Host objects that are attached to a particular Network object (by virtue of VIF and PIF instances -- see below) can send network packets to each other. |
| IF | A PIF (Physical InterFace) object represents an attachment between a Host and a Network object. If a host is connected to a Network (via a PIF) then packets from the specified host can be transmitted/received by the corresponding host. Example fields of the PIF class include "device" (which specifies the device name to which the PIF corresponds -- e.g. eth0) and "MAC" (which specifies the MAC address of the underlying NIC that a PIF represents). Note that PIFs abstract both physical interfaces and VLANs (the latter distinguished by the existence of a positive integer in the "VLAN" field). |
| PBD | A PBD (Physical Block Device) object represents an attachment between a Host and a SR (Storage Repository) object. Fields include "currently-attached" (which specifies whether the chunk of storage represented by the specified SR object) is currently available to the host; and "device_config" (which specifies storage-driver specific parameters that determines how the low-level storage devices are configured on the specified host -- e.g. in the case of an SR rendered on an NFS filer, device_config may specify the host-name of the filer and the path on the filer in which the SR files live.) |
| VHD | VM images are stored as thin-provisioned VHD format files on either a local non-shared file system (EXT type SR) or a shared NFS target (NFS type SR). A Virtual Hard Disk (VHD) is a file formatted to be structurally identical to a physical Hard Disk Drive. |
- Xen: The open source, completely free granddaddy of the Xen family (which at one time had many children, most of whom are now gone.) Xen is different from all of its competitors in that it is a hypervisor ONLY and not a virtualization ecosystem (no management console, no extra features, no nothing.) It's just a tiny little hypervisor. This is confusing because we lump Xen with HyperV, for example, but it is not an apples to apples comparison. Xen is like the hypervisor inside HyperV that no one even knows the name of.
- XenServer: The primary commercial virtualization suite built on technologies derived from Xen. XenServer is an "older" version of Xen with some features removed and other featurs hidden behind "add ons." So XenServer is far less functional than Xen and is not completely free (it can be, but many features are not.) XenServer is a full suite with all of the nice console and tools, APIs, etc. Much more user friendly than Xen and requires no core OS knowledge to get it working unlike Xen that requires you to really know the Dom0 environment well.
- XCP: Xen Cloud Platform. XCP is a full virtualization suite based on Xen. It uses real Xen and combines in all of the other components needed to be a full suite just like XenServer, vSphere and HyperV. It is open source and comes from the Xen people. Today, when people talk about Xen, they mostly talk about XCP as XCP is the apple to apple with the other products and not just the hypervisor. You lose no functionality going with XCP over Xen on its own but it is far easier. XCP is designed to be interoperable with most, if not all, APIs from XenServer so that they can share tools giving XCP a lot of important options.
Virtualization Matrix
No comments:
Post a Comment