mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-07-30 21:47:18 +00:00
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.
dddad4bcb4
Xen HVM guests with PV drivers end up with two network interfaces for
each configured interface. One of them being emulated by qemu and the
other one paravirtual. As this might not be desirable, the attached
patch provides a way for users to specify that only paravirtual network
interface should be presented to the guest.
The configuration was inspired by qemu/kvm driver, for which users can
specify model='virtio' to use paravirtual network interface.
The patch adds support for model='netfront' which results in
type=netfront instead of type=ioemu (or nothing for newer xen versions)
in guests native configuration. Xen's qemu ignores interfaces with
type != ioemu and only paravirtual network device will be seen in the
guest.
Four possible configuration scenarios follow:
- no model specified in domain's XML
- libvirt will behave like before this change; it will set
type=ioemu for HVM guests on xen host which is not newer than
XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU
- covered by existing tests
- PV guest, any model
- no functional change, model is passed as is (and ignored by the
hypervisor)
- covered by existing tests (e.g., *-net-e1000.*)
- HVM guest, model=netfront
- type is set to "netfront", model is not specified
- covered by new *-net-netfront.* tests
- HVM guest, model != netfront
- type is set to "ioemu", model is passed as is
- covered by new *-net-ioemu.* tests
The fourth scenario feels like a regression for xen newer than
XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU as users who had a model specified
in their guest's configuration won't see a paravirtual interface in
their guests any more. On the other hand, the reason for specifying a
model is most likely the fact that they want to use such model which
implies emulated interface. Users of older xen won't be affected at all
as their xen provides paravirtual interface regardless of the type used.
- src/xen/xend_internal.c: add netfront support for the xend backend
- src/xen/xm_internal.c: add netfront support for the XM serialization too
|
||
|---|---|---|
| .gnulib@28db629d4f | ||
| build-aux | ||
| daemon | ||
| docs | ||
| examples | ||
| include | ||
| m4 | ||
| po | ||
| proxy | ||
| python | ||
| src | ||
| tests | ||
| tools | ||
| .gitignore | ||
| .gitmodules | ||
| .hgignore | ||
| .x-sc_avoid_ctype_macros | ||
| .x-sc_avoid_if_before_free | ||
| .x-sc_avoid_write | ||
| .x-sc_m4_quote_check | ||
| .x-sc_prohibit_asprintf | ||
| .x-sc_prohibit_gethostby | ||
| .x-sc_prohibit_gethostname | ||
| .x-sc_prohibit_have_config_h | ||
| .x-sc_prohibit_HAVE_MBRTOWC | ||
| .x-sc_prohibit_nonreentrant | ||
| .x-sc_prohibit_strcmp | ||
| .x-sc_prohibit_strcmp_and_strncmp | ||
| .x-sc_prohibit_strncpy | ||
| .x-sc_prohibit_VIR_ERR_NO_MEMORY | ||
| .x-sc_require_config_h | ||
| .x-sc_require_config_h_first | ||
| .x-sc_trailing_blank | ||
| acinclude.m4 | ||
| AUTHORS | ||
| autobuild.sh | ||
| autogen.sh | ||
| bootstrap | ||
| cfg.mk | ||
| ChangeLog-old | ||
| configure.in | ||
| COPYING.LIB | ||
| HACKING | ||
| libvirt.pc.in | ||
| libvirt.spec.in | ||
| Makefile.am | ||
| Makefile.nonreentrant | ||
| mingw32-libvirt.spec.in | ||
| README | ||
| README-hacking | ||
| TODO | ||
LibVirt : simple API for virtualization
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). It is free software
available under the GNU Lesser General Public License. Virtualization of
the Linux Operating System means the ability to run multiple instances of
Operating Systems concurrently on a single hardware system where the basic
resources are driven by a Linux instance. The library aim at providing
long term stable C API initially for the Xen paravirtualization but
should be able to integrate other virtualization mechanisms if needed.
Daniel Veillard <veillard@redhat.com>