- 07 2月, 2019 13 次提交
-
-
由 Jiri Denemark 提交于
Some migration parameters supported by libvirt may use units that differ from the units used by QEMU for the corresponding parameters. For example, libvirt defines migration bandwidth in MiB/s while QEMU expects B/s. Let's add a unit field to qemuMigrationParamsTPMapItem for automatic conversion when translating between libvirt's migration typed parameters and QEMU's migration paramteres. This patch is a preparation for future parameters as the existing VIR_MIGRATE_PARAM_BANDWIDTH parameter is set using "migrate_set_speed" QMP command rather than "migrate-set-parameters" for backward compatibility. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
The virInitctlFifos list is exported, but lacks definition for non-Linux and/or non-BSD case. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
qemuDomainBlockPivot and qemuDomainBlockJobAbort need the job name for cancelling or pivoting but were generating it locally instead of accessing the existing copy in the job data structure. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
The writing to an image actually starts when the copy job is initiated, so checking this at the time of the pivot operation is too late. Move the check to qemuDomainBlockCopyCommon. Note that modern qemu would have prevented two writers with qcow2 so the slim possibility of a job started with libvirtd without this patch missing the check is not really worth worrying about. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
For copy and active commit jobs we record the state of the mirror so that we can recover. The status XML was not saved in case of qemuDomainBlockPivot due to an oversight. Save the XML always when invoking qemuDomainBlockJobAbort even if the job is not currently tracking any state. This will change later and also this is not a particularly hot code path. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
If the container is really a simple one (init is just bash and the whole root is passed through) then virDomainReboot and virDomainShutdown will talk to the actual init within the host. Therefore, 'virsh shutdown $dom' will result in shutting down the host. True, at that point the container is shut down too but looks a bit harsh to me. The solution is to check if the init inside the container is or is not the same as the init running on the host. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Michal Privoznik 提交于
So far the virInitctlSetRunLevel() is fully automatic. It finds the correct fifo to use to talk to the init and it will set the desired runlevel. Well, callers (so far there is just one) will need to inspect the fifo a bit just before the runlevel is set. Therefore, expose the internal list of fifos and also allow caller to explicitly use one. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Michal Privoznik 提交于
Due to a bug the seclabels are restored before any PID in the container is killed. This should be done afterwards in virLXCProcessCleanup. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Michal Privoznik 提交于
Prior to rewrite of cgroup code we only had one backend to try. After the rewrite the virCgroupBackendGetAll() returns both backends (for v1 and v2). However, not both have to really be present on the system which results in killRecursive callback failing which in turn might mean we won't try the other backend. At the same time, this function reports no error as it should. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Michal Privoznik 提交于
Not that it would matter because LXC driver doesn't differentiate the job types so far, but nevertheless the Destroy() should grab LXC_JOB_DESTROY. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Jie Wang 提交于
The number of iothreads is not part of the vm state sent during migration, nor exposed to the guest ABI, so this restriction is a mistake in libvirt. Let's remove that bit of code. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NJie Wang <wangjie88@huawei.com>
-
- 06 2月, 2019 3 次提交
-
-
由 Nikolay Shirokovskiy 提交于
Device attribute does not have dotted "portAddr" format. Instead it has single number format described but "usbAddr" which corresponds to device parsing code in virDomainHostdevSubsysUSBDefParseXML. Looks like [1] mistakenly changed device format for hostdev devices. And [2] copy-n-paste this for hostdev network interfaces. [1] 31710a53 Modify USB port to be defined as a port path [2] 3b1c191f conf: parse/format type='hostdev' network interfaces Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Andrea Bolognani 提交于
The checks and error messages are mostly the same across all virtio-input devices, so we can avoid having multiple copies of the same code. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
Turns out different versions of QEMU on the same architecture produce the same output, so we can have a single output file per architecture instead of duplicating the same data over and over again. Spotted-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
- 05 2月, 2019 1 次提交
-
-
由 Peter Krempa 提交于
It will not work. This breaks qemu capabilities probing as a user. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 04 2月, 2019 11 次提交
-
-
由 Marc Hartmayer 提交于
For normal starts (no incoming migration) the refresh of the QEMU state must be done before the VCPUs getting started since otherwise there might be a race condition between a possible shutdown of the guest OS and the QEMU monitor queries. This fixes "qemu: migration: Refresh device information after transferring state" (93db7eea). Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Michal Privoznik 提交于
If a domain has a disk that is type='network' we require specific cache mode to allow migration with it (either 'directsync' or 'none'). This doesn't make much sense since network disks are supposed to be safe to migrate by default. At the same time, we should be checking for the actual source type, not apparent type set in the domain XML. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Peter Krempa 提交于
Storage pools might want to specify format of the image when translating the volume thus we can't add any default format when parsing the XML. Add a explicit format when starting the VM and format is not present neither by user specifying it nor by the storage pool translation function. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Post parse callback adds the 'raw' type only for local files. Remote files can also have backing store (even local) so we should do this also for network backed storage. Note that virStorageFileGetMetadata always considers files with no type as raw so we will not accidentally traverse the backing chain and allow unexpected files being labelled with svirt labels. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Modify some existing tests of network-based disks to omit the storage format specification. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
In commit f80eae8c I was too agresive in removing properties of -drive for empty drives. It turns out that qemu actually persists the state of 'readonly' and the throttling information even for the empty drive. Removing 'readonly' thus made qemu open any subsequent images added via the 'change' command as RW which was forbidden by selinux thanks to the restrictive sVirt label for readonly media. Fix this by formating the property again and bump the tests and leave a note detailing why the rest of the properties needs to be skipped. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Cole Robinson 提交于
Missing semicolon at the end of macros can confuse some analyzers (like cppcheck <filename>). VIR_ONCE_GLOBAL_INIT is almost exclusively called without an ending semicolon, but let's standardize on using one like the other macros. Add a dummy struct definition at the end of the macro, so the compiler will require callers to add a semicolon. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
Missing semicolon at the end of macros can confuse some analyzers (like cppcheck <filename>), and we have a mix of semicolon and non-semicolon usage through the code. Let's standardize on using a semicolon for VIR_LOG_INIT calls. Drop the semicolon from the final statement of the macro, so the compiler will require callers to add a semicolon. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
Missing semicolon at the end of macros can confuse some analyzers (like cppcheck <filename>), and we have a mix of semicolon and non-semicolon usage through the code. Let's standardize on using a semicolon for VIR_ENUM_IMPL calls. Move the verify() statement to the end of the macro and drop the semicolon, so the compiler will require callers to add a semicolon. While we are touching these call sites, standardize on putting the closing parenth on its own line, as discussed here: https://www.redhat.com/archives/libvir-list/2019-January/msg00750.htmlReviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
Missing semicolon at the end of macros can confuse some analyzers (like cppcheck <filename>), and we have a mix of semicolon and non-semicolon usage through the code. Let's standardize on using a semicolon for VIR_ENUM_DECL calls. Drop the semicolon from the final statement of the macro, so the compiler will require callers to add a semicolon. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
- 03 2月, 2019 1 次提交
-
-
由 Laine Stump 提交于
Just before pushing the series containing commit 3bba4825 I had added a "return true" to the top of virFirewallDZoneExists() to measure the impact of calling that function once per network during startup. I found that the effect was minimal, but forgot to remove the "return true" before pushing. This unfortunately causes a failure to start networks on systems that have a firewalld version that doesn't support our libvirt zone file (i.e. pretty much everyone). This patch removes the unintended line. Signed-off-by: NLaine Stump <laine@laine.org>
-
- 02 2月, 2019 11 次提交
-
-
由 Roman Bogorodskiy 提交于
Document that using bhyve:commandline is not fully supported and may cause issues. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Roman Bogorodskiy 提交于
When using custom command line arguments, warn that this configuration is not fully supported. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Roman Bogorodskiy 提交于
- Remove ATTRIBUTE_UNUSED for the "buf" argument, it's not unused - Indent fix Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
Since we're setting the zone anyway, it will be useful to allow setting a different (custom) zone for each network. This will be done by adding a "zone" attribute to the "bridge" element, e.g.: ... <bridge name='virbr0' zone='myzone'/> ... If a zone is specified in the config and it can't be honored, this will be an error. Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
This patch restores broken guest network connectivity after a host firewalld is switched to using an nftables backend. It does this by adding libvirt networks' bridge interfaces to the new "libvirt" zone in firewalld. After this patch, the bridge interface of any network created by libvirt (when firewalld is active) will be added to the firewalld zone called "libvirt" if it exists (regardless of the firewalld backend setting). This behavior does *not* depend on whether or not libvirt has installed the libvirt zone file (set with "--with[out]-firewalld-zone" during the configure phase of the package build). If the libvirt zone doesn't exist (either because the package was configured to not install it, or possibly it was installed, but firewalld doesn't support rule priorities, resulting in a parse error), the bridge will remain in firewalld's default zone, which could be innocuous (in the case that the firewalld backend is iptables, guest networking will still function properly with the bridge in the default zone), or it could be disastrous (if the firewalld backend is nftables, we can be assured that guest networking will fail). In order to be unobtrusive in the former case, and informative in the latter, when the libvirt zone doesn't exist we then check the firewalld version to see if it's new enough to support the nftables backend, and then if the backend is actually set to nftables, before logging an error (and failing the net-start operation, since the network couldn't possibly work anyway). When the libvirt zone is used, network behavior is *slightly* different from behavior of previous libvirt. In the past, libvirt network behavior would be affected by the configuration of firewalld's default zone (usually "public"), but now it is affected only by the "libvirt" zone), and thus almost surely warrants a release note for any distro upgrading to libvirt 5.1 or above. Although it's unfortunate that we have to deal with a mandatory behavior change, the architecture of multiple hooks makes it impossible to *not* change behavior in some way, and the new behavior is arguably better (since it will now be possible to manage access to the host from virtual machines vs from public interfaces separately). Creates-and-Resolves: https://bugzilla.redhat.com/1650320 Resolves: https://bugzilla.redhat.com/1638342Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
virFirewallDGetBackend() reports whether firewalld is currently using an iptables or an nftables backend. virFirewallDGetVersion() learns the version of the firewalld running on this system and returns it as 1000000*major + 1000*minor + micro. virFirewallDGetZones() gets a list of all currently active firewalld zones. virFirewallDInterfaceSetZone() sets the firewalld zone of the given interface. virFirewallDZoneExists() can be used to learn whether or not a particular zone is present and active in firewalld. Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
In preparation for adding several other firewalld-specific functions, separate the code that's unique to firewalld from the more-generic "firewall" file. Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
Support for firewalld is a feature that can be selectively enabled or disabled (using --with-firewalld/--without-firewalld), not merely something that must be accounted for in the code if it is present with no exceptions. It is more consistent with other usage in libvirt to use WITH_FIREWALLD rather than HAVE_FIREWALLD. Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 John Ferlan 提交于
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-