Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt
切换分支/标签
  1. 23 10月, 2019 1 次提交
  3. 28 8月, 2019 1 次提交
  5. 27 6月, 2019 1 次提交
  7. 20 6月, 2019 1 次提交
  9. 12 4月, 2018 1 次提交
    • D
      driver: introduce a driver method for probing default URIs · 20ad55a8
      由 Daniel P. Berrangé 提交于 
      Currently the virDrvConnectOpen method is supposed to handle both
opening an explicit URI and auto-probing a driver if no URI is
given. Introduce a dedicated virDrvConnectURIProbe method to enable the
probing functionality to be split from the driver opening functionality.

It is still possible for NULL to be passed to the virDrvConnectOpen
method after this change, because the remote driver needs special
handling to enable probing of the URI against a remote libvirtd daemon.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      20ad55a8
  11. 19 9月, 2017 1 次提交
  13. 03 8月, 2017 1 次提交
  15. 11 11月, 2016 2 次提交
  17. 20 7月, 2016 3 次提交
    • J
      hvsupport: skip non-matching lines early · f1bbf57c
      由 Ján Tomko 提交于 
      Most of the lines we look at are not going to match one of the
driver types contained in $groups_regex.

Move on to the next line if it does not contain any of them early.
This speeds up the script execution by 50%, since this simple regex
does not have any capture groups.
      f1bbf57c
    • J
      hvsupport: construct the group regex upfront · 6dc1f103
      由 Ján Tomko 提交于 
      The %groups hash contains all the driver types (e.g.
virHypervisorDriver or virSecretDriver).

When searching for all the APIs that are implemented by a driver
of that specific driver type, we keep iterating over the %groups
hash on every line we look at, then matching against the driver type.

This is inefficient because it prevents perl from caching the regex
and it executes the regex once for every driver type, even though
one regex matching excludes all the others, since all the driver types
are different.

Construct the regex containing all the driver types upfront to save
about 6.4s (~98%) of the script execution time.
      6dc1f103
    • J
      hvsupport: use a regex instead of XML::XPath · ad9e72f5
      由 Ján Tomko 提交于 
      When generating the hvsupport.html.in file, we parse the -api.xml
files generated by apibuild.py to know in which HTML file the API
function is.

Doing an XPath query for every single 'function' element in the
file is inefficient.

Since the XML file is generated by another of our build scripts
(apibuild.py, using Python's standard 'output.write' XML library),
just find the function name->file mapping by a regex upfront.

Also add a note about this next to the line that generates it
in apibuild.py and do not check if XML::XPath is installed in
bootstrap since we no longer use it.
      ad9e72f5
  19. 18 7月, 2016 1 次提交
    • J
      hvsupport: Introduce parseSymsFile · fa0b00f9
      由 Ján Tomko 提交于 
      The code for parsing the different public syms files only differs
in the filenames and version prefix.

Unify it to a single subroutine.
      fa0b00f9
  21. 02 12月, 2014 1 次提交
    • M
      docs: Correct invalid hyperlinks · af1b89d1
      由 Martin Kletzander 提交于 
      Since libvirt.h was split into multiple files and similarly
docs/libvirt-libvirt.html, docs/hvsupport.html have bad hyperlinks.  The
same happens for all the html.in files that used <code class='docref'>
tag, because page.xsl has no idea where to point the link that's found.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      af1b89d1
  23. 19 11月, 2014 1 次提交
  25. 13 11月, 2014 1 次提交
    • D
      Fix API docs for header file re-organization · 47fb6138
      由 Daniel P. Berrange 提交于 
      The API docs generators were broken by the header file
re-organization. Specifically

 * html/libvirt-libvirt.html was empty (and should be deleted)
 * Makefile.am didn't install html/libvirt-libvirt-*.html
 * hvsupport.html was mostly empty
 * sitemap.html.in didn't list the new html/*.html files
      47fb6138
  27. 23 10月, 2014 1 次提交
  29. 21 8月, 2014 1 次提交
    • M
      hvsupport: Adapt to vbox driver rewrite · cf389258
      由 Michal Privoznik 提交于 
      Since vbox driver rewrite the virDriver structure init moved from
vbox_tmpl.c into vbox_common.c. However, our hvsupport.pl script
doesn't count with that. It still parses vbox_tmp.c and looks for
virDriver structure which is not found there anymore. As a result,
at hvsupport page is seems like vbox driver doesn't support
anything.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      cf389258
  31. 25 6月, 2013 1 次提交
  33. 07 5月, 2013 1 次提交
  35. 24 4月, 2013 4 次提交
  37. 14 1月, 2013 1 次提交
    • D
      Introduce an LXC specific public API & library · 3d1596b0
      由 Daniel P. Berrange 提交于 
      This patch introduces support for LXC specific public APIs. In
common with what was done for QEMU, this creates a libvirt_lxc.so
library and libvirt/libvirt-lxc.h header file.

The actual APIs are

  int virDomainLxcOpenNamespace(virDomainPtr domain,
                                int **fdlist,
                                unsigned int flags);

  int virDomainLxcEnterNamespace(virDomainPtr domain,
                                 unsigned int nfdlist,
                                 int *fdlist,
                                 unsigned int *noldfdlist,
                                 int **oldfdlist,
                                 unsigned int flags);

which provide a way to use the setns() system call to move the
calling process into the container's namespace. It is not
practical to write in a generically applicable manner. The
nearest that we could get to such an API would be an API which
allows to pass a command + argv to be executed inside a
container. Even if we had such a generic API, this LXC specific
API is still useful, because it allows the caller to maintain
the current process context, in particular any I/O streams they
have open.

NB the virDomainLxcEnterNamespace() API is special in that it
runs client side, so does not involve the internal driver API.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      3d1596b0
  39. 30 7月, 2012 1 次提交
  41. 06 6月, 2011 1 次提交
  43. 17 5月, 2011 1 次提交
  45. 16 5月, 2011 2 次提交
    • D
      Introduce yet another migration version in API. · 65043d2d
      由 Daniel P. Berrange 提交于 
      Migration just seems to go from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.

It turns out that this protocol still has some flaws that we
need to address. The current sequence is

 *  Src: DumpXML
          - Generate XML to pass to dst

 *  Dst: Prepare
          - Get ready to accept incoming VM
          - Generate optional cookie to pass to src

 *  Src: Perform
          - Start migration and wait for send completion
          - Kill off VM if successful, resume if failed

 *  Dst: Finish
          - Wait for recv completion and check status
          - Kill off VM if unsuccessful

The problems with this are:

 - Since the first step is a generic 'DumpXML' call, we can't
   add in other migration specific data. eg, we can't include
   any VM lease data from lock manager plugins
 - Since the first step is a generic 'DumpXML' call, we can't
   emit any 'migration begin' event on the source, or have
   any hook that runs right at the start of the process
 - Since there is no final step on the source, if the Finish
   method fails to receive all migration data & has to kill
   the VM, then there's no way to resume the original VM
   on the source

This patch attempts to introduce a version 3 that uses the
improved 5 step sequence

 *  Src: Begin
          - Generate XML to pass to dst
          - Generate optional cookie to pass to dst

 *  Dst: Prepare
          - Get ready to accept incoming VM
          - Generate optional cookie to pass to src

 *  Src: Perform
          - Start migration and wait for send completion
          - Generate optional cookie to pass to dst

 *  Dst: Finish
          - Wait for recv completion and check status
          - Kill off VM if failed, resume if success
          - Generate optional cookie to pass to src

 *  Src: Confirm
          - Kill off VM if success, resume if failed

The API is designed to allow both input and output cookies
in all methods where applicable. This lets us pass around
arbitrary extra driver specific data between src & dst during
migration. Combined with the extra 'Begin' method this lets
us pass lease information from source to dst at the start of
migration

Moving the killing of the source VM out of Perform and
into Confirm, means we can now recover if the dst host
can't successfully Finish receiving migration data.
      65043d2d
    • D
      Automatically generate the hvsupport.html.in file from source files · 4ffc6d17
      由 Daniel P. Berrange 提交于 
      The hvsupport.html.in file is forever out of date. By annotating
the driver struct tables in each driver with version information,
we can auto-generate the hvsupport.html.in file. Annotating the
drivers will be mandatory for new patches, ensuring hvsupport.html.in
is never out of date again.

* docs/hvsupport.html.in: Delete
* hvsupport.pl: Script to generate hvsupport.html.in
* Makefile.am: Autogenerate hvsupport.html.in
      4ffc6d17