Writing back virtual media images in HTML5
By creating a virtual disk image in read-write mode in the web browser of the user device, the problem that the HTML5 KVM/virtual media client cannot write back the file is solved, and two-way data transmission and data sharing from the host server to the user device is realized.
Patent Information
- Application Number
- CN202311098004.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2023-08-15
- Filing Date
- 2023-08-29
- Publication Date
- 2025-08-08
- Estimated Expiration
- 2043-08-29
AI Technical Summary
Existing HTML5 KVM/virtual media clients cannot write files from the host server back to the user device, resulting in critical log files and data files not being shared with the client computer.
By running the HTML5 KVM/Virtual Media Client in the web browser of the user device, creating a virtual disk image and mapping it into read-write mode, allowing files to be transferred from the host server to the user device through a persistent sandbox.
Two-way data transmission from the host server to the user equipment is realized. The user equipment can receive important log files and other data files, improving the ease of use of the user equipment and data sharing capabilities.
Smart Images

Figure CN117640657B_ABST
Abstract
Description
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS
[0002] This application claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Application No. 63 / 402,000, filed on August 29, 2022, the contents of which are incorporated herein by reference in their entirety. Technical Field
[0003] The present disclosure relates generally to virtual media protocols, and more particularly to systems and methods for creating a virtual disk image of selected data using a web browser on a user's computer. The virtual disk image is used by a remote host server during a virtual keyboard, video, and mouse (KVM) session. The virtual disk image can be modified by the host server, so that the modified disk image can be transferred from the host server to the user device. Background Art
[0004] Modern keyboard, video, and mouse (KVM) devices and baseboard management controllers (BMCs) allow users to access remote servers and other devices by passing keyboard, video, and mouse (KVM) signals between the user's device (typically a laptop, PC, tablet, smartphone, etc.) and the KVM device or BMC. For the purposes of this discussion, the following examples will only involve KVM devices, but it should be understood that they are equally applicable to communicating with a BMC. The keyboard and mouse signals received by the KVM device are typically received by a network protocol (e.g., Ethernet protocol packets) and then converted to a format that the remote device can receive (e.g., USB).
[0005] With the development of HTML5 technology, when a user establishes a KVM session, the HTML5 KVM / virtual media client can now run in the web browser of the user's device. Currently, HTML5 is supported by several browsers, including Apple's IOS AFAR. TM Web browser, Mozilla's FIREFOX TM Web browser, Google's CHROME TM Web browser, Amazon's Silk TM Browser, Microsoft's Internet Explorer TM (Versions 10 and 11) web browsers and Microsoft EDGE TM 、OPERA software development OPERA TM and OPERA MINI TMWeb browser. The ability to run the HTML5 KVM / Virtual Media Client in the user's web browser is a significant advantage, as users are generally very familiar with using web browsers. Thus, this implementation provides users with a comfortable, easy-to-use system for conducting KVM sessions with remote KVM devices (e.g., KVM appliances or BMCs).
[0006] However, running an HTML5 KVM / virtual media client in a user's web browser was initially limited by the web browser's inability to allow the KVM / virtual media client to access the physical disk of the client device (e.g., a PC workstation, laptop, computing tablet, smartphone, etc.) on which the web browser is running. This limitation does not apply to KVM / virtual media clients that do not run in the user's web browser. Previously used technologies (such as Java or ActiveX) allow access to physical media devices such as disk drives, thus eliminating the need for a disk image to access data files on the user's device. In contrast, web browsers provide a relatively small temporary storage area called a "sandbox." The JavaScript engine running in the web browser can bring files into the sandbox. However, the JavaScript engine still cannot write files out or directly access physical media devices on the user's device, such as the disk drive typically used for virtual media implementations. Furthermore, the temporary sandbox has a very small storage space of approximately 55MB, which significantly limits the creation of disk images.
[0007] Systems and methods that overcome these limitations are proposed in U.S. Patent No. 10,198,285, filed on February 5, 2019 by the assignee of the present application and entitled “System and method for creating a virtual disk image for a remote computer,” which is incorporated herein by reference in its entirety. TM Software web browser (such as Chrome TM and Microsoft Edge TM Web browsers) that have a temporary sandbox with a particularly high storage capacity and also allow files to be written directly to a persistent sandbox. The method includes mapping a storage device on a host server, creating a disk image of the storage device contents in the persistent sandbox of the web browser, and using the host server to obtain a virtual disk image of the contents from the persistent sandbox, ultimately resulting in data corresponding to the virtual disk image being transferred from the client computer to the host server. TMThe system and method disclosed in U.S. Patent No. 10,198,285 allows large (greater than 5MB) host data files, such as update files, to be transferred to a host server via an HTML5 KVM / virtual media client running in a web browser of a user device.
[0008] While the system and method disclosed in U.S. Patent No. 10,198,285 allows for the transfer of files from a client computer to a remote host server, the virtual media protocol only provides for one-way information transfer. Because the virtual image file appears as a read-only drive on the host server, the host server cannot write any files or data back to the client computer. This inability of the host server to write files back to the client computer prevents log files, data files, and other records generated by the host computer from being shared with the client computer or other client computers using the host server. Therefore, a system and method that addresses the shortcomings of the aforementioned conventional methods would be advantageous. Summary of the Invention
[0009] Thus, a system and method for transferring host data from a host server to a user device during a KVM session using an HTML5 KVM / virtual media client running in a web browser on the user device is disclosed. The system and method employed are related to a "virtual media" feature in a service processor for remotely managing a server (e.g., a host server). In this system and method, a client computer or user device runs a web browser that allows the user to select an image file (e.g., a block-by-block copy of a client storage device, such as a USB storage device, also known as a USB flash drive). The image file then appears as a new drive letter (e.g., a virtual drive) on the server system being managed. This organization allows files to be transferred from the user device to the host server. This system and method circumvents the problem of read-only virtual drives being unable to transfer files back to the user device's HTML client by modifying the original files received from the user device. These files are packaged and sent back to the user device via a persistent sandbox. In this way, the user device can receive important log files and other data files generated from the host server via a user-friendly web browser.
[0010] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not necessarily restrictive of the present disclosure. The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate the subject matter of the present disclosure. Figure 1 It is used to explain the principle of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] Those skilled in the art may better understand the numerous advantages of the present disclosure by referring to the accompanying drawings.
[0012] Figure 1 is a schematic diagram of a system in which a user device running a web browser is used to conduct a KVM session with a remote host server located in a data center, according to one or more embodiments of the present disclosure.
[0013] Figure 2A and 2B is a flow chart illustrating an operational sequence between an HTML5 KVM / virtual media client and a host server according to one or more embodiments of the present disclosure.
[0014] Figure 3A and 3B is a flowchart illustrating an operation sequence between an HTML5 KVM / virtual media client and a host server according to another embodiment of the present disclosure. DETAILED DESCRIPTION
[0015] Before describing in detail one or more embodiments of the present disclosure, it should be understood that the application of the embodiments is not limited to the construction and arrangement details of the components or steps or methods described in the following description or shown in the accompanying drawings. In the detailed description of the following embodiments, many specific details may be described in order to provide a more thorough understanding of the present disclosure. However, it will be apparent to those of ordinary skill in the art who benefit from the present disclosure that the embodiments disclosed herein can be implemented without these specific details. In other cases, well-known features may not be described in detail to avoid unnecessarily complicating the present disclosure.
[0016] As used herein, a letter following a reference number is intended to reference an embodiment of a feature or element that is similar, but not necessarily identical, to a previously described element or feature having the same reference number (e.g., 1, 1a, 1b). These shorthand notations are used for convenience only and should not be construed as limiting the disclosure in any way unless expressly stated to the contrary.
[0017] In addition, unless expressly stated to the contrary, "or" refers to an inclusive or and not an exclusive or. For example, condition A or B is satisfied by any of the following conditions: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), or both A and B are true (or exist).
[0018] In addition, "a" or "an" may be used to describe elements and components of the embodiments disclosed herein. This is done merely for convenience, and "a" or "an" are intended to include "one" or "at least one" and the singular also includes the plural unless it is obvious that it is meant otherwise.
[0019] Finally, as used herein, any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment disclosed herein. The appearances of the phrase "in an embodiment" in various places in the specification are not necessarily all referring to the same embodiment, and an embodiment may include one or more features expressly described or inherently present herein, or any combination or subcombination of two or more such features, as well as any other features not necessarily expressly described or inherently present in this disclosure.
[0020] refer to Figure 1 , shows a diagram of a system 10, wherein a user device, in this example, has a web browser (e.g., based on Chromium) running on it TM In the embodiment of the present invention, a workstation 12 (e.g., a workstation computer) using a web browser 14 is used to conduct a KVM session with a remote host server 16 located in a data center 17. A KVM device, in this example a KVM appliance 18, connects the user workstation 12 to the host server 16. However, it should be understood that a BMC can be implemented in place of a KVM appliance. For the purposes of this discussion, the KVM device will be referred to as a KVM appliance.
[0021] The web browser 14 can run an HTML5 KVM / virtual media client 20. The web browser 14 also provides a temporary sandbox 21 and a persistent sandbox 22, which are dedicated storage spaces in which the JavaScript engine running in the web browser 14 can manage files or portions of files. However, as described above, the JavaScript engine cannot write files to any physical devices (disk drives, flash drives) contained within or physically connected to the workstation 12, nor is it allowed to directly access these devices. It is contemplated that a single file browser can be included that can contain image files or portions of image files stored in the temporary sandbox 21 and the persistent sandbox 22 and can be visible to the user in a user interface.
[0022] The HTML5 KVM / virtual media client 20 communicates with the host server 16 via the KVM appliance 18, a virtual media connection device 24 within the KVM appliance 18, a USB port 26 of the host server 16, and a wide area network connection (e.g., the Internet). Messages, such as, but not limited to, AVMP (Avocent Virtual Messaging Protocol) messages, are transmitted between the HTML5 KVM / virtual media client 20 and the host server 16 when a virtual disk image is created on the workstation 12 and exposed to the host server 16, and when status updates (e.g., the number of bytes transferred) are sent from the HTML5 KVM / virtual media client to the host server 16. Virtual disk images of files and / or directories are created on the disk drive of the workstation 12 and exposed to the host server 16, allowing the host server 16 to access the contents of any disk on the workstation 12, as well as any virtual media devices (e.g., flash drives, portable storage devices, etc.) that may be physically connected to the workstation 12.
[0023] Now refer to Figure 2A and 2B , flow charts 100 and 140 illustrate a sequence of operations between the HTML5 KVM / virtual media client 20 and the host server 16. Initially, at operation 102 ( Figure 2A ), a user establishes a KVM session with host server 16 via HTML5 KVM / virtual media client 20 running in the user's web browser 14. At operation 104, KVM appliance 18 sends a list of virtual media devices available for mapping on host server 16 to HTML5 KVM / virtual media client 20. At operation 106, the user selects a host server device to be mapped and then selects specific content to be mapped via the virtual disk image. The content to be mapped can be a specific file, a directory, or a subdirectory.
[0024] At operation 107a, the HTML5 KVM / virtual media client 20 requests user permission to write the virtual disk image (e.g., in the form of packed bytes) to the web browser's persistent sandbox 22 or temporary sandbox 21. This request may be made at various times during the method. If the user does not approve the request, the method may terminate (e.g., end). If the user approves the request, the method proceeds to operation 107b, where the image is mapped as either a read-only (RO) or read-write (RW) image, depending on the client's approval. The request and approval sequence of 107a-b can take various forms. For example, the user may receive a permission dialog box requesting a decision on whether to map the image as RO or RW. In another example, the user may receive a permission dialog box asking the user to approve the browser writing the image to the persistent sandbox and / or writing the now-modified contents of the persistent sandbox copy of the bytes back to the image file on the workstation 12 file system, thereby allowing the user to access and manipulate the image file. In another example, the system may automatically decide whether to map the image as RO or RW (e.g., based on default criteria set by the user). If the decision is to map the image as RO, the image is copied to the temporary sandbox 21.
[0025] If the decision is made to map the image as RW, the flowchart continues to operation 108, where the HTML5 KVM / virtual media client 20 packages the selected content using the selected format (e.g., FAT32) to create a virtual disk image of the selected content in the browser's persistent sandbox 22. After the image is mapped as RW, all write block commands sent back from the host server 16 to the HTML5 KVM / virtual media client 20 will now change the data of the corresponding block in the web browser's 14 persistent sandbox.
[0026] At operation 110, the HTML5 KVM / virtual media client 20 sends a message to the host server 16, notifying the host server of the available virtual disk image and exposing the virtual disk image to the host server 16 for use. Regarding the messages that may be sent, it should be understood that any message protocol may be used, including but not limited to AVMP (Avocent Virtual Message Protocol) messages. The Avocent Virtual Message Protocol is a proprietary protocol of Avocent, Inc., a subsidiary of Vertiv, Inc.
[0027] At operation 112, the host server 16 obtains the virtual disk image and then sends a message (e.g., an AVMP message) back to the HTML5 KVM / virtual media client 20 with the starting block number and the number of data blocks to be retrieved. At operation 114, the HTML5 KVM / virtual media client 20 responds to the request by translating the request into the specific files that make up the virtual disk image and specific content from those files (e.g., the offsets into the files and the number of bytes to read from the persistent files in the persistent sandbox). It will also be understood that creating a virtual disk image involves creating structural elements of the disk image, such as the boot sector and the FAT table. Data from the disk image, typically stored in files within the disk image, is not part of the virtual disk image. Instead, the present system and method retains references to the files so that when a request for a particular data block (or set of data blocks) is received, a reverse lookup can be performed. The reverse lookup determines which files contain the requested data, and operations can then be performed to retrieve the data from the client workstation. The data is retrieved by copying the desired portions of the files into the persistent sandbox 22 and then transferring the data to the host server 16. The files that make up the disk image are not put into the persistent sandbox 22 until their data is needed, and then only those file parts that are needed are put into the persistent sandbox. Therefore, this method forms a kind of "on-demand" system.
[0028] At operation 116, the HTML5 KVM / virtual media client 20 sends the data represented by the selected bytes to the host server 16. At operation 118, the host server 16 receives the transmitted bytes. It will be appreciated that the bytes received by the host server 16 are from certain blocks on the virtual disk image. However, the host server 16 is unaware that the bytes are from the disk image. To the host server 16, it appears that the bytes are being retrieved from a physical device connected to its USB port 26.
[0029] In some embodiments, system 10 may perform operations to determine whether additional bytes are needed to complete the transfer of bytes. These operations are described in detail in U.S. Patent No. 10,198,285, entitled "System and Method for Creating a Virtual Disk Image for a Remote Computer," which is incorporated herein by reference in its entirety.
[0030] At operation 133, bytes are transferred from the host server 16 to the workstation 12. For example, the contents from the persistent sandbox (e.g., the RW image file) can be saved to the web browser (e.g., the download area) as a new image file that now contains the modified bytes of the host server 16. The sub-operations of operation 133 are detailed in Figure 2BAt operation 134, the KVM appliance 18 firmware receives the pop-up notification and sends a message (eg, an AVMP message) to the HTML5 KVM / virtual media client 20, which then unmaps the virtual disk image.
[0031] refer to Figure 2B , operation 133 of transferring bytes from the host server 16 to the workstation 12 is expanded and shown as operations 133a-f in flowchart 140. At operation 133a, the host server 16 adds or modifies the bytes received from the HTML5 KVM / virtual media client 20 (e.g., received in operation 118). The bytes added or modified by the host server 16 may include any type of data, including but not limited to log data or data records generated by the host server 16.
[0032] After adding and / or modifying the bytes, the KVM appliance 18 sends an instruction to the host server 16 requesting that the host server 16 send the bytes to the HTML5 KVM / virtual media client 20, as shown in operation 133b. The bytes may include the added and / or modified bytes as well as a portion of the original file sent from the HTML5 KVM / virtual media client 20 to the host server 16. In preparation for transmitting the added and / or modified bytes to the HTML5 KVM / virtual media client 20, the host server packages the bytes into an indicated format (e.g., a FAT-type file system such as FAT32) and sends the packaged bytes to the client, as shown in operation 133c.
[0033] At operation 133d, the received packed bytes are updated to the client's persistent memory. The host server then initiates the unmapping of the virtual disk by a user request (e.g., from operation 107a), as shown in operation 133e. In some embodiments, method 100 can utilize a user-triggered action to take a snapshot of the current persistent sandbox image content and store the content back to a file on the local disk while keeping the original mapped file still mapped. This embodiment may need to store the snapshot with a different file name because the still mapped image file cannot be overwritten. At operation 133f, the packed file is sent from the network browser's persistent sandbox 22 to the client storage device in the form of a disk image.
[0034] By using the HTML5 KVM / Virtual Media Client 20 to create a virtual disk image and expose it to the host server 16, the inability of a web browser to directly access the physical disk on the workstation 12 is at least partially overcome. However, because the persistent sandbox 22 does not allow the HTML5 KVM / Virtual Media Client 20 to read the boot sector of the physical device, the host server 16 loses the ability to boot from the physical disk on the client workstation. Essentially, the host server 16 can access any data content stored as a file on the workstation 12's disk, as well as any virtual media devices accessible to the workstation 12 through a physical connection to the workstation. The ability to run the HTML5 KVM / Virtual Media Client 20 in a web browser also significantly increases ease of use for users, as users are familiar with using web browsers.
[0035] Now refer to Figure 3A and 3B , flowcharts 300 and 340 illustrate an example of an operational sequence between the HTML5 KVM / virtual media client 20 and the host server 16, the decision making and byte transfer operations of flowcharts 300 and 340 are similar to Figure 2A and 2B 100, 140. In flowchart 300, operations 302 to 306 are the same as operations 102 to 106 in flowchart 100, respectively. At operation 307a, a decision is made (e.g., automatically or by a user) whether to map the image as a read-only (RO) or read-write (RW) image. If the decision is to map the image as read-only (RO), the image is written to the temporary sandbox 21. If the decision is to map the image as read-write (RW), the flowchart continues to operation 307b, where the HTML5 KVM / virtual media client 20 requests user permission to write the virtual disk image (e.g., in the form of packed bytes) to the web browser's persistent sandbox 22. If the user does not grant approval, the packed bytes are written to the temporary sandbox 21. If the user grants approval, the flowchart continues to the next operation 308.
[0036] Operations 308 through 318 of flowchart 300 may be the same as operations 108 through 118 of flowchart 100, respectively. Both operation 333 of flowchart 300 and operation 133 of flowchart 100 disclose transferring bytes from host server 16 to workstation 12. However, as shown in flowchart 340, these operations differ in how the transfer is performed. For example, after host server 16 adds or modifies bytes received from HTML5 KVM / virtual media client 20 in operation 333a, host server 16 packages these bytes into a specified format, as shown in operation 333b. Then, as shown in operation 333c, KVM appliance 18 sends a command to host server 16 requesting that host server 16 send bytes to HTML5 KVM / virtual media client 20.
[0037] In operation 333d, the HTML5 KVM / virtual media client 20 updates the received data into the web browser's persistent sandbox 22, wherein the host server 16 initiates the unmapping of the virtual disk in response to a user request in step 333e. As shown in operation 333f, the packaged file is then sent from the web browser's persistent sandbox 22 to the client storage device. Once the packaged file is sent from the persistent sandbox 22 to the client storage device, the method returns to operation 334 in flowchart 100, where the KVM device firmware receives the pop-up notification and sends a notification (e.g., via an AVMP message) to the KVM / virtual media client 20, which then unmaps the virtual disk.
[0038] As described in this article, based on Chromium TM The web browser, CHROME TM A web browser used to transfer host data from the host server 16 to the workstation 12. CHROME TM The web browser has a temporary sandbox 21, a persistent sandbox 22, an HTML5 KVM virtual media client 20, and can allow files to be written directly from the memory to the persistent sandbox 22. Based on Chromium TM web browsers offer certain advantages over other web browsers. In particular, Chromium-based TM The web browser's persistent sandbox uses free space from the user's hard drive, allowing for the transfer of larger image files.
[0039] It should be understood that as more web browsers 14 continue to be developed based on HTML5 protocols, many web browsers have or will have the ability to implement the methods described herein for CHROME TM The ability of web browsers to use Chromium-based TMThis is especially true for web browsers including but not limited to Amazon Silk TM , Avast Secure Browser, Beaker TM 、Blisk TM Brave TM 、CodeWeavers CrossOver TM 、Comodo Dragon TM 、 CrossOver TM 、Epic Browser TM 、Falkon TM 、quitebrowser TM , Microsoft Edge TM 、NaverWhale TM 、Opera TM , Qihoo 360 Safe Browser TM 、SatamWeb TM 、Samsung Internet TM 、Sleipnir TM 、Slimjet TM 、SRWare Iron TM 、Torch TM 、ungoogle-Chromium TM 、Vivaldi TM and Yandex Browser TM web browser. Therefore, the ones described in this article include Chrome TM The web browser systems and methods should not be construed as limited to the particular web browser 14 included in the disclosed systems and methods, but are merely illustrative.
[0040] According to flowcharts 100 and 300, system 10 may also perform operations to determine whether additional bytes are needed to complete the transfer of bytes. These operations are described in detail in U.S. Patent No. 10,198,285, entitled "System and Method for Creating a Virtual Disk Image for a Remote Computer," which is incorporated herein by reference in its entirety.
[0041] It is pointed out herein that the methods described in this disclosure are not limited to the operations and / or sub-operations provided. The methods herein may include more or fewer operations and / or sub-operations. One or more operations or sub-operations of the methods described in this disclosure may be performed simultaneously. One or more operations or sub-operations of the methods described in this disclosure may be formed in sequence, including in the sequence provided or in an order other than the sequence provided. Therefore, the above description should not be interpreted as limiting the scope of this disclosure, but merely as an illustration.
[0042] Those skilled in the art will recognize that the state of the art has advanced to the point where there is little distinction between hardware and software implementations of systems; the use of hardware or software is often (but not always; in some cases, the choice between hardware and software can be significant) a design choice that represents a cost-efficiency tradeoff. Those skilled in the art will understand that there are a variety of tools by which the processes and / or systems and / or other techniques described herein can be implemented (e.g., hardware, software, and / or firmware), and that the preferred tool will vary depending on the environment in which the processes and / or systems and / or other techniques are deployed. For example, if an implementer considers speed and accuracy to be paramount, the implementer may choose a tool that is primarily hardware and / or firmware; alternatively, if flexibility is paramount, the implementer may choose a primarily software implementation; or, alternatively, the implementer may choose some combination of hardware, software, and / or firmware. Thus, there are several possible tools by which the processes and / or devices and / or other techniques described herein can be implemented, with no one tool being inherently superior to another, as the choice of any tool will depend on the environment in which the tool will be deployed and the implementer's specific concerns (e.g., speed, flexibility, or predictability), any of which can vary. Those skilled in the art will recognize that the optical aspects of an implementation will typically use optically oriented hardware, software, and / or firmware.
[0043] The foregoing detailed description describes various embodiments of devices and / or processes using block diagrams, flow charts, and / or examples. As long as these block diagrams, flow charts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that each function and / or operation in these block diagrams, flow charts, or examples can be implemented individually and / or collectively by various hardware, software, firmware, or almost any combination thereof. In one embodiment, several portions of the subject matter described herein can be implemented by application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented in whole or in part in an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as almost any combination thereof, and that designing circuits and / or writing code for software and / or firmware, based on the present disclosure, will fall well within the skill of those skilled in the art. Furthermore, those skilled in the art will recognize that the mechanisms of the subject matter described herein can be distributed as a program product in a variety of forms, and that the illustrative embodiments of the subject matter described herein are applicable regardless of the particular type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to: recordable media (e.g., floppy disks, hard drives, CDs, digital video disks (DVDs), digital tapes, computer memories, etc.); and transmission-type media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).
[0044] In a general sense, those skilled in the art will recognize that the various aspects described herein, which may be implemented individually and / or collectively by various hardware, software, firmware, or any combination thereof, may be considered to be comprised of various types of "circuits." Thus, as used herein, "circuitry" includes, but is not limited to, circuitry having at least one discrete circuit, circuitry having at least one integrated circuit, circuitry having at least one application-specific integrated circuit, circuitry forming a general-purpose computing device configured by a computer program (e.g., a general-purpose computer configured by a computer program that at least partially performs the processes and / or devices described herein, or a microprocessor configured by a computer program that at least partially performs the processes and / or devices described herein), circuitry forming a storage device (e.g., in the form of random access memory), and / or circuitry forming a communication device (e.g., a modem, a communication switch, or an optoelectronic device). Those skilled in the art will recognize that the subject matter described herein may be implemented in analog or digital form, or some combination thereof.
[0045] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein and then use engineering practices to integrate the described devices and / or processes into a data processing system. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system typically includes one or more of the following: a system unit housing, a video display device, memory (such as volatile and non-volatile memory), a processor (such as a microprocessor and a digital signal processor), a computing entity (such as an operating system, a driver, a graphical user interface, and an application), one or more interactive devices (such as a touchpad or screen), and / or a control system including feedback loops and control motors (e.g., feedback loops for sensing position and / or velocity; control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.
[0046] The subject matter described herein sometimes illustrates different components that are contained in or connected to different other components. It should be understood that the architecture described in this way is merely exemplary, and in fact, many other architectures can achieve the same function. Conceptually, any arrangement of components that achieve the same function is effectively "associated" to achieve the desired function. Therefore, any two components that are combined here to achieve a specific function can be considered as "associated" to each other, so as to achieve the desired function, and have nothing to do with the architecture or intermediate components. Similarly, any two components that are so associated can also be considered as "operably connected" or "operably coupled" to achieve the desired function, and any two components that can be so associated can also be considered as "operably coupled" to achieve the desired function. The specific example of being operably coupled includes but is not limited to physically matchable and / or physically interactive components and / or wirelessly interactive and / or wirelessly interactive components and / or logically interactive and / or logically interactive components.
[0047] While particular aspects of the subject matter described herein have been shown and described, it will be apparent to those skilled in the art, based on the teachings herein, that changes and modifications may be made without departing from the subject matter described herein and its broader aspects, and it is intended that the appended claims include within their scope all such changes and modifications that fall within the true spirit and scope of the subject matter described herein. Furthermore, it will be understood that the invention is defined by the appended claims.
Claims
1. A system for creating a virtual disk image and exposing the virtual disk image to a host server and transferring host data from the host server to the user device during a KVM session using an HTML5 KVM / virtual media client running in a web browser of a user device, the web browser having a transient sandbox and a persistent sandbox, the system comprising: A user device running the web browser; HTML5 KVM / Virtual Media Client, running in the web browser, the system is configured to: packaging the selected content using a selected format to create a disk image of the selected content in the persistent sandbox; Notifying the host server that a virtual disk image is available, and publishing the virtual disk image in the persistent sandbox for use by the host server; responding to a request from the host server for data corresponding to a portion of the virtual disk image; performing a reverse lookup operation using the HTML5 KVM / virtual media client to convert the data request into at least a portion of at least one specific file constituting the virtual disk image; sending, using the HTML5 KVM / virtual media client, data bytes corresponding to at least a portion of the at least one specific file to the host server; modifying the data bytes received from the HTML5 KVM / virtual media client using host data to produce modified bytes; Sending instructions to the host server using the HTML5 KVM / virtual media client, wherein the instructions include sending the modified bytes to the HTML5 KVM / virtual media client; sending the modified bytes to the HTML5 KVM / virtual media client using the host server; packing the modified bytes into the indicated format to generate packed bytes; Initiating unmapping of the virtual disk; Sending the packed bytes to the persistent sandbox; selecting a client storage device to receive the packed bytes; and The packed bytes are sent from the persistent sandbox to the client storage device.
2. The system according to claim 1, wherein: The modified bytes comprise at least a portion of the image file.
3. The system according to claim 1, wherein: The modified bytes include log data or data records generated by the host server.
4. The system according to claim 1, wherein: The format of the indication is a FAT type file system, and the FAT type file system is FAT32.
5. The system according to claim 1, wherein: The client storage device is a USB storage device.
6. The system according to claim 1, wherein: The web browser includes CHROME TM A web browser.
7. A method for transferring host data from a host server to a user device during a KVM session using an HTML5 KVM / virtual media client running in a web browser of a user device, the web browser having a transient sandbox and a persistent sandbox, the method comprising: modifying original data received from the HTML5 KVM / virtual media client running in the web browser of the user device using host data to produce modified bytes, wherein The web browser includes the temporary sandbox and the persistent sandbox, wherein the modified bytes are stored as a disk image on a virtual disk; Sending instructions to the host server using the HTML5 KVM / virtual media client, wherein the instructions include sending the modified bytes to the HTML5 KVM / virtual media client; packing the modified bytes into the indicated format to generate packed bytes; Initiating unmapping of the virtual disk; Sending the packed bytes to the persistent sandbox; selecting a client storage device to receive the packaged bytes; The packed bytes are sent from the persistent sandbox to the client storage device.
8. The method according to claim 7, wherein: The modified bytes comprise at least a portion of the image file.
9. The method according to claim 7, wherein: The modified bytes include log data or data records generated by the host server.
10. The method according to claim 7, wherein: The format of the indication is a FAT type file system, and the FAT type file system is FAT32.
11. The method according to claim 7, wherein: The client storage device is a USB storage device.
12. The method according to claim 7, wherein: The web browser includes CHROME TM A web browser.
13. A method for creating a virtual disk image and exposing the virtual disk image to a host server and transferring host data from the host server to the user device during a KVM session using an HTML5 KVM / virtual media client running in a web browser of a user device, the web browser having a transient sandbox and a persistent sandbox, the method comprising: sending, to the host server, a selection of a particular virtual media device to be mapped to the host server; using the HTML5 KVM / virtual media client running in the web browser of the user device to package selected content into a selected format, wherein The network browser includes the temporary sandbox and the persistent sandbox; writing the selected format to the persistent sandbox; Creating a virtual disk image of the selected content in the persistent sandbox; Notifying the host server that the virtual disk image is available; exposing the virtual disk image in the persistent sandbox for use by the host server; Obtaining the virtual disk image from the persistent sandbox using the host server; sending, using the host server, a request to the HTML5 KVM / virtual media client to retrieve a portion of the data of the virtual disk image; converting the request into at least one specific file constituting the virtual disk image using the HTML5 KVM / virtual media client, and sending data bytes corresponding to the at least one specific file to the host server; receiving, using the host server, the data bytes corresponding to the at least one specific file; modifying the data bytes received from the HTML5 KVM / virtual media client using host data to produce modified bytes; Sending instructions to the host server using the HTML5 KVM / virtual media client, wherein the instructions include sending the modified bytes to the HTML5 KVM / virtual media client; packing the modified bytes into the indicated format to generate packed bytes; Initiating unmapping of the virtual disk; Sending the packed bytes to the persistent sandbox; selecting a client storage device to receive the packed bytes; and The packed bytes are sent from the persistent sandbox to the client storage device.
14. The method according to claim 13, wherein: The modified bytes comprise at least a portion of the image file.
15. The method according to claim 13, wherein The modified bytes include log data or data records generated by the host server.
16. The method according to claim 13, wherein The format of the indication is a FAT type file system, and the FAT type file system is FAT32.
17. The method according to claim 13, wherein: The client storage device is a USB storage device.
18. The method according to claim 13, wherein The web browser includes CHROME TM A web browser.
Citation Information
Patent Citations
System and method for creating virtual disk images for use with remote computer
US10198285B2
System and method for creating virtual disk images for use with remote computer
CN104685488A
System and method for creating virtual disk images for use with remote computer
CN109656677A