vSphere - 19

In the upcoming version of vCenter, the Alarm section is greatly improved. You can create alarm rules which are triggered when an event like powering on a Virtual Machine occurs. Event triggers monitor events that occur on managed objects, vCenter Server, and the License Server. An event is recorded for any action that is of interest to vCenter Server.

I created a new alarm that sends me an email when someone reconfigures one of the virtual machines. As a test, I removed the USB controller from a virtual machine and instantly I received an email from my vCenter Server.                                                

[VMware vCenter - Alarm Test Event] Reconfigured Connection on 192.168.178.251 in NTPRO

Target: Connection
Previous Status: Gray
New Status: Red
 
Alarm Definition:
([Event alarm expression: VM reconfigured; Status = Red])
 
Event details:
 Reconfigured Connection on 192.168.178.251 in NTPRO

You can use vCenter Server to create abstracted network devices called vNetwork Distributed Switches. A vNetwork Distributed Switch functions like a single virtual switch across all associated hosts. This allows virtual machines to maintain consistent network configuration as they migrate across multiple hosts. Like a virtual switch, each vNetwork Distributed Switch is a network hub that virtual machines can use. A vNetwork Distributed Switch can route traffic internally between virtual machines or link to an external network by connecting to physical Ethernet adapters, also known as uplink adapters.

Each vNetwork Distributed Switch can also have one or more dvPort groups assigned to it. dvPort groups aggregate multiple ports under a common configuration and provide a stable anchor point for virtual machines connecting to labeled networks. Each dvPort group is identified by a network label, which is unique to the current datacenter. A VLAN ID, which restricts port group traffic to a logical Ethernet segment within the physical network, is optional.

An alarm action is an operation that occurs in response to a condition, state, or event that causes an alarm to trigger.

In the new version, VMware provides a list of preconfigured actions you can associate with an alarm. For example, alarm actions for hosts include rebooting the host and putting the host in maintenance mode. Alarm actions for virtual machines include powering on, powering off, and suspending the virtual machine.

Although the action are preconfigured, you must manually set up certain aspects of the action, such as having the action occur when a warning is triggered or when an alert is triggered, and whether to repeat the action. You can configure alarm actions to repeat in the following ways:

• At a specified time interval after an alarm triggers. For example, if an alarm triggers because a physical host is not responding, you can have an email message sent every 10 minutes until the host is returned to a connected state or until the alarm trigger is suppressed.
• Until the alarm is explicitly acknowledged by an administrator. When you acknowledge an alarm, the alarm actions are suppressed. The alarm trigger is not reset; it remains in its current state until the triggering condition, state, or event is no longer valid.

Some alarm actions, such as sending notification emails or traps, and running a script, require additional configuration.

 

When you acknowledge a triggered alarm (in the new version), you suppress the alarm actions from occurring. You can configure alarm actions to repeat Until the alarm is explicitly acknowledged by an administrator. After acknowledging an alarm, the alarm actions are suppressed. The alarm trigger is not reset; it remains in its current state until the triggering condition, state, or event is no longer valid.

You can use the next version as a platform for running applications, in addition to using it as a platform for running virtual machines. The applications can be packaged to run directly on top of the next version. The format of how the applications are packaged and managed is called VMware vApp.
vApp has the same basic operations as a virtual machine, but can actually contain multiple virtual machines or multiple services. In the VI client, vApp is both represented in the Host and Clusters view and the VM and Template view. Each view has a specific summary page with the current status of the service and relevant summary information, as well as operations on the service. The distribution format for vApp is OVF. Importing and exporting a vApp is performed as you would import or export a virtual appliance.

Maps are a graphical representation of the relationships between inventory objects. Physical, Virtual, and Custom map types exist for Inventory Maps and Global Maps. You can constrain and filter this information on a vCenter Server-wide level for Global Maps. In the new version you can zoom in only to a certain point, but you can zoom out until the map fits entirely into the window. You can also export maps to various graphic files, including JPEG, TIFF, and GIF.

The list with default alarm definitions in the next version of ESX server has grown tremendously. As you can see in the image the list contains a a lot of new trigger objects. You can monitor the current condition or state of virtual machines, hosts, and datastores. This includes power states, connection states, and performance metrics, such as CPU and disk usage. To set alarms on other objects in the inventory, including datacenters, clusters, resource pools, and networking objects, use event triggers. The Event Triggers monitors events that occur in response to operations occurring with any managed object in the inventory, the vCenter Server system, or the license server. For example, an event is recorded each time a virtual machine is cloned, created, deleted, deployed, and migrated.

 

In the Alarm Settings dialog box, use the Triggers tab to add, edit, or remove alarm triggers. The procedure for setting up triggers depends on whether you are setting the trigger for a condition or state or for an event. What’s new... you can set a condition length.

VMware handles I/O somewhat differently from the manner in which IBM handles it. In the case of VMware, instead of a separate partition and dedicated I/O system, the hypervisor handles I/O itself. "We provide a virtual device or virtualized drivers for Intel E1000 and AMD VLANCE," said VMware's Chief Platform Architect Richard Brunner. He said that the company also provides a virtual device called VMXnet. "When these devices attempt to access physical hardware, all their writes are trapped to the hypervisor, which turns around and places the request in a stack in the hypervisor," said Brunner. He added that the hypervisor has a queue that the physical device driver then has to take care of.

Read the full interview by Wayne Rash at Server Watch

According to Bogomil Balkansky, senior director of product marketing at VMware, the naming convention for the future ESX Server (or ESX Servers, as the case may be) has not been set, even if people are referring to this future product as ESX Server 4.0. He says that there will be some product rebranding in 2009.

The current ESX Server hypervisors support up to 64 GB of main memory to be allocated to a single virtual machine on a server, and the VirtualSMP feature of the hypervisor (which allows a VM to span multiple cores or processor sockets) can only span up to four x64 cores right now. Balkansky says that in 2009, the hypervisor will double VirtualSMP capability to eight cores and with quadruple memory to 256 GB maximum per virtual machine. By the way, that is cores, not threads. While the ESX Server can certainly see and use multiple threads in a processor core, if they are there - some Intel chips have virtualized threads created by the chip hardware to boost their efficiency, while Advanced Micro Devices' Opterons do not have simultaneous multithreading (which is silly, really) - these threads are not seen by the hypervisor as a core even if applications riding atop the operating system treat threads as if they were separate cores.

Read the full interview by Timothy Prickett Morgan at Channel & Register

Vsphere targets the mobile user with live feed "WHEN" the user wants it. The mobile device can be undefined, the mobile browser undefined as well as any computer [ Local / Remote ] should be able to connect to vsphere. How does VSphere Work ? VSphere functions at 3 levels:   The Image Server.   The camera System.   Connecting Clients - Local and Remote. Vsphere converts the computer on which it is loaded into a image server. The application then connects to the attached cameras. You can specify video codec, video display, video format and the video source for each camera connected. The properties page that will be displayed for each element will depend on the type of camera[s] connected to the system.