Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
openeuler
libvirt
提交
0b5c717b
L
libvirt
项目概览
openeuler
/
libvirt
通知
3
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
L
libvirt
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
提交
0b5c717b
编写于
11年前
作者:
J
John Ferlan
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
api: Add text and references for daemon
上级
b1083281
无相关合并请求
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
43 addition
and
0 deletion
+43
-0
docs/api.html.in
docs/api.html.in
+43
-0
未找到文件。
docs/api.html.in
浏览文件 @
0b5c717b
...
...
@@ -186,9 +186,52 @@
support was added into libvirt.
</p>
<h2><a
name=
"Remote"
>
Daemon and Remote Access
</a></h2>
<p>
Access to libvirt drivers is primarily handled by the libvirtd
daemon through the
<a
href=
"remote.html"
>
remote
</a>
driver via an
<a
href=
"internals/rpc.html"
>
RPC
</a>
. Some hypervisors do support
client-side connections and responses, such as Test, OpenVZ, VMware,
Power VM (phyp), VirtualBox (vbox), ESX, Hyper-V, Xen, and Parallels.
The libvirtd daemon service is started on the host at system boot
time and can also be restarted at any time by a properly privileged
user, such as root. The libvirtd daemon uses the same libvirt API
<code
class=
'docref'
>
virInitialize
</code>
sequence as applications
for client-side driver registrations, but then extends the registered
driver list to encompass all known drivers supported for all driver
types supported on the host.
</p>
<p>
The libvirt client
<a
href=
"apps.html"
>
applications
</a>
use a
<a
href=
"uri.html"
>
URI
</a>
to obtain the
<code>
virConnectPtr
</code>
.
The
<code>
virConnectPtr
</code>
keeps track of the driver connection
plus a variety of other connections (network, interface, storage, etc.).
The
<code>
virConnectPtr
</code>
is then used as a parameter to other
virtualization
<a
href=
"#Functions"
>
functions
</a>
. Depending upon the
driver being used, calls will be routed through the remote driver to
the libvirtd daemon. The daemon will reference the connection specific
driver in order to retreive the requested information and then pass
back status and/or data through the connection back to the application.
The application can then decide what to do with that data, such as
display, write log data, etc.
<a
href=
"migration.html"
>
Migration
</a>
is an example of many facets of the architecture in use.
</p>
<p
class=
"image"
>
<img
alt=
"The libvirt daemon and remote architecture"
src=
"libvirt-daemon-arch.png"
/>
</p>
<p>
The key takeaway from the above diagram is that there is a remote driver
which handles transactions for a majority of the drivers. The libvirtd
daemon running on the host will receive transaction requests from the
remote driver and will then query the hypervisor driver as specified in
the
<code>
virConnectPtr
</code>
in order to fetch the data. The data will
then be returned through the remote driver to the client application
for processing.
</p>
<p>
If you are interested in contributing to libvirt, read the
<a
href=
"http://wiki.libvirt.org/page/FAQ"
>
FAQ
</a>
and
<a
href=
"hacking.html"
>
hacking
</a>
guidelines to gain an understanding
of basic rules and guidelines. In order to add new API functionality
follow the instructions regarding
<a
href=
"api_extension.html"
>
implementing a new API in libvirt
</a>
.
</p>
</body>
</html>
This diff is collapsed.
Click to expand it.
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录
反馈
建议
客服
返回
顶部