According to the dnsmasq manpage, the netmask for IPv4 address ranges
will be auto-deteremined from the interface dnsmasq is listening on,
but it can't do this for IPv6 for some reason - it instead assumes a
network prefix of 64 for all IPv6 address ranges. If this is
incorrect, dnsmasq will refuse to give out an address to clients,
instead logging this message:
dnsmasq-dhcp[2380]: no address range available for DHCPv6 request via virbr0
The solution is for libvirt to add ",$prefix" to all IPv6 dhcp-range
arguments when building the dnsmasq.conf file.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1033739
(cherry picked from commit bf3d9f305ebad9d8abd68e4600d2db996b860e68)
FD passing APIs like CreateXMLWithFiles or OpenGraphicsFD will leak
file descriptors. The user passes in an fd, which is dup()'d in
virNetClientProgramCall. The new fd is what is transfered to the
server virNetClientIOWriteMessage.
Once all the fds have been written though, the parent msg->fds list
is immediately free'd, so the individual fds are never closed.
This closes each FD as its send to the server, so all fds have been
closed by the time msg->fds is free'd.
https://bugzilla.redhat.com/show_bug.cgi?id=1159766
(cherry picked from commit 5ba48584fbc5079c0ddbc9e9a52c96d7bcef0761)
My commit 0d1579572 crashes on a URI without a scheme, like via
'virsh --connect frob'
Add a check on uri->server too while we are at it, and centralize
them all
(cherry picked from commit f1bae376b71ecc712e5d8359382290db1120e13e)
My commit 6879be4 moved the addition of the implicit video device
from the XML parser to the PostParse function, but did not regenerate
all the tests.
(cherry picked from commit 4b35a7155ad6b4346591dd54f03abead2f8c6e1f)
virsh vol-clone is expected to clone a volume within a single
pool; it doesn't work for cloning across pools. Clarify the docs
https://bugzilla.redhat.com/show_bug.cgi?id=1103714
(cherry picked from commit 2f1dc3de4672f4d7aa42bb4984618d382388e0d2)
VIR_ERR_NO_SUPPORT maps to the error string
this function is not supported by the connection driver
and is largely only used for when a driver doesn't have any
implementation for a public API. So its usage with invalid
net-update requests is a bit out of place. Instead use
VIR_ERR_OPERATION_UNSUPPORTED which maps to:
Operation not supported
And is what qemu's hotplug routines use in similar scenarios
(cherry picked from commit cdb4caac81606b8c1bb6ed6f3c0e5d06e4b8b3d6)
This reverts commit 1e9808d3a1e00a7121bae8b163d9c42d441d2ca8.
We shouldn't advertise libvirtd.socket activation, since currently
it means VM/network/... autostart won't work as expected.
We tried to find a middle ground by installing the config file without
an [Install] section, since systemd won't allow .socket to be enabled
without one... or at least it did do that; presently on f24 it allows
activating the socket quite happily. This also caused user confusion[1]
Just remove the socket file. I've filed a new RFE to track coming up
with a solution to the autostart problem[2], we can point users at that
if there's more confusion:
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1279348
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1326136
(cherry picked from commit 3b9100a4d255fdb5f731fcfa49326746d371894a)
It isn't implemented and does not work:
error: internal error: guest failed to start: /usr/lib/libvirt/libvirt_lxc: option '--veth' requires an argument
syntax: /usr/lib/libvirt/libvirt_lxc [OPTIONS] ...
We previously threw an explicit error, but this changed in
22cff52a2b8e06c913b1f97767e5d390fb17fc3b , which I suspect was
untested for LXC
(cherry picked from commit 27f2b74782e15c528079c8a93e5ccf216fe7b22c)
While working on the tests for the secret initialization vector, I found
that the existing iSCSI tests were lacking in how they defined the IQN.
Many had IQN's of just 'iqn.1992-01.com.example' for one disk while using
'iqn.1992-01.com.example/1' for the second disk (same for hostdevs - guess
how they were copied/generated).
Typically (and documented this way), IQN's would include be of the form
'iqn.1992-01.com.example:storage/1' indicating an IQN using "storage" for
naming authority specific string and "/1" for the iSCSI LUN.
So modify the input XML's to use the more proper format - this of course
has a ripple effect on the output XML and the args.
Also note that the "%3A" is generated by the virURIFormat/xmlSaveUri
to represent the colon.
Signed-off-by: John Ferlan <jferlan@redhat.com>
(cherry picked from commit dd1400280eb0fcd38906b17a9341ac9fe6317498)
virTypedParamsValidate currently uses an index based check to find
duplicate parameters. This check does not work. Consider the following
simple example:
We have only 2 keys
A (multiples allowed)
B (multiples NOT allowed)
We are given the following list of parameters to check:
A
A
B
If you work through the validation loop you will see that our last iteration
through the loop has i=2 and j=1. In this case, i > j and keys[j].value.i will
indicate that multiples are not allowed. Both conditionals are satisfied so
an incorrect error will be given: "parameter '%s' occurs multiple times"
This patch replaces the index based check with code that remembers
the name of the last parameter seen and only triggers the error case if
the current parameter name equals the last one. This works because the
list is sorted and duplicate parameters will be grouped together.
In reality, we hit this bug while using selective block migration to migrate
a guest with 5 disks. 5 was apparently just the right number to push i > j
and hit this bug.
virsh migrate --live guestname --copy-storage-all
--migrate-disks vdb,vdc,vdd,vde,vdf
qemu+ssh://dsthost/system
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: Eric Farman <farman@linux.vnet.ibm.com>
(cherry picked from commit 0e570a6acc13ebbca913e69026f1468daf28240f)
Commit id '4b75237f' seems to have triggered Coverity into finding
at least one memory leak in xen_xl.c for error path for cleanup where
the listenAddr would be leaked. Reviewing other callers, it seems that
qemu_parse_command.c would have the same issue, so just it too.
(cherry picked from commit 727a3c5860ef5e1fb8878da9d44c6e5e33a4f4ae)
To ensure the libvirt libxl driver will build with future versions
of Xen where the libxl API may change in incompatible ways,
explicitly use LIBXL_API_VERSION 0x040200. The libxl driver
does use new libxl APIs that have been added since Xen 4.2, but
currently it does not make use of any changes made to existing
APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity.
The version can be bumped if/when the libxl driver consumes the
changed APIs.
Further details can be found in the following discussion thread
https://www.redhat.com/archives/libvir-list/2016-April/msg00178.html
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
(cherry picked from commit e744065679ccba8471d28b2cf6e93f443cd20c8c)
In a few places in libvirt we busy-wait for events, for example qemu
creating a monitor socket. This is problematic because:
- We need to choose a sufficiently small polling period so that
libvirt doesn't add unnecessary delays.
- We need to choose a sufficiently large polling period so that
the effect of busy-waiting doesn't affect the system.
The solution to this conflict is to use an exponential backoff.
This patch adds two functions to hide the details, and modifies a few
places where we currently busy-wait.
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
(cherry picked from commit beaa447a2982bc78adb26c183560d0ee566c1268)
Move some API specific documentation out of -docs package and into
-devel, and some end user docs out of -devel and into -docs, then
drop the -devel dep on -docs. This is more in line with the suggested
Fedora guidelines.
https://bugzilla.redhat.com/show_bug.cgi?id=1310155
(cherry picked from commit feffcc03a0d3690dcffd860682dcbaa61d726b39)
Take setlocale/gettext error handling pattern from tools/virsh-*
and use it for all standalone binaries via a new shared
virGettextInitialize routine. The virsh* pattern differed slightly
from other callers. All users now consistently:
* Ignore setlocale errors. virsh has done this forever, presumably for
good reason. This has been partially responsible for some bug reports:
https://bugzilla.redhat.com/show_bug.cgi?id=1312688https://bugzilla.redhat.com/show_bug.cgi?id=1026514https://bugzilla.redhat.com/show_bug.cgi?id=1016158
* Report the failed function name
* Report strerror
(cherry picked from commit e7db22781071a39668276a395fb547c0dd90875d)
We use device-mapper to enumerate all dm devices, and filter out
the list of multipath devices by checking the target_type string
name. The code however cancels all scanning if we encounter
target_type=NULL
I don't know how to reproduce that situation, but a user was hitting
it in their setup, and inspecting the lvm2/device-mapper code shows
many places where !target_type is explicitly ignored and processing
continues on to the next device. So I think we should do the same
https://bugzilla.redhat.com/show_bug.cgi?id=1069317
(cherry picked from commit 8f8c0feb113420625f15b7f1e17bfd719c977eeb)
The watchdog cli refactoring in 4666b762 dropped the temporary variable
we use to convert to action=dump to action=pause for the qemu cli, and
stored the converted value in the domain structure. Our other watchdog
handling code then treated it as though the user requested action=pause,
which broke action=dump handling.
Revive the temporary variable to fix things.
(cherry picked from commit a91177c8f7b432e67d2e232650d7debbbfc694da)
Trying to reload/SIGUSR1 virtlogd or virtlockd fails with:
error : virNetDaemonRun:747 : internal error: Not all servers restored, cannot run server
Commit 252610f7 changed the daemon state json to allow tracking
multiple servers. However it missed clearing dmn->srvObject after
the json is empty, like the previous code paths handled. Later on in
virNewDaemonRun, dmn->srvObject is expected to be empty otherwise we
throw the above error.
https://bugzilla.redhat.com/show_bug.cgi?id=1311013
(cherry picked from commit 9b69f02243f2abec4170576dfe28f8a4bb398b4e)
Commit 119cd06 started setting the primary bool for the first
user-specified video even if user omitted the 'primary' attribute.
However this was done before the addition of the implicit device.
This broke startup of transient qemu domains with no <video>:
https://bugzilla.redhat.com/show_bug.cgi?id=1325757
Move this default to virDomainDefPostParseInternal,
after the addition of the implicit video device, to catch the implicit
video as well.
(cherry picked from commit 6d8b6d2847f31a3d7a234536c12b8feca751a02f)
Commit c3bd0019c0e3 forgot to cleanup after itself.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1325043
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 16b41728b59a7188f643937303e3aec4c299a980)
The check is supposed to stop users from trying to compile
virt-login-shell on Windows by erroring out during the
configure phase; however, there are two flaws in it:
* the value of "x$with_win" is compared to "yes" instead
of "xyes" (note the "x" in the first string)
* "test" is not being used, so the script will actually
try to run a command called "x$with_win" instead of
performing string comparison
This patch fixes both issues.
(cherry picked from commit ccf58bd72a426f34481787af694d6eae78b4e64e)
FreeBSD lacks ENODATA, and viruuid.c redefines it to EIO, but it's not
actually using it. On the other hand, we have virrandom.c that's using
ENODATA. So make this re-definition common by moving it to internal.h,
so all the current and possible future users don't need to care about
that.
(cherry picked from commit edc028d122a45b09988dae6d93510adbd9f5c3e4)
In the latest libxenlight code, libxl_domain_create_restore accepts a
new argument. Update libvirt's libxl driver for that. Use the macro
provided by libxenlight to detect which version should be used.
The new parameter (send_back_fd) is set to -1 because libvirt provides
no such fd.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Message-id: 1459866012-27081-1-git-send-email-wei.liu2@citrix.com
(cherry picked from commit 216650f14b35ad11a45505405347f8027bc294d7)
The new perf code didn't bother to clear a pointer in 'priv' causing a
double free or other memory corruption goodness if a VM failed to start.
Clear the pointer after freeing the memory.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1324757
(cherry picked from commit 03e8d5fb54c7c897225ed9ea56d83b894930f144)
For device hotplug, the new alias ID needs to be checked in the list
rather than using the count of devices. Unplugging a device that is not
last in the array will make further hotplug impossible due to alias
collision.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1324551
(cherry picked from commit be6e92f541ab27019de530f1f08ec9b2912765a9)
There is a LIBVIRT_ADMIN_DEFAULT_URI environment variable
which is honored by virAdmConnectOpen and documented
in the virt-admin man page.
LIBVIRT_DEFAULT_ADMIN_URI is undocumented and this is its
only occurrence.
(cherry picked from commit df8964308ed3d7eeb4f15f26e17993b5f7af1c51)
Postpone filling out the default connection in ctl->connname
after calling virshInit.
This allows printing help without a connection to the daemon.
(cherry picked from commit c0726e0708762e571a7883cb0558cfec32459669)
fdstream.c: In function 'virFDStreamWrite':
fdstream.c:390:29: error: logical 'or' of equal expressions [-Werror=logical-op]
if (errno == EAGAIN || errno == EWOULDBLOCK) {
^~
Fedora rawhide now uses gcc 6.0 and there is a bug with -Wlogical-op
producing false warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Use GCC pragma push/pop and ignore -Wlogical-op for GCC that supports
push/pop pragma and also has this bug.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
(cherry picked from commit d713a6b120904c488170e7920c482b2fade70ae1)
Some places already check for "virt-" prefix as well as plain "virt".
virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices
having assigned the same unnumbered "pci" alias.
Add a test for the "virt-2.6" machine type which also omits the
<model type='virtio'/> in <interface>, to check if
qemuDomainDefaultNetModel works too.
https://bugzilla.redhat.com/show_bug.cgi?id=1325085
(cherry picked from commit f06ca25d235433f9139cbfb3d5d9eae7409156b9)
Commit id '3992ff14' added the prototype for networkGetActualType
with 1 parameter, but added 2 ATTRIBUTE_NONNULL's (assume from a
cut-n-paste), just remove (2).
Commit d77ffb6876 added not only reporting of the PCI header type, but
also parsing of that information. However, because there was no parsing
done for the other sub-PCI capabilities, if there was any other
capability then a valid header type name (like phys_function or
virt_functions) the parsing would fail. This prevented passing node
device XMLs that we generated into our own functions when dealing with,
e.g. with SRIOV cards.
Instead of reworking the whole parsing, just fix this one occurence and
remove a test for it for the time being. Future patches will deal with
the rest.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Starting with commit f8e712fe, if you start a domain that has an
<interface type='hostdev' (or that has <interface type='network'>
where the network is a pool of devices for hostdev assignment), when
you later try to add *another* interface (of any kind) with hotplug,
the function qemuAssignDeviceNetAlias() fails as soon as it sees a
"hostdevN" alias in the list of interfaces), causing the attach to
fail.
This is because (starting with f8e712fe) the device alias names are
assigned during the new function qemuProcessPrepareDomain(), which is
called *before* networkAllocateActualDevice() (which is called from
qemuProcessPrepareHost(), which is called from
qemuProcessLaunch()). Prior to that commit,
networkAllocateActualDevice() was called first.
The problem with this is that the alias for interfaces that are really
a hostdev (<interface type='hostdev'>) is of the form "hostdevN" (just
like other hostdevs), while other interfaces are "netN". But if you
don't know that the interface is going to be a hostdev at the time you
assign the alias name, you can't name it differently. (As far as I've
seen so far, the change in name by itself wouldn't have been a problem
(other than just an outwardly noticeable change in behavior) except
for the abovementioned failure to attach/detach new interfaces.
Rather than take the chance that there may be other not-yet-revealed
problems associated with changing the alias name, this patch changes
the way that aliases are assigned to restore the old behavior.
Old: In the past, assigning an alias to an interface was skipped if it
was seen that the interface was type='hostdev' - we knew that the
hostdev part of the interface was also in the list of hostdevs (that's
part of what happens in networkAllocateActualDevice()) and it would be
assigned when all the other hostdev aliases were assigned.
New: When assigning an alias to an interface, we haven't yet called
networkAllocateActualDevice() to construct the hostdev part of the
interface, so we can't just wait for the loop that creates aliases for
all the hostdevs (there's nothing on that list for this device
yet!). Instead we handle it immediately in the loop creating interface
aliases, by calling the new function networkGetActualType() to
determine if it is going to be hostdev, and if so calling
qemuAssignDeviceHostdevAlias() instead.
Some adjustments have to be made to both
qemuAssignDeviceHostdevAlias() and to qemuAssignDeviceNetAlias() to
accommodate this. In both of them, an error return from
qemuDomainDeviceAliasIndex() is no longer considered an error; instead
it's just ignored (because it almost certainly means that the alias
string for the device was "net" when we expected "hostdev" or vice
versa). in qemuAssignDeviceHostdevAlias() we have to look at all
interface aliases for hostdevN in addition to looking at all hostdev
aliases (this wasn't necessary in the past, because both the interface
entry and the hostdev entry for the device already pointed at the
device info; no longer the case since the hostdev entry hasn't yet
been setup).
Fortunately the buggy behavior hasn't yet been in any official release
of libvirt.
In certain cases, we need to assign a hostdevN-style alias in a case
when we don't have a virDomainHostdevDefPtr (instead we have a
virDomainNetDefPtr). Since qemuAssignDeviceHostdevAlias() doesn't use
anything in the virDomainHostdevDef except the alias string itself
anyway, this patch just changes the arguments to pass a pointer to the
alias pointer instead.
There are times when it's necessary to learn the actual type of a
network connection before any resources have been allocated
(e.g. during qemuProcessPrepareDomain()), but in the past it was
necessary to call networkAllocateActualDevice() in order to have the
actual type filled in.
This new function returns the type of network that *will be* setup
once it actually happens, but without making any changes on the host.
The paths have the domain ID in them. Without cleaning them, they would
contain the same ID even after multiple restarts. That could cause
various problems, e.g. with access.
Add function qemuDomainClearPrivatePaths() for this as a counterpart of
qemuDomainSetPrivatePaths().
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
