Patent Application
20070055740
This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
As most people are aware, computers and computer networks continue to play an increasingly important role in society. From small scale office networks to large scale networks, such as the Internet, it cannot be denied that computer networks play an important part in global communications and information systems. At the heart of computer networks are the computers themselves. Even though computers in general have become much more reliable over the past few years, most computers still benefit from periodic maintenance, updates, or repairs. Until a few years ago, the more prevalent technique for performing this maintenance was for a technician to sit down in front of a particular computer and use the particular computer's keyboard, mouse, or disk drives to perform the maintenance. Several years ago, however, many types of computers began to leverage computer networks to enable technicians to perform maintenance or monitoring remotely from another computer somewhere else on the computer network.
Advantages of the invention may become apparent upon reading the following detailed description and upon reference to the drawings in which:
One or more specific embodiments of the present invention will be described below. In an effort to provide a concise description of these embodiments, not all features of an actual implementation are described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
The exemplary embodiments described below are directed towards a system or a method for interacting with a remote computer. For example, in one embodiment, a host computer contains a circuit that is configured receive commands from a remote computer and to transmit status data associated with the host computer hardware to the remote computer. In another embodiment, a remote computer is configured to create a graphical control panel, to receive hardware status data generated by host computer hardware, and to display the status data in the graphical control panel.
Turning initially to
The host computer 12 may include one or more central processing units (“CPU”) 18. The CPUs 18 may be any suitable number of physical or logical CPUs, such as the Intel Pentium IV Processor or the Intel Xeon Processor. The CPUs 18 may be configured to execute instructions stored on a host memory 20. For example, in one embodiment, the CPUs 18 may execute instructions stored on the memory 20 to route data across the network 14.
The CPU 18 may be coupled to a motherboard 22 of the host computer 12. In one embodiment, the motherboard 22 controls the routing of signals and instructions within the host computer 12. The motherboard 22 may be coupled to an external device interface 24, indicator light emitting diodes (“LEDs”) 26, control switches 27, and a power switch state machine 28. The external device interface 24 may be any suitable form of computer interface. For example, the external device interface 24 may be a Peripheral Components Interconnect (“PCI”) interface, a PCI-X interface, a PCI Express interface, a Fibre channel interface, a fiber optic interface, a Small Computer System Interface (“SCSI”), an Ethernet interface, a Universal Serial Bus (“USB”) interface, a Firewire interface, a Fibre-SCSI interface, a Serial Advance Technology Attachment (“SATA”) interface, a Serial Attached SCSI (“SAS”) interface, and so forth. As illustrated in
The indicator LEDs 26 enable the host computer 12 to display visually one or more status indicators without using a computer monitor. For example, in one embodiment, the indicator LEDs may illuminate to indicate access to a storage device, access to a network, an error or failure of the host computer 12, and so forth. In another embodiment, the indicator LEDs 26 may be configured to display power-on self test (“POST”) codes or other milestone codes emitted by the host computer during the boot process. In still another embodiment, the indicator LEDs may display the power state of the host computer 12 (e.g., on, standby, sleep, hibernate, off, and the like).
The control switches may permit a user to interface or send commands to the motherboard 22. For example, the control switches 27 may include a sleep button that, when pressed, causes the motherboard 22 to initiate a lower power state. The control switches 27 may also include a non-maskable interrupt (“NMI”) dump switch that, when activated, causes the motherboard 22 to initiate a non-maskable interrupt dump to cause a Windows™ blue screen. In still other embodiments, the control switches 27 may include a unit identification switch (“UID”) that, when activated, causes the motherboard 22 to illuminate an LED or other externally mounted light source so that a user can visually identify the host computer 12 amongst a plurality of other computers. These examples are not intended to be exclusive.
As will be appreciated, the power switch 29 may allow a user to power-on or power-off the host computer 12. In one embodiment, the power switch 29 is a momentary contact switch. The momentary press of the power switch 29 is fed into the power switch state machine 28 that performs the desired power-button functionality and supplies the power supply with an on/off signal. As illustrated, the power switch state machine 28 is coupled to the motherboard and thus may be tied into operating system (“OS”) software running on the host computer 12. When the user presses the power switch 29 while the power switch 29 is under control of a power-management aware OS running on the host computer 12, a signal is generated to inform the OS of the user's desire for a power-down event. The OS then starts a graceful shutdown of the machine and when all data is quiesced, the OS itself turns off power through a register located in the power control logic. If the OS is degraded or otherwise in a state where a graceful shutdown is not possible, a user may also be able to “force” a power-down by pressing in the power switch 29 and holding it for a time period. The power switch state machine 28 may see this condition and de-asserts the “on” request to the power-supply.
Those of ordinary skill in the art will also appreciate that even when the host computer 12 is powered off, the host computer 12 may still draw some power. For example, the host computer 12 may continue to draw power for standby purposes, such as maintaining the host computer's internal clock or powering a remote management controller 32, as will be discussed further below.
The motherboard 22 may also be coupled to a video card 30. The video card 30 may be configured to receive video display data from the motherboard 22 and to transmit that video display data to a monitor (not shown) for display to a user. In one embodiment, the video card is configured to transmit a digital video data. For example, the video card 22 may be configured to produce a digital video output (“DVO”).
As illustrated, the motherboard 22 and/or the video card 30 may be coupled to the remote management controller (“RMC”) 32. In one embodiment, the RMC 32 may be an expansion or add-in card coupled to the digital video output of the video card 30 and coupled to the motherboard 22 via an expansion port, such as a PCI expansion port. In another embodiment, the RMC 32 may include a logic circuit, such as an ASIC, Field Programmable Gate Array (“FPGA”), and the like mounted on the motherboard 22, itself. In yet another embodiment, the RMC 32 may be a self-contained internal or external unit is coupled directly to one or more components of the host computer 12. The RMC 32 may be coupled to a network 14, such as an intranet or the Internet via a network interface 34. In one embodiment, the network interface 34 may be a dedicated network interface for the RMC 32. In an alternate embodiments (not shown), the RMC 32 and the motherboard 22 may share a single network interface.
In one embodiment, the RMC 32 (in combination with the network 14 and the remote computer 16) may form a remote management system for the host computer 12. Further, in one embodiment, the RMC 32 may be a part of an integrated lights out (“iLO”) system for managing servers that are located in temperature-controlled dark rooms, for example. Because technicians generally are not intended to enter these rooms, the RMC 32 in combination with the network 14 and the remote computer 16 may enable management and maintenance of these types of servers. As such, the RMC 32 and its related components may include auxiliary power sources, such as batteries (not shown) or may be configured to draw power from the host computer's 12 power source when the host computer 12 is turned off. In this way, the RMC 32 may enable the host computer 12 to be managed through the RMC 32 even when the host computer 12 is turned off.
As will be described in greater detail below, the RMC 32 may be configured to receive status data regarding the state of visual indicators associated with one or more the external devices 25, the indicator LEDs 26, and/or the power state of the host computer 12. The RMC 32 may also be configured to transmit this status data, referred to as hardware status data, to the remote computer 16 over the network 14. The RMC 32 may also be configured to store a graphical control panel that can be transmitted to the remote computer 16 to enable the remote computer 16 to display the hardware status data graphically. Further, the RMC 32 may be configured to receive commands or instructions from the remote computer 16 and to transmit these commands or instructions to the motherboard 22 or other suitable components of the host computer 12.
Returning now to
The RMC 32 may be communicatively coupled to the remote computer 16 via the network 14. As outlined above, the network 14 may be any form of computer network suitable to link the RMC 32 with the remote computer 16. For example, the network may be an Ethernet network, a Gigabit network, a wireless network, and so forth.
The remote computer 16 may include the network interface 36, a client computer 38, a display 40, and local storage resources 42, such as an optical drive, a hard disk drive, and/or a semiconductor memory. In one embodiment, the client computer 38 is configured to execute a graphical control panel program that produces virtualized controls that enable a user of the remote computer 16 to transmit commands to the host computer via the RMC 32. Further, the graphical control panel program may also enable the client computer 38 to display status data regarding the host computer 12 on the display 40, wherein the graphical control panel program and/or the status data is received from the RMC 32 over the network 14. In another embodiment, the remote computer 16 may also be configured to display video display data from the video card 30 on the display 40. In still another embodiment, the client computer 38 may be configured to logically couple or “mount” local storage resources 42, such as disk drives or image files to the host computer 12 via RMC 32, as described in further detail in regard to
As described above, embodiments of the present technique enable the creation of a graphical control panel on the remote computer 16. The graphical control program may enable the remote computer 16 to create a graphical user interface (“GUI”) that includes virtualized controls that enable a user of the remote computer 16 to transmit commands and/or instructions to the host computer 12 via the RMC 32. The GUI may also display video display data and/or hardware status data from the host computer 12. Specifically, in one embodiment, the graphical control panel may be configured to display graphically hardware status data associated with the host computer 12 that the RMC 32 transmits over the network 14. Accordingly,
As indicated by block 52, the technique 50 begins when the RMC 32 receives a request from the remote computer 16 to create a graphical control panel for the host computer 12. In one embodiment (not shown), the RMC 32 may prompt the remote computer for a password or other form of authentication to ensure that the remote computer 16 has permission to access the hardware status data of the host computer 12. After receiving the request from the remote computer 16 (and authenticating it, if appropriate), the RMC 32 may transmit a graphical control program to the remote computer via the network 14, as indicated in block 54. In various embodiments, the graphical control program may be an Active-X control, a Java applet, a .NET framework program, or other suitable form of software and/or instructions. It should be noted, however, that in alternate embodiments the graphical control program may also be preloaded on the remote computer 16.
Once the RMC 32 has transmitted the graphical control program to the remote computer 16 and once the remote computer has begun to execute the graphical control program, the RMC 32 may begin to transmit video display data from the video card 30 to the remote computer 16 via the network 14, as indicated in block 56. In one embodiment, the RMC 32 may compress the video display data to facilitate transmission over the network 14. Various compression techniques may be employed.
Either after the video display data is transmitted or while the video display data is begin transmitted, the RMC 32 may also transmit hardware status data to the remote computer 16, as also indicated in block 56. For example, the RMC 32 may transmit the power state of the host computer 12 (e.g., on, standby, or off), the status of one of the indicator LEDs 26 (i.e., illuminated or not illuminated), a status of one or more of the external devices 25, and/or a status of the local storage resources 42. As alluded to above, because the RMC 32 may have an independent power source, the RMC 32 is able to transmit both the video display data and the status data regardless of the state of the host computer 12. For example, if the host computer is in the off state, the RMC 32 may be configured to transmit to the remote computer 16 an indication that there is no current video display data and an indication that the power state of the host computer 12 is “off.”
As described above, the graphical control panel may also contain one or more virtualized controls. As such, the RMC 32 may also be configured to receive commands from the remote computer 16 and to transmit those commands to the host computer 12, as indicated by block 58. For example, the graphical control panel may include a virtualized power switch, that when activated (by a mouse click, for example) may cause the graphical control panel to transmit a power-related command to the RMC 32. In one embodiment, the virtualized power switch may be configured to perform a soft reset if the virtualized power switch is clicked on relatively briefly and to perform a hard reboot if the virtualized power switch is clicked on longer. As described in more detail below, the RMC 32 may also receive commands related to control switches 27 or commands involving the local storage resources 42. In one embodiment, the RMC 32 may use multiple ports (TCP/IP ports, for example) to simultaneously transmit and receive commands, display data, and status data.
Further, as illustrated in
As described above, the RMC 32 may be configured to transmit a graphical control program, video display data, and/or hardware status data to the remote computer 16.
Next, the remote computer 16 may receive the graphical control program from the RMC 32, as indicated by block 64. After the remote computer 16 has received the graphical control program, it may execute the graphical control program, as illustrated by block 66. At this point in the technique 60, the remote computer 16 may begin to receive the video display data of the host computer 12, as indicated by block 68. Once received, this video display data may be displayed on the display 40 of the remote computer 16. In one embodiment, the remote computer is configured to display the video display data from the host computer in a format matching the native display of the host computer. For example, if the native resolution of the video card 30 is 1024 by 768, the remote computer 16 may be configured to display the video display data at full screen with a resolution of 1024 by 768. In an alternate embodiment, the remote computer 16 may be configured to display the video display data in a subset of the display 40 or a different resolution than the host computer's 12 native resolution. Further, as illustrated in
The remote computer 16 may also be configured to receive and display hardware status data from the RMC 32, as indicated in blocks 72 and 74. In one embodiment, the hardware status data may include hardware status indictors that are typically externally visible on the host computer 12, such as the condition of the external indicator lights on the host computer 12, the power state of the host computer 12, and/or the status of storage devices coupled or mounted to the host computer 12. Further, as illustrated in
The remote computer 16 may also be configured to receive user commands from the user of the remote computer 16, as indicated by block 76. In one embodiment, the user command may come from a keyboard and/or mouse coupled to the remote computer 16. In another embodiment, the user requests may come from user interaction with the virtualized controls within the graphical control panel. For example, the user may click on a virtualized power control to issue a power-related command. The user may also click on a virtualized control to command one or more of the local storage resources to be communicatively coupled to the host computer 12. The user may also click on a virtualized control to initiate a non-maskable interrupt on the host computer 12 or to activate a unit identification (“UID”) light on the host computer 12. It will be appreciated that these examples of virtualized controls are merely exemplary and not intended to be exclusive. For example, in alternate embodiments, the virtualized controls may include any function suitable for one of the control switches 27. Once the host computer 16 has received the user request, it may transmit the request to the host computer 12 via the RMC 32, as indicated by block 78. Further, as illustrated in
As such, the remote computer 16 is configured transmit commands to the host computer 12 while the remote computer 16 is receiving hardware status data and video display data from the host computer 12 (blocks 68 and 72). For example, if the user “presses” a virtualized power switch control on a graphical control panel 80 (see
As described above, the remote computer 16 may be configured to execute the graphical control program to create a GUI that enables interaction with the host computer 12 via the RMC 32. In one embodiment, the remote computer 16 may generate a GUI containing a graphical control panel, such as the graphical control panel 80 illustrated in
The remote computer 16 may render the graphical control panel 80 over the video display data from the host computer 12 or may render the graphical control panel 80 along side the video display data. It will be appreciated that the one or more of the virtualized controls/representations 82, 84, or 86 may be designed to simulate the physical properties of actual components on the host computer 12. For example, the representation 82 of the power switch 29 may be configured to appear “pressed in” when the host computer 12 is powered on. Similarly, the representations 86 of the indicator LEDs 26 may appear illuminated when the actual indicator LEDs 26 are or would be illuminated.
As described above, the graphical control panel may be configured to include the virtualized control/representation 84 of storage devices coupled to or mounted to the host computer 12. The virtualized control/representation 84 may provide a selectable list of the local storage resources 42 that enables a user to couple one or more of the local storage resources 42 to the host computer 12. In one embodiment, the RMC 32 may be configured to mount one or more of the local storage resources 42 (e.g., hard disk drives, optical drives, or image files) as storage devices for the host computer 12 after receiving a mounting command from the remote computer 16.
Once the local storage resource 42 has been mounted, the RMC 32 may be configured to transmit the video display data from the host computer 96 to the remote computer 16, as indicated in block 96. In this way, a user of the remote computer 16 is able to see the effects of mounting the drive on host computer 12. For example, if a CD-ROM drive containing a executable program is mounted to the host computer 12, the user of the remote computer may be able to see the new drive being added into the host computer's 12 file system and may be able to see the host computer 12 execute or autorun the executable program stored on the CR-ROM. Moreover, the RMC 32 may also be configured to transmit the hardware status and/or indicator light status (e.g., a disk access light) of the mounted local storage resource 42 to the remote computer 16.
While the invention may be susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. However, it should be understood that the invention is not intended to be limited to the particular forms disclosed. Rather, the invention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the invention as defined by the following appended claims.
