mirror of
https://github.com/libvirt/libvirt.git
synced 2026-10-02 12:20:06 -05:00
Laine Stump
6b2c18913f
This new function sends the command "announce-self" to QEMU, causing
it to inject a series of gratuitous ARP (GARP) response packets into
the output stream of one or all guest interfaces, which will force any
switches in the same collision domain to update their forwarding db
for that interface's MAC address.
There are several parameters that control which interfaces the GARP
packets are sent on, as well as their number and interval, but all of
these parameters have sane defaults (even though QEMU's own
self-announce requires they all be specified in the QMP command).
Here is an example of the fully formed JSON for an announce-self:
{"execute":"announce-self",
"arguments":{"interfaces":["net1"],
"initial":50,
"max":550,
"rounds":5,
"step":50},
"id":"libvirt-16"}
All parameters except "interface" are unsigned integers that are
mandatory in the JSON command sent to QEMU. libvirt's
qemuMonitoAnnounceSelf() function, however, makes them optional by
replacing anything set to 0 with the same default value used
internally by QEMU when it is executing announce-self for a guest at
the end of a migration (initial=50, max=550, rounds-5, step=50).
"interfaces" (the only optional parameter from QEMU's point of view)
is (again, from QEMU's PoV) a *list* of the QEMU device-ids for the
interfaces to announce (if it's missing then announce-self injects
announcements on *all* of this guest's interfaces), but it seems much
more likely that someone will either want to announce a single
interface, or all of them, so to simplify calling in the more common
cases, our function just accepts a *single* device name (that can be
NULL) and creates a JSON array containing that one interface name (in
the rare case that someone wants to announce multiple interfaces but
not all of them, they can call our API multiple times).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
.. image:: https://gitlab.com/libvirt/libvirt/badges/master/pipeline.svg
:target: https://gitlab.com/libvirt/libvirt/pipelines
:alt: GitLab 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:
* users@lists.libvirt.org (**for user discussions**)
* devel@lists.libvirt.org (**for development only**)
Further details on contacting the project are available on the website:
https://libvirt.org/contact.html