- 02 2月, 2019 12 次提交
-
-
由 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>
-
由 Erik Skultety 提交于
Signed-off-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
- 01 2月, 2019 16 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1657468 Commit be1bb6c9 changed the way volumes were stored from a forward linked list to a hash table. In doing so, it required that each vol object would have 3 unique values as keys into tables - key, name, and path. Due to how vHBA/NPIV LUNs are created/used this resulted in a failure to utilize all the LUN's found during processing. During virStorageBackendSCSINewLun processing fetch the key (or serial value) for NPIV LUN's using virStorageFileGetNPIVKey which will formulate a more unique key based on the serial value and the port for the LUN. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 John Ferlan 提交于
The vHBA/NPIV LUNs created via the udev processing of the VPORT_CREATE command end up using the same serial value as seen/generated by the /lib/udev/scsi_id as returned during virStorageFileGetSCSIKey. Therefore, in order to generate a unique enough key to be used when adding the LUN as a volume during virStoragePoolObjAddVol a more unique key needs to be generated for an NPIV volume. The problem is illustrated by the following example, where scsi_host5 is a vHBA used with the following LUNs: $ lsscsi -tg ... [5:0:4:0] disk fc:0x5006016844602198,0x101f00 /dev/sdh /dev/sg23 [5:0:5:0] disk fc:0x5006016044602198,0x102000 /dev/sdi /dev/sg24 ... Calling virStorageFileGetSCSIKey would return: /lib/udev/scsi_id --device /dev/sdh --whitelisted --replace-whitespace /dev/sdh 350060160c460219850060160c4602198 /lib/udev/scsi_id --device /dev/sdh --whitelisted --replace-whitespace /dev/sdi 350060160c460219850060160c4602198 Note that althrough /dev/sdh and /dev/sdi are separate LUNs, they end up with the same serial number used for the vol->key value. When virStoragePoolFCRefreshThread calls virStoragePoolObjAddVol the second LUN fails to be added with the following message getting logged: virHashAddOrUpdateEntry:341 : internal error: Duplicate key To resolve this, virStorageFileGetNPIVKey will use a similar call sequence as virStorageFileGetSCSIKey, except that it will add the "--export" option to the call. This results in more detailed output which needs to be parsed in order to formulate a unique enough key to be used. In order to be unique enough, the returned value will concatenate the target port as returned in the "ID_TARGET_PORT" field from the command to the "ID_SERIAL" value. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 John Ferlan 提交于
Alter the code to use the virStorageFileGetSCSIKey helper to fetch the unique key for the SCSI disk. Alter the logic to follow the former code which would return a duplicate of @dev when either the virCommandRun succeeded, but returned an empty string or when WITH_UDEV was not true. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 John Ferlan 提交于
Alter the "real" code to return -2 on virCommandRun failure. Alter the comments and function header to describe the function and its returns. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1503284 The way we currently start qemu from CPU affinity POV is as follows: 1) the child process is set affinity to all online CPUs (unless some vcpu pinning was given in the domain XML) 2) Once qemu is running, cpuset cgroup is configured taking memory pinning into account Problem is that we let qemu allocate its memory just anywhere in 1) and then rely in 2) to be able to move the memory to configured NUMA nodes. This might not be always possible (e.g. qemu might lock some parts of its memory) and is very suboptimal (copying large memory between NUMA nodes takes significant amount of time). The solution is to set affinity to one of (in priority order): - The CPUs associated with NUMA memory affinity mask - The CPUs associated with emulator pinning - All online host CPUs Later (once QEMU has allocated its memory) we then change this again to (again in priority order): - The CPUs associated with emulator pinning - The CPUs returned by numad - The CPUs associated with vCPU pinning - All online host CPUs Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Erik Skultety 提交于
This is mainly about /dev/sev and its default permissions 0600. Of course, rule of 'tinfoil' would be that we can't trust anything, but the probing code in QEMU is considered safe from security's perspective + we can't create an udev rule for this at the moment, because ioctls and file system permissions aren't cross-checked in kernel and therefore a user with read permissions could issue a 'privileged' operation on SEV which is currently only limited to root. https://bugzilla.redhat.com/show_bug.cgi?id=1665400Signed-off-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Erik Skultety 提交于
The default permissions (0600 root:root) are of no use to the qemu process so we need to change the owner to qemu iff running with namespaces. Signed-off-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Erik Skultety 提交于
Instead of exposing /dev/sev to every domain, do it selectively. Signed-off-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Erik Skultety 提交于
SEV has a limit on number of concurrent guests. From security POV we should only expose resources (any resources for that matter) to domains that truly need them. Signed-off-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Erik Skultety 提交于
We should not give domains access to something they don't necessarily need by default. Remove it from the qemu driver docs too. Signed-off-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
Commit fb0d0d6c added capabilities data and updated qemucapabilitiestest but forgot to update qemucaps2xmltest at the same time. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
This shows users can now use PCI for RISC-V guests, as long as they opt into it by manually assigning addresses. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
virtio-mmio is still used by default, so if PCI is desired it's necessary to explicitly opt-in by adding an appropriate <address type='pci' domain='0x0000' ... /> element to the corresponding device. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Casey Callendrello 提交于
This adds an additional directive to the dnsmasq configuration file that notifies clients via dhcp about the link's MTU. Guests can then choose adjust their link accordingly. Signed-off-by: NCasey Callendrello <cdc@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 31 1月, 2019 12 次提交
-
-
由 Ján Tomko 提交于
This test relies on namespace support, which is only compiled in if we have the 'fs' and 'netfs' backends. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Ján Tomko 提交于
Instead of repeating the same platform for every test, set it once, since we do the same tests with the same input for all platforms, it's just the output that differs. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Ján Tomko 提交于
Instead of a pair of bools. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Erik Skultety 提交于
This was a left-over that should have been dropped along the change in qemu.conf. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 John Ferlan 提交于
Only run the pool-netfs-ns-mountopts if built WITH_STORAGE_FS and only run pool-rbd-ns-configopts if built with WITH_STORAGE_RBD since the namespace support is only enabled if the pool is enabled. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Daniel P. Berrangé 提交于
The 'qemu' binary used to provide the i386 emulator until it was renamed to qemu-system-i386 in QEMU 1.0. Since we don't support such old versions we don't need to check for 'qemu' when probing capabilities. Reviewed-by: NErik Skultety <eskultet@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The custom namespaces were originally registered against the storage pool source struct, but during review this was changed to the top level storage pool struct. The namespace URIs were not updated to match, so had a redundant '/source' component. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Krempa 提交于
Some clients poll virDomainGetBlockJobInfo rather than wait for the VIR_DOMAIN_BLOCK_JOB_READY event. In some cases qemu can get to 100% and still not reach the synchronised phase. Initiating a pivot in that case will fail. Given that computers are interacting here, the error that the job can't be finalized yet is not handled very well by those specific implementations. Our docs now correctly state to use the event. We already do a similar output adjustment in case when the progress is not available from qemu as in that case we'd report 0 out of 0, which some apps also incorrectly considered as 100% complete. In this case we subtract 1 from the progress if the ready state is not signalled by qemu if the progress was at 100% otherwise. Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Peter Krempa 提交于
Bump the width to 70em while keeping a maximum width of 95% to allow for some border. Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Peter Krempa 提交于
Big number itself does not make much sense in some cases. Format the bitshift format as well. Changes our web page docs from: VIR_MIGRATE_POSTCOPY = 32768 : Setting the VIR_MIGRATE_POSTCOPY... VIR_MIGRATE_TLS = 65536 : Setting the VIR_MIGRATE_TLS flag... to: VIR_MIGRATE_POSTCOPY = 32768 (0x8000; 1 << 15) : Setting the VIR_MIGRATE_POSTCOPY... VIR_MIGRATE_TLS = 65536 (0x10000; 1 << 16) : Setting the VIR_MIGRATE_TLS flag... Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Daniel P. Berrangé 提交于
A copy+paste mistaken meant the wrong enum -> string convertor function was used for the error when an incorrect feature capability was used. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
PEP 8 says: "Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators." There are potentially semantics differences, though in the case of this libvirt code its merely a style change: http://jaredgrubb.blogspot.com/2009/04/python-is-none-vs-none.htmlReviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-