mirror of https://gitee.com/openkylin/libvirt.git
fe3840eac7
A few commits back (in v6.4.0-131-gbdb8f2e418) the post parse function for domain interface was changed so that it doesn't fill in model for hostdev types of interfaces (including network type interfaces which would end up hostdevs). While the idea is sound, the execution can be a bit better: virDomainNetResolveActualType() which is used to determine runtime type of given interface is heavy gun - it connects to network driver, fetches network XML, parses it. This all is followed by check whether the interface doesn't already have model set (from domain XML). If we switch the order of these two checks then the short circuit evaluation will ensure the expensive check is done only if really needed. This commit in fact fixes qemuxml2xmltest which due to lacking fake network driver tries to connect to network:///session and start the virtnetworkd. Fortunately, because of v6.3.0-25-gf28fbb05d3 it fails to do so and virDomainNetResolveActualType() returns -1. The only reason we don't see the test failing is because our input XMLs have model and thus we are saved by the latter (now former) check. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com> |
||
|---|---|---|
| .ctags.d | ||
| .github | ||
| build-aux | ||
| ci | ||
| docs | ||
| examples | ||
| include/libvirt | ||
| m4 | ||
| po | ||
| scripts | ||
| src | ||
| tests | ||
| tools | ||
| .color_coded.in | ||
| .ctags | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitmodules | ||
| .gitpublish | ||
| .mailmap | ||
| .ycm_extra_conf.py.in | ||
| ABOUT-NLS | ||
| AUTHORS.in | ||
| CONTRIBUTING.rst | ||
| COPYING | ||
| COPYING.LESSER | ||
| ChangeLog | ||
| GNUmakefile | ||
| Makefile.am | ||
| Makefile.nonreentrant | ||
| NEWS.rst | ||
| README | ||
| README.rst | ||
| autogen.sh | ||
| config-post.h | ||
| configure.ac | ||
| gitdm.config | ||
| libvirt-admin.pc.in | ||
| libvirt-lxc.pc.in | ||
| libvirt-qemu.pc.in | ||
| libvirt.pc.in | ||
| libvirt.spec.in | ||
| mingw-libvirt.spec.in | ||
| run.in | ||
README
.. image:: https://gitlab.com/libvirt/libvirt/badges/master/pipeline.svg
:target: https://gitlab.com/libvirt/libvirt/pipelines
:alt: GitLab CI Build Status
.. image:: https://travis-ci.org/libvirt/libvirt.svg
:target: https://travis-ci.org/libvirt/libvirt
:alt: Travis CI Build Status
.. image:: https://bestpractices.coreinfrastructure.org/projects/355/badge
:target: https://bestpractices.coreinfrastructure.org/projects/355
:alt: CII Best Practices
.. image:: https://translate.fedoraproject.org/widgets/libvirt/-/libvirt/svg-badge.svg
:target: https://translate.fedoraproject.org/engage/libvirt/
:alt: Translation status
==============================
Libvirt API for virtualization
==============================
Libvirt provides a portable, long term stable C API for managing the
virtualization technologies provided by many operating systems. It
includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware
vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER
Hypervisor.
For some of these hypervisors, it provides a stateful management
daemon which runs on the virtualization host allowing access to the
API both by non-privileged local users and remote users.
Layered packages provide bindings of the libvirt C API into other
languages including Python, Perl, PHP, Go, Java, OCaml, as well as
mappings into object systems such as GObject, CIM and SNMP.
Further information about the libvirt project can be found on the
website:
https://libvirt.org
License
=======
The libvirt C API is distributed under the terms of GNU Lesser General
Public License, version 2.1 (or later). Some parts of the code that are
not part of the C library may have the more restrictive GNU General
Public License, version 2.0 (or later). See the files ``COPYING.LESSER``
and ``COPYING`` for full license terms & conditions.
Installation
============
Instructions on building and installing libvirt can be found on the website:
https://libvirt.org/compiling.html
Contributing
============
The libvirt project welcomes contributions in many ways. For most components
the best way to contribute is to send patches to the primary development
mailing list. Further guidance on this can be found on the website:
https://libvirt.org/contribute.html
Contact
=======
The libvirt project has two primary mailing lists:
* libvirt-users@redhat.com (**for user discussions**)
* libvir-list@redhat.com (**for development only**)
Further details on contacting the project are available on the website:
https://libvirt.org/contact.html