CN109977093A - More virtual systems based on LXC check the method and device of container log - Google Patents
More virtual systems based on LXC check the method and device of container log Download PDFInfo
- Publication number
- CN109977093A CN109977093A CN201910273364.XA CN201910273364A CN109977093A CN 109977093 A CN109977093 A CN 109977093A CN 201910273364 A CN201910273364 A CN 201910273364A CN 109977093 A CN109977093 A CN 109977093A
- Authority
- CN
- China
- Prior art keywords
- container
- domain
- lxc
- log
- ram
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 43
- 238000012544 monitoring process Methods 0.000 claims abstract description 14
- 238000004806 packaging method and process Methods 0.000 claims description 9
- 238000012545 processing Methods 0.000 abstract description 4
- 238000004590 computer program Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 3
- 238000002955 isolation Methods 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Landscapes
- Debugging And Monitoring (AREA)
Abstract
The embodiment of the invention discloses a kind of, and more virtual systems based on LXC check the method, apparatus and electronic equipment of container log, are related to technical field of data processing.This method comprises: applying for ram space in the container domain of linux kernel, and the ram space is packaged into memory device；The file system based on RAM is created in the container domain, it will be described file system mounted to specific mount point catalogue；The parameter that LOGD is arranged in the container domain makes it be re-introduced into the specific mount point catalogue；The container management service in trusted domain generated using linux kernel, the operation of trusted domain is notified to monitor service routine, the monitoring service routine is by starting default routine, memory device described in carry obtains container log to a specific mount point directory node in the trusted domain from the specific mount point directory node.By the scheme of the application, the efficiency that log is checked is improved.
Description
Technical Field
The invention relates to the technical field of data processing, in particular to a technology for checking container logs by a multi-virtual system based on LXC.
Background
In the field of Android system virtualization, there are several mainstream virtualization schemes. (1) The data isolation is the most thorough based on the hardware level virtualization of the Hypervisor model, but the hardware level virtualization is heavier for an Android embedded system and is not superior in indexes such as power consumption and performance. (2) An implementation scheme based on an Android multi-user mechanism belongs to user-level virtualization, and the user data isolation degree is low, so that the method can only meet the scene requirement of low security level. (3) In the Android multi-system embedded field with higher security level requirements, an LXC container implementation scheme with a moderate volume is often adopted, belongs to virtualization of an operating system level, realizes a multi-container system sharing a kernel, and realizes balance in system performance and security.
In order to obtain the container log, one solution in the prior art is to enter a "trusted domain" first, and then enter a container system view using an LXC command in the "trusted domain" to view the log using a log terminal tool. The disadvantages of this solution are: for a user, the operation is complex, the user needs to enter two areas, log information of different container systems can not be obtained in the same terminal, and the user is inconvenient to dump the log information in an upper computer. In another scheme, the Android user partition transfer log is utilized on the premise of closing the Android full disk encryption characteristic. The disadvantages of this solution are: the Data subarea cannot be encrypted, and the Data which is decrypted and received by the Data is difficult to obtain by the security domain after encryption; due to frequent IO operations, the overall system performance may be significantly reduced.
In view of the foregoing problems, a new technology for viewing container logs by using an LXC-based multi-virtual system is needed.
Disclosure of Invention
In view of the above, embodiments of the present invention provide a method, an apparatus, an electronic device, a non-transitory computer-readable storage medium, and a computer program for viewing a container log in a LXC-based multi-virtual system, which at least partially solve the problems in the prior art.
In a first aspect, an embodiment of the present invention provides a method for viewing a container log in a LXC-based multi-virtual system, including:
applying for RAM space in a container domain of a Linux kernel, and packaging the RAM space into memory equipment;
creating a file system based on RAM in the container domain, and mounting the file system to a specific mounting point directory;
setting parameters of the LOGD within the container domain to redirect to the particular mounting point directory;
and informing the trusted domain to operate a monitoring service routine by utilizing a container management service in the trusted domain generated by a Linux kernel, wherein the monitoring service routine starts a preset routine to mount the memory device to a specific mounting point directory node in the trusted domain, and acquiring a container log from the specific mounting point directory node.
According to a specific implementation manner of the embodiment of the present invention, the RAM space applied in the container domain of the Linux kernel includes:
appointing the memory quantity to be applied and the application identification which are calculated according to bytes;
sending the content quantity and the application identifier to the Linux kernel;
and determining the position and the size of the RAM space based on the return result of the Linux kernel.
According to a specific implementation manner of the embodiment of the present invention, the encapsulating the RAM space into the memory device includes:
applying for a general disk for the RAM space by utilizing a first API (application program interface);
initializing the general disk and setting the queue attribute of the pass disk;
and registering the universal disk in the Linux system through a second API interface.
According to a specific implementation manner of the embodiment of the present invention, the creating of the RAM-based file system in the container domain includes:
and when the Linux system is initialized, establishing the file system in the RAM space by using a preset command.
According to a specific implementation manner of the embodiment of the present invention, the mounting the RAM file system to a specific mounting point directory includes:
and when the system is initialized, mounting the RAM equipment to a specific mounting point directory.
According to a specific implementation manner of the embodiment of the present invention, the setting of the parameters of the LOGD in the container domain to redirect to the specific mounting point directory includes:
and acquiring a file path of the specific mounting point directory, and setting the file path in the LOGD parameter to be the same as the file path of the specific mounting point directory.
According to a specific implementation manner of the embodiment of the present invention, the acquiring a container log from the specific mount point directory node includes:
and starting an application program in the trusted domain, and acquiring the log file information of the container domain from the specific directory node through the application program.
According to a specific implementation manner of the embodiment of the present invention, the acquiring a container log from the specific mount point directory node further includes:
messages are sent to the LXC container domain by a container management service program, by which the enabling and disabling of LOGD to RAM space outputs in the container domain is controlled.
In a second aspect, an embodiment of the present invention further provides an apparatus for viewing a container log in a LXC-based multi-virtual system, where the apparatus includes:
the packaging module is used for applying for RAM space in a container domain of a Linux kernel and packaging the RAM space into memory equipment;
the mounting module is used for creating a file system based on the RAM in the container domain and mounting the file system to a specific mounting point directory;
an orientation module to set parameters of the LOGD to be redirected to the particular mounting point directory within the container domain;
and the execution module is used for notifying the trusted domain to run a monitoring service routine by utilizing a container management service in the trusted domain generated by a Linux kernel, wherein the monitoring service routine is used for mounting the memory device to a specific mounting point directory node in the trusted domain by starting a preset routine, and acquiring a container log from the specific mounting point directory node.
In a third aspect, an embodiment of the present invention further provides an electronic device, where the electronic device includes:
at least one processor; and the number of the first and second groups,
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method for viewing a container log for an LXC-based multi-virtual system according to any one of the preceding aspects or any implementation manner of the first aspect.
In a fourth aspect, an embodiment of the present invention further provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the method for viewing a container log in an LXC-based multi-virtual system according to the first aspect or any implementation manner of the first aspect.
In a fifth aspect, an embodiment of the present invention further provides a computer program product, where the computer program product includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions, when executed by a computer, cause the computer to execute the method for viewing a container log based on an LXC multiple virtual system according to the foregoing first aspect or any implementation manner of the first aspect.
The method, the device, the electronic equipment, the non-transitory computer readable storage medium and the computer program for checking the container log of the multi-virtual system based on the LXC comprise the steps of applying for a RAM space in a container domain of a Linux kernel, and packaging the RAM space into a memory device; creating a file system based on RAM in the container domain, and mounting the file system to a specific mounting point directory; setting parameters of the LOGD within the container domain to redirect to the particular mounting point directory; and informing the trusted domain to operate a monitoring service routine by utilizing a container management service in the trusted domain generated by a Linux kernel, wherein the monitoring service routine starts a preset routine to mount the memory device to a specific mounting point directory node in the trusted domain, and acquiring a container log from the specific mounting point directory node. According to the scheme, the full-disk encryption function of the Android system is not influenced; only the memory is accessed, so that the I/O operation which obviously influences the performance is avoided; the switch of the container system can be dynamically controlled, and unnecessary performance loss is avoided; by utilizing the file redirection function of the LOGD, the scheme is modularized, decoupling is facilitated, and the implementation is simple.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1 is a schematic flowchart illustrating a process of viewing a container log by a LXC-based multi-virtual system according to an embodiment of the present invention;
fig. 2 is a schematic product structure diagram of a LXC-based multi-virtual system viewing container log according to an embodiment of the present invention;
FIG. 3 is a schematic diagram of a product structure of another LXC-based multi-virtual system viewing container log according to an embodiment of the present invention;
fig. 4 is a schematic structural diagram of an apparatus for viewing a container log in a LXC-based multi-virtual system according to an embodiment of the present invention;
fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.
Detailed Description
Embodiments of the present invention will be described in detail below with reference to the accompanying drawings.
It should be understood that the described embodiments are only some embodiments of the invention, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The LXC, an abbreviation of Linux condontainer, is a user space toolset using a "namespace" and a "group control" mechanism provided by a Linux kernel, and is currently maintained and evolved by an open source community, and is a lightweight virtualization technology. The multi-Android container system is derived based on the LXC, namely the system enters a user space (called a 'trusted domain') at the moment after the kernel initialization is completed, a plurality of containers are built on the same Linux kernel by utilizing the LXC characteristics, and then an independent Android system (called the 'container domain') is started in the containers. All processes in a single container are in the container view, namely, the process is considered to monopolize a kernel without sensing the existence of processes in other containers, so that the debugging of the system in the container under the framework cannot be as easy as that in a common system.
Firstly, a Linux kernel needs to provide characteristic support of a 'name space' and a 'control group' for the LXC, after the Linux kernel is started, the LXC is started in a user space, a context at this time is called a 'trusted domain', two or more container systems are created in the 'trusted domain' by using the LXC, and a Container Management Service (CMS) in the 'trusted domain' is used as a hub for starting, monitoring and switching the dual container system, as shown in fig. 2
The LOGD is a basic log daemon process in an Android system, can be regarded as a server, provides log service for a log client program (such as logcat), and can redirect log information to a file system by configuring parameters of the LOGD. In the architecture of the LXC-based multi-Android system, LOGD in a container cannot be directly used by a server of a "trusted domain".
The basic scheme of the application is as follows: based on the characteristic that a trusted domain and a container domain share a kernel space, a RAM area is reserved in a kernel and packaged into a special device, and a file system is established on the device to expose a file system interface to the outside; then, in the starting stage of the system of the container domain, the file system based on the RAM equipment is mounted on a specific directory node in the container domain, and then log information provided by the LOGD service is redirected to the directory node; the above steps implement the writing of the container log. And meanwhile, mounting in the trusted domain according to similar steps, and reading the content of the transit file in the container domain, thereby obtaining the log information in the container domain system.
Referring to fig. 1 to fig. 3, an embodiment of the present invention provides a method for viewing a container log by a LXC-based multi-virtual system, including the following steps:
s101, applying for RAM space in a container domain of a Linux kernel, and packaging the RAM space into memory equipment.
The hardware system of Linux can be an electronic device with RAM, such as a computer and a mobile phone, and the electronic device can be installed with an operating system (e.g., an Android system) based on a Linux kernel. After the Linux kernel is started, the LXC is started in the user space, and the context of this time is a "trusted domain", and a plurality of container domains (container systems) are created in this "trusted domain" by using the LXC, where the container domains may be various virtual operating systems capable of running on the LXC. Through these container fields, RAM space can be applied for.
In order to ensure independence of the applied RAM space and facilitate identification, the RAM space may be packaged into a memory device. The Linux kernel and the virtual operating system installed in the container domain can access data through the memory device.
S102, creating a file system based on RAM in the container domain, and mounting the file system to a specific mounting point directory.
After the RAM space is encapsulated into a memory device, a file system may be created based on the memory device, for example, a TEMPFS system may be created on the memory device, and a RAM-based file system (e.g., TEMPFS) may be used and may be implemented by using a specific command during a system initialization stage.
In the initialization phase of the system, the RAM memory device is mounted to a specific directory node in a container domain, so that the redirection of the log file by a user layer is facilitated.
S103, setting parameters of LOGD in the container domain to redirect to the specific mounting point directory.
The LOGD is used for saving logs during Android operation, and the logs are saved in a user space. Specifically, the Android layer prints a Log (Log) by calling a v/d method in the Log/Slog/Rlog, and finally the Log is transmitted to the Log through a netlink and stored in the memory by the Log.
In the log saving process of the log, the log needs to be set with target parameters for a saving target object, and at this time, the memory device may be used as a new target parameter, and the space where the target device is located may be used as a specific mounting point directory.
S104, notifying the trusted domain to operate a monitoring service routine by utilizing a container management service in the trusted domain generated by a Linux kernel, wherein the monitoring service routine starts a preset routine to mount the memory device to a specific mounting point directory node in the trusted domain, and acquiring a container log from the specific mounting point directory node.
After steps S101 to S103 are completed in the "container domain", the CMS hub is used to notify the "trusted domain" to run a snooping service routine, which may start a similar process to mount the memory device to a directory node of the "trusted domain" to further obtain a container log in the directory node.
The RAM space may be applied in a variety of ways, and according to a specific implementation manner of an embodiment of the present invention, the RAM space applied in the container domain of the Linux kernel includes: appointing the memory quantity to be applied and the application identification which are calculated according to bytes; sending the content quantity and the application identifier to the Linux kernel; and determining the position and the size of the RAM space based on the return result of the Linux kernel.
In a process of encapsulating a memory space into a memory device, according to a specific implementation manner of an embodiment of the present invention, encapsulating the RAM space into the memory device includes: applying for a generic disk for the RAM space using a first API interface (e.g., a disk application API); initializing the general disk and setting a queue attribute of the pass disk, wherein the queue attribute provides real read-write capability for the general disk; the general disk is registered in the Linux system through a second API interface (for example, a disk addition API), after the general disk is registered in the system, a corresponding disk identifier is allocated, and a corresponding operation can be executed on the disk through the disk identifier.
According to a specific implementation manner of the embodiment of the present invention, the creating of the RAM-based file system in the container domain includes: and when the Linux system is initialized, establishing the file system in the RAM space by using a preset command.
According to a specific implementation manner of the embodiment of the present invention, the mounting the RAM file system to a specific mounting point directory includes: and when the system is initialized, mounting the RAM equipment to a specific mounting point directory.
According to a specific implementation manner of the embodiment of the present invention, the setting of the parameters of the LOGD in the container domain to redirect to the specific mounting point directory includes: and acquiring a file path of the specific mounting point directory, and setting the file path in the LOGD parameter to be the same as the file path of the specific mounting point directory.
According to a specific implementation manner of the embodiment of the present invention, the acquiring a container log from the specific mount point directory node includes: and starting an application program in the trusted domain, and acquiring the log file information of the container domain from the specific directory node through the application program.
Referring to fig. 3, according to a specific implementation manner of the embodiment of the present invention, the acquiring a container log from the specific mount point directory node further includes: and sending a message to the LXC container domain through a container management service program, and controlling enabling and closing of output of the LOGD to the RAM space in the container domain by setting an enabling switch in a file system node through the container management service.
Corresponding to the above method embodiment, referring to fig. 4, the present application further discloses an apparatus 40 for viewing a container log in an LXC-based multi-virtual system, including:
the packaging module 401 is configured to apply for a RAM space in a container domain of a Linux kernel, and package the RAM space into a memory device;
a mount module 402, configured to create a RAM-based file system in the container domain, and mount the file system to a specific mount point directory;
an orientation module 403 for setting parameters of the LOGD within the container domain to redirect to the specific mounting point directory;
an execution module 404, configured to notify the trusted domain to run a listening service routine by using a container management service in the trusted domain generated by a Linux kernel, where the listening service routine is configured to mount the memory device to a specific mount point directory node in the trusted domain by starting a preset routine, and obtain a container log from the specific mount point directory node.
In the above embodiments, the functions and contents executed by the functional modules correspond to the corresponding method embodiments one to one, and are not described herein again.
Fig. 5 shows a schematic structural diagram of the electronic device 50 according to an embodiment of the present invention, where the electronic device 5 includes at least one processor 501 (e.g., a CPU), at least one input/output interface 504, a memory 502, and at least one communication bus 503, which are used to implement connection communication between these components. The at least one processor 501 is arranged to execute executable modules, such as computer programs, stored in the memory 502. The Memory 502 is a non-transitory Memory (non-transitory Memory), which may include a volatile Memory such as a high-speed Random Access Memory (RAM) or a non-volatile Memory such as at least one disk Memory. The communication connection with at least one other network element is realized through at least one input/output interface 504 (which may be a wired or wireless communication interface).
In some embodiments, the memory 502 stores a program 5021, and the processor 501 executes the program 5021 to perform any one of the embodiments of the method for an electronic device based LXC based multi-virtual system to view container logs described above.
The electronic device may exist in a variety of forms, including but not limited to:
(1) a mobile communication device: such devices are characterized by mobile communications capabilities and are primarily targeted at providing voice, data communications. Such terminals include: smart phones (e.g., iphones), multimedia phones, functional phones, and low-end phones, among others.
(2) Ultra mobile personal computer device: the equipment belongs to the category of personal computers, has calculation and processing functions and generally has the characteristic of mobile internet access. Such terminals include: PDA, MID, and UMPC devices, etc., such as ipads.
(3) A portable entertainment device: such devices can display and play multimedia content. This type of device comprises: audio, video players (e.g., ipods), handheld game consoles, electronic books, and smart toys and portable car navigation devices.
(4) The specific server: the device for providing the computing service comprises a processor, a hard disk, a memory, a system bus and the like, and the server is similar to a general computer architecture, but has higher requirements on processing capacity, stability, reliability, safety, expandability, manageability and the like because of the need of providing high-reliability service.
(5) And other electronic equipment with data interaction function.
It should be noted that, in this document, relational terms such as first and second, and the like are used only for description
One entity or operation is distinct from another entity or operation without necessarily requiring or implying such.
There may be any such actual relationship or order between the entities or operations. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments.
In particular, as for the apparatus embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The logic and/or steps represented in the flowcharts or otherwise described herein, e.g., an ordered listing of executable instructions that can be considered to implement logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic device) having one or more wires, a portable computer diskette (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
It should be understood that portions of the present invention may be implemented in hardware, software, firmware, or a combination thereof.
In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.
The above description is only for the specific embodiment of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present invention are included in the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.
Claims (10)
1. A method for viewing a container log by a multi-virtual system based on an LXC (local area network controller), which is characterized by comprising the following steps:
applying for RAM space in a container domain of a Linux kernel, and packaging the RAM space into memory equipment;
creating a file system based on RAM in the container domain, and mounting the file system to a specific mounting point directory;
setting parameters of the LOGD within the container domain to redirect to the particular mounting point directory;
and informing the trusted domain to operate a monitoring service routine by utilizing a container management service in the trusted domain generated by a Linux kernel, wherein the monitoring service routine starts a preset routine to mount the memory device to a specific mounting point directory node in the trusted domain, and acquiring a container log from the specific mounting point directory node.
2. The method for viewing container logs in the LXC-based multi-virtual system according to claim 1, wherein the applying for the RAM space in the container domain of Linux kernel comprises:
appointing the memory quantity to be applied and the application identification which are calculated according to bytes;
sending the content quantity and the application identifier to the Linux kernel;
and determining the position and the size of the RAM space based on the return result of the Linux kernel.
3. The method for viewing container logs by a LXC-based multi-virtual system according to claim 1, wherein said encapsulating said RAM space into a memory device comprises:
applying for a general disk for the RAM space by utilizing a first API (application program interface);
initializing the general disk and setting the queue attribute of the pass disk;
and registering the universal disk in the Linux system through a second API interface.
4. The method for viewing a container log by a LXC-based multi-virtual system according to claim 1, wherein said creating a RAM-based file system in said container domain comprises:
and when the Linux system is initialized, establishing the file system in the RAM space by using a preset command.
5. The method for viewing a container log by a LXC-based multi-virtual system according to claim 1, wherein said mounting said RAM file system to a specific mount point directory comprises:
and when the system is initialized, mounting the RAM equipment to a specific mounting point directory.
6. The method for LXC-based multi-virtual system to view container logs of claim 1, wherein said setting the parameters of LOGD within said container domain to redirect to said specific mounting point directory comprises:
and acquiring a file path of the specific mounting point directory, and setting the file path in the LOGD parameter to be the same as the file path of the specific mounting point directory.
7. The method for viewing a container log in a LXC-based multi-virtual system according to claim 1, wherein said obtaining a container log from said specific mount point directory node comprises:
and starting an application program in the trusted domain, and acquiring the log file information of the container domain from the specific directory node through the application program.
8. The method for a LXC-based multi-virtual system to view a container log according to claim 7, wherein said obtaining a container log from said specific mount point directory node further comprises:
messages are sent to the LXC container domain by a container management service program, by which the enabling and disabling of LOGD to RAM space outputs in the container domain is controlled.
9. An apparatus for viewing container logs in a LXC-based multi-virtual system, comprising:
the packaging module is used for applying for RAM space in a container domain of a Linux kernel and packaging the RAM space into memory equipment;
the mounting module is used for creating a file system based on the RAM in the container domain and mounting the file system to a specific mounting point directory;
an orientation module to set parameters of the LOGD to be redirected to the particular mounting point directory within the container domain;
and the execution module is used for notifying the trusted domain to run a monitoring service routine by utilizing a container management service in the trusted domain generated by a Linux kernel, wherein the monitoring service routine is used for mounting the memory device to a specific mounting point directory node in the trusted domain by starting a preset routine, and acquiring a container log from the specific mounting point directory node.
10. An electronic device, characterized in that the electronic device comprises:
at least one processor; and the number of the first and second groups,
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method for LXC based multi-virtual system viewing container logs of any of the preceding claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910273364.XA CN109977093A (en) | 2019-04-04 | 2019-04-04 | More virtual systems based on LXC check the method and device of container log |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910273364.XA CN109977093A (en) | 2019-04-04 | 2019-04-04 | More virtual systems based on LXC check the method and device of container log |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN109977093A true CN109977093A (en) | 2019-07-05 |
Family
ID=67083252
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910273364.XA Pending CN109977093A (en) | 2019-04-04 | 2019-04-04 | More virtual systems based on LXC check the method and device of container log |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109977093A (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110673974A (en) * | 2019-08-20 | 2020-01-10 | 中科创达软件股份有限公司 | System debugging method and device |
| CN111176787A (en) * | 2019-12-23 | 2020-05-19 | 中国建设银行股份有限公司 | Data analysis method and device |
| CN112905537A (en) * | 2021-02-20 | 2021-06-04 | 北京百度网讯科技有限公司 | File processing method and device, electronic equipment and storage medium |
| CN114168203A (en) * | 2020-09-10 | 2022-03-11 | 成都鼎桥通信技术有限公司 | Dual-system running state control method and device and electronic equipment |
| WO2023273482A1 (en) * | 2021-06-29 | 2023-01-05 | 华为技术有限公司 | Control method and electronic device |
| WO2023093127A1 (en) * | 2021-11-26 | 2023-06-01 | 北京百度网讯科技有限公司 | Method and apparatus for monitoring a cluster, and electronic device |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1744040A (en) * | 2005-09-27 | 2006-03-08 | 胡元志 | Method for completely running operating system in multi storage media and its operating system |
| US20090320009A1 (en) * | 2008-06-20 | 2009-12-24 | Vmware, Inc. | Decoupling dynamic program analysis from execution in virtual environments |
| CN103049546A (en) * | 2012-12-27 | 2013-04-17 | 华为技术有限公司 | Method and device for managing and accessing system logs |
| US8806115B1 (en) * | 2014-01-09 | 2014-08-12 | Netapp, Inc. | NVRAM data organization using self-describing entities for predictable recovery after power-loss |
| CN105653906A (en) * | 2015-12-28 | 2016-06-08 | 中国人民解放军信息工程大学 | Anti-kernel-hook method based on address randomization |
| CN105893205A (en) * | 2015-11-20 | 2016-08-24 | 乐视云计算有限公司 | Method and system for monitoring containers created based on docker |
| CN108052328A (en) * | 2017-11-09 | 2018-05-18 | 华中科技大学 | A kind of construction method of Android system and its application |
| CN108845917A (en) * | 2018-04-09 | 2018-11-20 | 东峡大通（北京）管理咨询有限公司 | File journalization carry module, system and method in container |
| CN108897617A (en) * | 2018-06-19 | 2018-11-27 | 北京元心科技有限公司 | The method, apparatus and terminal device of memory management |
-
2019
- 2019-04-04 CN CN201910273364.XA patent/CN109977093A/en active Pending
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1744040A (en) * | 2005-09-27 | 2006-03-08 | 胡元志 | Method for completely running operating system in multi storage media and its operating system |
| US20090320009A1 (en) * | 2008-06-20 | 2009-12-24 | Vmware, Inc. | Decoupling dynamic program analysis from execution in virtual environments |
| CN103049546A (en) * | 2012-12-27 | 2013-04-17 | 华为技术有限公司 | Method and device for managing and accessing system logs |
| US8806115B1 (en) * | 2014-01-09 | 2014-08-12 | Netapp, Inc. | NVRAM data organization using self-describing entities for predictable recovery after power-loss |
| CN105893205A (en) * | 2015-11-20 | 2016-08-24 | 乐视云计算有限公司 | Method and system for monitoring containers created based on docker |
| CN105653906A (en) * | 2015-12-28 | 2016-06-08 | 中国人民解放军信息工程大学 | Anti-kernel-hook method based on address randomization |
| CN108052328A (en) * | 2017-11-09 | 2018-05-18 | 华中科技大学 | A kind of construction method of Android system and its application |
| CN108845917A (en) * | 2018-04-09 | 2018-11-20 | 东峡大通（北京）管理咨询有限公司 | File journalization carry module, system and method in container |
| CN108897617A (en) * | 2018-06-19 | 2018-11-27 | 北京元心科技有限公司 | The method, apparatus and terminal device of memory management |
Non-Patent Citations (1)
| Title |
|---|
| 杨天明等: "基于线性化日志树的连续数据保护技术", 《计算机工程与设计》 * |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110673974A (en) * | 2019-08-20 | 2020-01-10 | 中科创达软件股份有限公司 | System debugging method and device |
| CN111176787A (en) * | 2019-12-23 | 2020-05-19 | 中国建设银行股份有限公司 | Data analysis method and device |
| CN111176787B (en) * | 2019-12-23 | 2023-07-28 | 中国建设银行股份有限公司 | Data analysis method and device |
| CN114168203A (en) * | 2020-09-10 | 2022-03-11 | 成都鼎桥通信技术有限公司 | Dual-system running state control method and device and electronic equipment |
| CN114168203B (en) * | 2020-09-10 | 2024-02-13 | 成都鼎桥通信技术有限公司 | Dual-system running state control method and device and electronic equipment |
| CN112905537A (en) * | 2021-02-20 | 2021-06-04 | 北京百度网讯科技有限公司 | File processing method and device, electronic equipment and storage medium |
| CN112905537B (en) * | 2021-02-20 | 2022-09-02 | 北京百度网讯科技有限公司 | File processing method and device, electronic equipment and storage medium |
| WO2023273482A1 (en) * | 2021-06-29 | 2023-01-05 | 华为技术有限公司 | Control method and electronic device |
| WO2023093127A1 (en) * | 2021-11-26 | 2023-06-01 | 北京百度网讯科技有限公司 | Method and apparatus for monitoring a cluster, and electronic device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109977093A (en) | More virtual systems based on LXC check the method and device of container log | |
| US10320674B2 (en) | Independent network interfaces for virtual network environments | |
| US9183378B2 (en) | Runtime based application security and regulatory compliance in cloud environment | |
| US20200201686A1 (en) | Method and Apparatus for Accessing Desktop Cloud Virtual Machine, and Desktop Cloud Controller | |
| US9813423B2 (en) | Trust-based computing resource authorization in a networked computing environment | |
| CN103488791B (en) | Data access method, system and data warehouse | |
| CN108427649B (en) | Access management method, terminal device, system and storage medium of USB interface | |
| US8417848B2 (en) | Method and apparatus for implementing multiple service processing functions | |
| CN107222326B (en) | Access method, configuration method and device for service between devices | |
| US20140359613A1 (en) | Physical/virtual device failover with a shared backend | |
| TW201629783A (en) | Emulated endpoint configuration | |
| CN108322325B (en) | Virtual machine management method and device | |
| WO2012103827A2 (en) | Method and device for checkpoint and restart of container state | |
| CN107580011B (en) | Data sharing method and desktop cloud server | |
| US11411887B2 (en) | Method and device for performing traffic control on user equipment | |
| CN108234551A (en) | A kind of data processing method and device | |
| CN110781014B (en) | Recording data multi-process distribution method and system based on Android device | |
| CN115033348B (en) | Method, system, equipment and medium for unified management of virtual machine and container | |
| US20150381766A1 (en) | Application transfer system, application transfer method, terminal, and program | |
| US10911371B1 (en) | Policy-based allocation of provider network resources | |
| CN108021801B (en) | Virtual desktop-based anti-leakage method, server and storage medium | |
| KR20130063399A (en) | Mobile terminal and cloud server for mobile cloud computing environment and method of mobile cloud computing using the same | |
| US10809927B1 (en) | Online conversion of storage layout | |
| US9609080B2 (en) | Systems and methods for device identity delegation for application software | |
| CN112637106A (en) | Method and device for terminal to access website |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190705 |