- 09 8月, 2019 12 次提交
-
-
由 Daniel P. Berrangé 提交于
The virtqemud daemon will be responsible for providing the qemu API driver functionality. The qemu driver is still loaded by the main libvirtd daemon at this stage, so virtqemud must not be running at the same time. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virtxend daemon will be responsible for providing the libxl API driver functionality. The libxl driver is still loaded by the main libvirtd daemon at this stage, so virtxend must not be running at the same time. This naming is slightly different than other drivers. With the libxl driver, the user still has a 'xen:///system' URI, and we provide it in a libvirt-daemon-xen RPM, which pulls in a libvirt-daemon-driver-libxl RPM. Arguably we could rename the libxl driver to "xen" since it is the only xen driver we have these days, and that matches how we expose it to users in the URI naming. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virtnwfilterd daemon will be responsible for providing the nwfilter API driver functionality. The nwfilter driver is still loaded by the main libvirtd daemon at this stage, so virtnwfilterd must not be running at the same time. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virtnodedevd daemon will be responsible for providing the nodedev API driver functionality. The nodedev driver is still loaded by the main libvirtd daemon at this stage, so virtnodedevd must not be running at the same time. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virtstoraged daemon will be responsible for providing the storage API driver functionality. The storage driver is still loaded by the main libvirtd daemon at this stage, so virtstoraged must not be running at the same time. Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virtinterfaced daemon will be responsible for providing the interface API driver functionality. The interface driver is still loaded by the main libvirtd daemon at this stage, so virtinterfaced must not be running at the same time. Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virtnetworkd daemon will be responsible for providing the network API driver functionality. The network driver is still loaded by the main libvirtd daemon at this stage, so virtnetworkd must not be running at the same time. Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virtsecretd daemon will be responsible for providing the secret API driver functionality. The secret driver is still loaded by the main libvirtd daemon at this stage, so virtsecretd must not be running at the same time. Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The libvirtd daemon provides the traditional libvirt experience where all the drivers are in a single daemon, and is accessible over both local UNIX sockets and remote IP sockets. In the new world we're having a set of per-driver daemons which will primarily be accessed locally via their own UNIX sockets. We still, however, need to allow for case of applications which will connect to libvirt remotely. These remote connections can be done as TCP/TLS sockets, or by SSH tunnelling to the UNIX socket. In the later case, the old libvirt.so clients will only know about the path to the old libvirtd socket /var/run/libvirt/libvirt-sock, and not the new driver sockets /var/run/libvirt/virtqemud-sock. It is also not desirable to expose the main driver specific daemons over IP directly to minimize their attack service. Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets, and back compat for the old libvirtd UNIX socket path(s). It will then forward all RPC calls made to the appropriate driver specific daemon. Essentially it is equivalent to the old libvirtd with absolutely no drivers registered except for the remote driver (and other stateless drivers in libvirt.so). We could have modified libvirtd so none of the drivers are registed to get the same end result. We could even add a libvirtd.conf parameter to control whether the drivers are loaded to enable users to switch back to the old world if we discover bugs in the split-daemon model. Using a new daemon though has some advantages - We can make virtproxyd and the virtXXXd per-driver daemons all have "Conflicts: libvirtd.service" in their systemd unit files. This will guarantee that libvirtd is never started at the same time, as this would result in two daemons running the same driver. Fortunately drivers use locking to protect themselves, but it is better to avoid starting a daemon we know will conflict. - It allows us to break CLI compat to remove the --listen parameter. Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf will default to zero. Either TLS or TCP can be enabled exclusively though virtd.conf without requiring the extra step of adding --listen. - It allows us to set a strict SELinux policy over virtproxyd. For back compat the libvirtd policy must continue to allow all drivers to run. We can't easily give a second policy to libvirtd which locks it down. By introducing a new virtproxyd we can set a strict policy for that daemon only. - It gets rid of the weird naming of having a daemon with "lib" in its name. Now all normal daemons libvirt ships will have "virt" as their prefix not "libvirt". - Distros can more easily choose their upgrade path. They can ship both sets of daemons in their packages, and choose to either enable libvirtd, or enable the per-driver daemons and virtproxyd out of the box. Users can easily override this if desired by just tweaking which systemd units are active. After some time we can deprecate use of libvirtd and after some more time delete it entirely, leaving us in a pretty world filled with prancing unicorns. The main downside with introducing a new daemon, and with the per-driver daemons in general, is figuring out the correct upgrade path. The conservative option is to leave libvirtd running if it was an existing installation. Only use the new daemons & virtproxyd on completely new installs. The aggressive option is to disable libvirtd if already running and activate all the new daemons. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Prepare for reusing libvirtd augeas defintions with other daemons by making the config parameters for IP sockets conditionally defined by the make rules. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Prepare for reusing libvirtd config to create other daemons by making the config parameters for IP sockets conditionally defined by the make rules. The main libvirtd daemon will retain IP listen ability, but all the driver specific daemons will be local UNIX sockets only. Apps needing IP connectivity will connect via the libvirtd daemon which will proxy to the driver specfic daemon. Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The current make rules are inconsistent about which directory the augeas test files are created in. Put them all in the same dir as their source. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 07 8月, 2019 1 次提交
-
-
由 Daniel P. Berrangé 提交于
The virt-login-shell binary is a setuid program that takes no arguments. When invoked it looks at the invoking uid, resolves it to a username, and finds an LXC guest with the same name. It then starts the guest and runs the shell in side the namespaces of the container. Given this set of tasks the virt-login-shell binary needs to connect to libvirtd, make various other libvirt API calls. This is a problem for setuid binaries as various libraries that libvirt.so links to are not safe. For example, they have constructor functions which execute an unknown amount of code that can be influenced by env variables. For this reason virt-login-shell doesn't use libvirt.so, but instead links to a custom, cut down, set of source files sufficient to be a local client only. This introduces a problem for integrating glib2 into libvirt though, as once integrated, there would be no way to build virt-login-shell without an external dependancy on glib2 and this is definitely not setuid safe. To resolve this problem, we split the virt-login-shell binary into two parts. The first part is setuid and does almost nothing. It simply records the original uid+gid, and then invokes the virt-login-shell-helper binary. Crucially when it does this it completes scrubs all environment variables. It is thus safe for virt-login-shell-helper to link to the normal libvirt.so. Any things that constructor functions do cannot be influenced by user control env vars or cli args. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 03 6月, 2019 2 次提交
-
-
由 Andrea Bolognani 提交于
All other examples are organized using the either the format/ or the format/category/ hierarchy already, and grouping all C programs together removes the last remaining outliers. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Acked-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
Most C examples live in their own directory, which seems a bit unnecessary especially considering that all virt-admin related examples share a single admin/ directory. Reorganize non-admin C examples in two categories: domain/ for those that act on a domain, and misc/ for everything else. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Acked-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 12 4月, 2019 1 次提交
-
-
由 Daniel P. Berrangé 提交于
The Travis CI system uses Docker containers for its build environment. These are pre-built and hosted under quay.io/libvirt so that developers can use them for reproducing problems locally. Getting the right Docker command syntax to use them, however, is not entirely easy. This patch addresses that usability issue by introducing some make targets. To run a simple build (aka 'make all') using the Fedora 28 container: make ci-build@fedora-28 To also run unit tests make ci-check@fedora-28 This is just syntax sugar for calling the previous command with a custom make target make ci-build@fedora-28 CI_MAKE_ARGS="check" To do a purely interactive build it is possible to request a shell make ci-shell@fedora-28 To do a MinGW build, it is currently possible to use the fedora-rawhide image and request a different configure script make ci-build@fedora-rawhide CI_CONFIGURE=mingw32-configure It is also possible to do cross compiled builds via the Debian containers make ci-build@debian-9-cross-s390x In all cases the GIT source tree is cloned locally into a 'ci-tree/src' sub-directory which is then exposed to the container at '/src'. It is setup to use a separate build directory so the build takes place in a subdir '/src/build'. A source tree build can be requested instead by passing an empty string CI_VPATH= arg to make. The make rules are kept in a standalone file that is included into the main Makefile.am, so that it is possible to run them without having to invoke autotools first. It is neccessary to disable the gnulib submodule commit check because this fails due to the way we have manually cloned submodule repos as primary git repos with their own .git directory, instead of letting git treat them as submodules in the top level .git directory. make[1]: Entering directory '/src/build' fatal: Not a valid object name origin fatal: run_command returned non-zero status for .gnulib . maint.mk: found non-public submodule commit make: *** [/src/maint.mk:1448: public-submodule-commit] Error 1 Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 05 4月, 2019 1 次提交
-
-
由 Cole Robinson 提交于
libvirt.org/search.php drops into some kind of screen which I guess is supposed to show a search bar with options, but presently for me renders as nothing but the following text: Search the documentation on Libvirt.org The search service indexes the libvirt APIs and documentation as well as the libvir-list@redhat.com mailing-list archives. To use it simply provide a set of keywords: The main page search bar now redirects to google, this page is broken, I say we just remove it and move on. Reviewed-by: NDaniel P. Berrange <berrange@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
- 03 4月, 2019 1 次提交
-
-
由 Andrea Bolognani 提交于
Our ChangeLog is generated by basically redirecting the output of 'git log' into it so, as can be expected, it has only gotten bigger as development has progressed. As of today, its size has reached pretty much comical levels: $ du -sk ChangeLog 11328 ChangeLog All of that for information *literally nobody* cares about: end users and distro maintainers have proper release notes lovingly compiled for them, while developers peruse the history either by calling 'git log' directly or through their favorite $EDITOR's git integration. Replacing the generated ChangeLog with a short message pointing interested parties to the git repository does not only reduce the size of the unpacked sources from 259904 KiB to 248576 KiB (~4% saving): from a quick test on my laptop, doing so reduces the size of the *compressed* release archive from 15140 KiB to 12364 KiB (~18% saving) and also takes the time needed to run 'make distcheck' down from 4:44 to 4:21 (~8% saving). Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 16 3月, 2019 1 次提交
-
-
由 Andrea Bolognani 提交于
Despite the misleading name, these were supposed to be used with a System V style init; however, none of the platforms we target is using that kind of init anymore: almost all Linux distributions have switched to systemd, those that haven't (such as Gentoo and Alpine) are mostly using OpenRC with custom init scripts, and the BSDs have been doing their own thing all along. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 12 2月, 2019 1 次提交
-
-
由 Michal Privoznik 提交于
In order to be able to dissect libvirt protocol the wireshark plugin needs to be registered. So far this plugin registration code was generated on every build using a script that was copied over from wireshark's tools/ directory. This is suboptimal, because the way that plugins register changes across wireshark releases. Therefore, let's keep the generated file in the git, put the command line used to generate the file into a comment and remove the script. This solution allows us to put different registration mechanism into one file (under #ifdef-s) and thus compile with wider range of wireshark releases. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 19 4月, 2018 2 次提交
-
-
由 Daniel P. Berrangé 提交于
Similar to the libvirt.pot, .po files contain line numbers and file names identifying where in the source a translatable string comes from. The source locations in the .po files are thrown away and replaced with content from the libvirt.pot whenever msgmerge is run, so this is not precious information that needs to be stored in git. When msgmerge processes a .po file, it will add in any msgids from the libvirt.pot that were not already present. Thus, if a particular msgid currently has no translation, it can be considered redundant and again does not need storing in git. When msgmerge processes a .po file and can't find an exact existing translation match, it will try todo fuzzy matching instead, marking such entries with a "# fuzzy" comment to alert the translator to take a look and either discard, edit or accept the match. Looking at the existing fuzzy matches in .po files shows that the quality is awful, with many having a completely different set of printf format specifiers between the msgid and fuzzy msgstr entry. Fortunately when msgfmt generates the .gmo, the fuzzy entries are all ignored anyway. The fuzzy entries could be useful to translators if they were working on the .po files directly from git, but Libvirt outsourced translation to the Fedora Zanata system, so keeping fuzzy matches in git is not much help. Finally, by default msgids are sorted based on source location. Thus, if a bit of code with translatable text is moved from one file to another, it may shift around in the .po file, despite the msgid not itself changing. If the msgids were sorted alphabetically, the .po files would have stable ordering when code is refactored. This patch takes advantage of the above observations to canonicalize and minimize the content stored for .po files in git. Instead of storing the real .po files, we now store .mini.po files. The .mini.po files are the same file format as .po files, but have no source location comments, are sorted alphabetically, and all fuzzy msgstrs and msgids with no translation are discarded. This cuts the size of content in the po directory from 109MB to 19MB. Users working from a libvirt git checkout who need the full .po files can run "make update-po", which merges the libvirt.pot and .mini.po file to create a .po file containing all the content previously stored in git. Conversely if a full .po file has been modified, for example, by downloading new content from Zanata, the .mini.po files can be updated by running "make update-mini-po". The resulting diffs of the .mini.po file will clearly show the changed translations without any of the noise that previously obscured content. Being able to see content changes clearly actually identified a bug in the zanata python client where it was adding bogus "fuzzy" annotations to many messages: https://bugzilla.redhat.com/show_bug.cgi?id=1564497 Users working from libvirt releases should not see any difference in behaviour, since the tarballs only contain the full .po files, not the .mini.po files. As an added benefit, generating tarballs with "make dist", will no longer cause creation of dirty files in git, since it won't touch the .mini.po files, only the .po files which are no longer kept in git. To avoid creating a single commit 100+MB in size, each language is minimized separately in a following commit. Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Historically we have relied on autopoint/gettextize to install a standard po/Makefile.in.in. There is very limited scope for customizing this and it also causes a bunch of extra stuff to be pulled into configure.ac which potentially clashes with gnulib. Writing make rules for po file management is no more difficult than any other rules libvirt has, so stop using autopoint/gettextize. Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 14 3月, 2018 1 次提交
-
-
由 Ján Tomko 提交于
This essentially reverts commit <e1019e9e>, which added an extra step for generating the policy file. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 22 2月, 2018 5 次提交
-
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Move the systemd, sysvinit, upstart and sysconfig files into the src/remote/ directory. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Having a daemon/ directory makes little sense from a code structure point of view, as 90% of the code that is built into libvirtd already lives in the src/ directory. The virtlockd and virlogd daemons also live entirely in src/{locking,logging} directories. This moves the source code for libvirtd into src/remote/, alongside the client code. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 31 1月, 2018 1 次提交
-
-
由 Daniel P. Berrange 提交于
The admin server functionality is a generic concept that should be wired up into all libvirt daemons, but is currently integrated with the libvirtd code. Move it all into the src/admin directory to prepare for broader reuse. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 09 5月, 2017 2 次提交
-
-
由 Andrea Bolognani 提交于
YouCompleteMe[1] is a vim plugin that implements semantic code completion using libclang. For non-trivial projects such as libvirt, the plugin needs some help figuring out where to find the various header files: generate its configuration file at configure time so that the plugin works out of the box. [1] http://valloric.github.io/YouCompleteMe/
-
由 Andrea Bolognani 提交于
color_coded[1] is a vim plugin that implements semantic syntax highlighting using libclang. For non-trivial projects such as libvirt, the plugin needs some help figuring out where to find the various header files: generate its configuration file at configure time so that the plugin works out of the box. [1] https://github.com/jeaye/color_coded
-
- 26 4月, 2017 2 次提交
-
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
A long time ago we imported the keymaps.csv file from GTK-VNC so we can do conversions between keycode sets. Meanwhile lots of bug fixes have gone into this CSV file and libvirt hasn't kept in sync. The keymaps.csv file and associated generator script has been pulled out of GTK-VNC into a dedicated GIT repo for use as a submodule. This allows GTK-VNC, SPICE-GTK, QEMU and libvirt to share the same master database and tools and pushing updates merely requires a submodule commit update as with gnulib. The test suite is updated to cover some extra boundary conditions. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 07 4月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
We want to ignore all files except *.pl in build-aux directory, however the unignore pattern "!/build-aux/*.pl" doesn't have any effect because a previous "/build-aux/" pattern ignores the directory itself rather than individual files in it. https://bugzilla.redhat.com/show_bug.cgi?id=1439994Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 11 1月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
Currently, building the NEWS file involves using a XSLT stylesheet to extract information from the same HTML file that's used on the libvirt website. The process works, but it's quite fiddly in that it requires the source HTML to be formatted in a very precise way, and a single missing newline can mess up the resulting plain text considerably. Moreover, the XSLT stylesheet itself encodes a lot of the details of converting to plain text in a way that's not necessarily easy to understand, tweak or fix. To improve the process, move all existing entries to a new XML file that contains exactly the information we care about in a simple structured format, and start generating both the HTML and plain text versions of the release notes using XSLT stylesheets that can now afford to be almost trivial.
-
- 15 12月, 2016 1 次提交
-
-
由 Erik Skultety 提交于
Provide a simple C example demonstrating the use of both query APIs as well as setter APIs. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 14 9月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
Just like we are running 'virsh self-test' from within our test suite, we should run 'virt-admin self-test' too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 26 6月, 2016 1 次提交
-
-
由 Erik Skultety 提交于
Some of the examples make use of asprintf and strtol functions (to keep things simple) which are prohibited to use within our code (enforced by syntax-check). Therefore besides adding some examples, this patch also updates cfg.mk to exclude examples directory from asprintf and strtol rules, as well as updates .gitignore to exclude all the new admin binaries created in the 'examples' dir. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 23 6月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
Also remove the duplicate build-aux entry from .gitignore.
-
- 21 6月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
A new hidden command for virsh that will iterate over all command groups and commands and print help for every single one. This involves running vshCmddefOptParse so we can get an error if one of the command's option structure is invalid.
-