https://bugzilla.redhat.com/show_bug.cgi?id=1459091
We try to get the last element of the passed path by calling
strrch(path, '/'). However, the pointer that strrchr() returns
points at the slash, We want string that starts right after that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1459091
Currently, we are querying for vhostuser interface name in post
parse callback. At that time interface might not yet exist.
However, it has to exist when starting domain. Therefore it makes
more sense to query its name at that point. This partially
reverts 57b5e27.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
While reworking client side of streams, I had to postpone payload
decoding so that stream holes and stream data can be
distinguished in virNetClientStreamRecvPacket. That's merely what
18944b7aea does. However, I accidentally removed one important
bit: when server sends us an empty STREAM packet (with no
payload) - meaning end of stream - st->incomingEOF flag needs to
be set. It used to be before I touched the code. After I removed
it, virNetClientStreamRecvPacket will try to fetch more data from
the stream, but it will never come.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
In 9cb891141c we've introduced some logic to clearing suggested
macvtap/macvlan ifnames. The logic consists of comparing ifname
string with strings that libvirt would generate. However, due to
a typo only VIR_NET_GENERATED_MACVTAP_PREFIX was compared. Twice.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When adding the aliased serial stub console, the structure wasn't
properly allocated (VIR_ALLOC instead of virDomainChrDefNew) which then
resulted in SIGSEGV in virDomainChrSourceIsEqual during a serial device
coldplug.
https://bugzilla.redhat.com/show_bug.cgi?id=1434278
Signed-off-by: Erik Skultety <eskultet@redhat.com>
If QEMU is new enough and we have the live updated CPU definition in
either save or migration cookie, we can use it to enforce ABI. The
original guest CPU from domain XML will be stored in private data.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Since the domain XML saved in a snapshot or saved image uses the
original guest CPU definition but we still want to enforce ABI when
restoring the domain if libvirt and QEMU are new enough, we save the
live updated CPU definition in a save cookie.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Since the domain XML send during migration uses the original guest CPU
definition but we still want the destination to enforce ABI if it is new
enough, we send the live updated CPU definition in a migration cookie.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When persistent migration of a transient domain is requested but no
custom XML is passed to the migration API we would just let the
destination daemon make a persistent definition from the live definition
itself. This is not a problem now, but once the destination daemon
starts replacing the original CPU definition with the one from migration
cookie before starting a domain, it would need to add more ugly hacks to
reverse the operation. Let's just always send the persistent definition
in the cookie to make things a bit cleaner.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The destination host may not be able to start a domain using the live
updated CPU definition because either libvirt or QEMU may not be new
enough. Thus we need to send the original guest CPU definition.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When starting a domain we update the guest CPU definition to match what
QEMU actually provided (since it is allowed to add or removed some
features unless check='full' is specified). Let's store the original CPU
in domain private data so that we can use it to provide a backward
compatible domain XML.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The following patches will add an actual content in the cookie and use
the data when restoring a domain.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This patch implements a new save cookie object and callbacks for qemu
driver. The actual useful content will be added in the object later.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
virDomainXMLOption gains driver specific callbacks for parsing and
formatting save cookies.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The code will be used by snapshots and domain save/restore code to store
additional data for a saved running domain. It is analogous to migration
cookies, but simple and one way only.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The new structure encapsulates save image header and associated data
(domain XML).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The function is now called virQEMUSaveDataWrite and it is now doing
everything it needs to save both the save image header and domain XML to
a file. Be it a new file or an existing file in which a user wants to
change the domain XML.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The function is supposed to update the save image header after a
successful migration to the save image file.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This is a preparation for creating a new virQEMUSaveData structure which
will encapsulate all save image header data.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Since virQEMUSaveHeader will be followed by more than just domain XML,
the old name would be confusing as it was designed to describe the
length of all data following the save image header.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This will be used later when a save cookie will become part of the
snapshot XML using new driver specific parser/formatter functions.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The function will be used in paths where mismatching CPU defs are not an
error.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Allow starting the block-copy job for a persistent domain if a user
declares by using a flag that the job will not be recovered if the VM is
switched off while the job is active.
This allows to use the block-copy job with persistent VMs under the same
conditions as would apply to transient domains.
Without this patch libvirt would just report the operation of a
completed job as "unknown" instead of "incoming migration".
https://bugzilla.redhat.com/show_bug.cgi?id=1457052
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Now that we have a bit more control, let's convert our object into
a lockable object and let that magic handle the create and lock/unlock.
This commit also introduces virInterfaceObjEndAPI in order to handle the
lock unlock and object unref in one call for consumers returning a NULL
obj upon return. This removes the need for virInterfaceObj{Lock|Unlock}
external API's.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Move the consumption of @def in virInterfaceObjNew and then handle that
in the error path of virInterfaceObjListAssignDef since it's caller expects
to need to free @def when NULL is returned and so would virInterfaceObjFree.
Signed-off-by: John Ferlan <jferlan@redhat.com>
vCPU ordering information would not be updated if a vCPU emerged or
disappeared during the time libvirtd is not running. This allowed to
create invalid configuration like:
[...]
<vcpu id='56' enabled='yes' hotpluggable='yes' order='57'/>
<vcpu id='57' enabled='yes' hotpluggable='yes' order='58'/>
<vcpu id='58' enabled='yes' hotpluggable='yes'/>
Call the function that records the information on reconnect.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1451251
There's a problem with current streams after I switched them from
iohelper to thread implementation. Previously, iohelper made sure
not to exceed specified @length resulting in the pipe EOF
appearing at the exact right moment (the pipe was used to tunnel
the data from the iohelper to the daemon). Anyway, when switching
to thread I had to write the I/O code from scratch. Whilst doing
that I took an inspiration from the iohelper code, but since the
usage of pipe switched to slightly different meaning, there was
no 1:1 relationship between the codes.
Moreover, after introducing VIR_FDSTREAM_MSG_TYPE_HOLE, the
condition that should made sure we won't exceed @length was
completely wrong.
The fix is to:
a) account for holes for @length
b) cap not just data sections but holes too (if @length would be
exceeded)
For this purpose, the condition needs to be brought closer to the
code that handles holes and data sections.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Make the decision based on the usage of childBuf buffer.
This fixes the oddity in the test case introduced by commit c1c4d0d
where we would format an empty pair tag.
We need to decide whether to format <controller> as a single tag
or if it has any subelements.
Rewrite the function to use a separate buffer for subelements,
to make adding new options easier.
After some discussion on and off the linux-audit mailing list, we
should use different fields for the audit messages.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1218603
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
They do the same thing with only one difference. Let's put them
together (like we already do with virFDStreamCloseInt) so that future
changes don't miss one of the implementations. Also to clean up the
code.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1450349
Problem is, qemu fails to load guest memory image if these
attribute change on migration/restore from an image.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
While checking for ABI stability, drivers might pose additional
checks that are not valid for general case. For instance, qemu
driver might check some memory backing attributes because of how
qemu works. But those attributes may work well in other drivers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
It was only ever used in node_device_hal.c which really never used it
anyway since the NODE_DEV_UDI was never referenced. Remove free_udi()
and @privData as well as the references to obj->privateData & obj->privateFree.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In preparation for privatizing the virNodeDeviceObj - create an accessor
for the @def field and then use it for various callers.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Create nodeDeviceObjFindByName which will perform the corresponding
virNodeDeviceObjFindByName call for various node_device_driver callers
rather than having the same repetitive code.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than taking an virNodeDeviceObjPtr and dereffing the obj->def,
just pass the def.
Also check for an error in the function to have the calling function goto
cleanup on error.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Alter the node_device_driver source and prototypes to follow more
recent code style guidelines w/r/t spacing between functions, format
of the function, and the prototype definitions.
While the new names for nodeDeviceUpdateCaps, nodeDeviceUpdateDriverName,
and nodeDeviceGetTime don't follow exactly w/r/t a "vir" prefix, they
do follow other driver nomenclature style.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In order to ensure that whenever something is added to virNodeDevCapType
that both functions are considered for processing of a new capability,
change the if-then-else construct into a switch statement.
Signed-off-by: John Ferlan <jferlan@redhat.com>
When searching for an NPIV capable fc_host, not only does there need to
be an "fc_host" capability with the specified wwnn/wwpn or fabric_wwn,
but that scsi_host must be vport capable; otherwise, one could end up
picking an exising vHBA/NPIV which wouldn't be good.
Currently not a problem since scsi_hosts are in an as found forward linked
list and the vport capable scsi_hosts will always appear before a vHBA by
definition. However, in the near term future a hash table will be used to
lookup the devices and that could cause problems for these algorithms.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Alter the algorithm to return a list of matching names rather than a
list of match virInterfaceObjPtr which are then just dereferenced
extracting the def->name and def->mac. Since the def->mac would be
the same as the passed @mac, just return a list of names and as long
as there's only one, extract the [0] entry from the passed list.
Also alter the error message on failure to include the mac that wasn't
found.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Move the structs into virinterfaceobj.c, create necessary accessors, and
initializers.
This also includes reworking virInterfaceObjListClone to handle receiving
a source interfaces list pointer, creating the destination interfaces object,
and copying everything from source into dest.
Signed-off-by: John Ferlan <jferlan@redhat.com>
We're about to make the obj much more private, so make it easier to
see future changes which will require accessors for the obj->def
This also includes modifying some interfaces->objs[i]->X references to be
obj = interfaces->objs[i]; and then def = obj->def
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than using goto cleanup on object find failure and having cleanup
need to check if the obj was present before unlocking, just return immediately.
Signed-off-by: John Ferlan <jferlan@redhat.com>
qemuDomainGetBlockInfo would error out if qemu did not report
'wr_highest_offset'. This usually does not happen, but can happen
briefly during active layer block commit. There's no need to report the
error, we can simply report that the disk is fully alocated at that
point.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1452045
The host address or the socket path have already been checked at the
begining of the function virStorageSourceParseNBDColonString(). So,
when the parameter is not a unix socket, there is no reason to check
the address again because if it does not exists, the logic will fail
in the first IF conditional.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
VIR_STRDUP returns -1 if the string copy was not successful. So, the
current comparison/logic is throwing an error when VIR_STRDUP() returns
1. Only when source is NULL, it is considering as a success which is
not right.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
In 48d9e6cdcc and friends we've allowed users to back guest
memory by a file inside the host. And in order to keep things
manageable the memory_backing_dir variable was introduced to
qemu.conf to specify the directory where the files are kept.
However, libvirt's policy is that directories are created on
domain startup if they don't exist. We've missed this one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
commit a8eba5036 added further checking of the guest shutdown cause, but
this enhancement is available since qemu 2.10, causing a crash because
of a NULL pointer dereference on older qemus.
Thread 1 "libvirtd" received signal SIGSEGV, Segmentation fault.
0x00007ffff72441af in virJSONValueObjectGet (object=0x0,
key=0x7fffd5ef11bf "guest")
at util/virjson.c:769
769 if (object->type != VIR_JSON_TYPE_OBJECT)
(gdb) bt
0 in virJSONValueObjectGet
1 in virJSONValueObjectGetBoolean
2 in qemuMonitorJSONHandleShutdown
3 in qemuMonitorJSONIOProcessEvent
4 in qemuMonitorJSONIOProcessLine
5 in qemuMonitorJSONIOProcess
6 in qemuMonitorIOProcess
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Callers expect the return value to be the total number of vcpus in the
host (including offline vcpus). The refactor in c67e04e25f
broke this assumption by using virHostCPUGetOnlineBitmap which only
creates a bitmap long enough to hold the last online vcpu.
Report the full number of host vcpus by returning value from
virHostCPUGetCount().
Signed-off-by: Nitesh Konkar <nitkon12@linux.vnet.ibm.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
When a number of SRIOV VFs (up to 128 on Intel XL710) is created:
for i in `seq 0 1`; do
echo 63 > /sys/class/net/<interface>/device/sriov_numvfs
done
libvirtd will then report "udev_monitor_receive_device returned NULL"
error because the netlink socket buffer is not big enough (using GDB on
libudev confirmed this with ENOBUFFS) and thus some udev events were
dropped. This results in some devices being missing in the nodedev-list
output. This patch overrides the system's rmem_max limit but for that,
we need to make sure we've got root privileges.
https://bugzilla.redhat.com/show_bug.cgi?id=1450960
Signed-off-by: ning.bo <ning.bo9@zte.com.cn>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The @cpus is allocated by virFileReadValueBitmap() but never
freed:
==21274== 40 (32 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 808 of 1,004
==21274== at 0x4C2E080: calloc (vg_replace_malloc.c:711)
==21274== by 0x54BA561: virAlloc (viralloc.c:144)
==21274== by 0x54BC604: virBitmapNewEmpty (virbitmap.c:126)
==21274== by 0x54BD059: virBitmapParseUnlimited (virbitmap.c:570)
==21274== by 0x54EECE9: virFileReadValueBitmap (virfile.c:4113)
==21274== by 0x5563132: virCapabilitiesInitCaches (capabilities.c:1548)
==21274== by 0x2BB86E59: virQEMUCapsInit (qemu_capabilities.c:1132)
==21274== by 0x2BBEC067: virQEMUDriverCreateCapabilities (qemu_conf.c:928)
==21274== by 0x2BC3DEAA: qemuStateInitialize (qemu_driver.c:845)
==21274== by 0x5625AAC: virStateInitialize (libvirt.c:770)
==21274== by 0x124519: daemonRunStateInit (libvirtd.c:881)
==21274== by 0x554C927: virThreadHelper (virthread.c:206)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Similar to scsi_host and fc_host, there is a relation between a
scsi_target and its transport specific fc_remote_port. Let's expose this
relation and relevant information behind it.
An example for a virsh nodedev-dumpxml:
virsh # nodedev-dumpxml scsi_target0_0_0
<device>
<name>scsi_target0_0_0</name>
<path>/sys/devices/[...]/host0/rport-0:0-0/target0:0:0</path>
<parent>scsi_host0</parent>
<capability type='scsi_target'>
<target>target0:0:0</target>
<capability type='fc_remote_port'>
<rport>rport-0:0-0</rport>
<wwpn>0x9d73bc45f0e21a86</wwpn>
</capability>
</capability>
</device>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
We will need some convenient helper functions for managing sysfs-entries
for fibre channel-backed devices. Let's implement them and make them
available in the private API.
Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Now that the node_device driver is aware of CCW devices, let's hook up
virsh so that we can filter them properly.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Make CCW devices available to the node_device driver. The devices are
already seen by udev so let's implement necessary code for detecting
them properly.
Topologically, CCW devices are similar to PCI devices, e.g.:
+- ccw_0_0_1a2b
|
+- scsi_host0
|
+- scsi_target0_0_0
|
+- scsi_0_0_0_0
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Unlock @obj in case of an error too.
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Since the switch statement is already using the deref'd @cap variable
and the VIR_NODE_DEV_CAP_NET case uses it, the SCSI_HOST and PCI_DEV
cases may as well use it too.
Suggested-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
QEMU will likely report the details of it shutting down, particularly
whether the shutdown was initiated by the guest or host. We should
forward that information along, at least for shutdown events. Reset
has that as well, however that is not a lifecycle event and would add
extra constants that might not be used. It can be added later on.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1384007
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
The number of records that virConnectGetAllDomainStats can return per
domain is currently limited to 4096. This is quite low -- for
example, a single guest with ~320 disks will hit this limit. This
increases the limit to make it much larger. Note that
VIR_NET_MESSAGE_MAX still protects the total message size in the case
where there are many domains and many disks per domain.
I tested this using a guest with 500 disks with no issues.
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1440683
When increasing the buffer size up to VIR_NET_MESSAGE_MAX, we
currently quadruple it each time. This unfortunately means that we
cannot allow certain buffer sizes -- for example the current
VIR_NET_MESSAGE_MAX == 33554432 can never be "hit" since ‘newlen’
jumps from 16MB to 64MB.
Instead of quadrupling, double it each time.
Thanks: Daniel Berrange.
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Commit 4337bc57be introduced code that would in certain error paths
unref the last reference of a pointer, but return it.
Clear the pointers before returning them.
@tmp is leaked after the second call to virVHBAGetConfig within
virVHBAIsVportCapable code block because it wasn't freed after making the
first call to the function.
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The @ipv6_host allocated in virAsprintf may be lost when virAsprintf
addrstr failed.
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
There is a VIR_FREE after a return statement. That code section is never
executed and for this reason the "tty" variable is not being freed. This
commit rearranges the logic.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Many vendor id's and product id's have leading zeros. We should show
them in the logs.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
Reviewed-by: Laine Stump <laine@laine.org>
The @meminfo allocated in qemuMonitorGetMemoryDeviceInfo() may be
lost when qemuDomainObjExitMonitor() failed.
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1420740
Testing found an inventive way to cause an error at shutdown by providing the
parent name for the fc host creation using the "same name" as the HBA. Since
the code thus assumed the parent host name provided was the parent HBA and
just extracted out the host number and sent that along to the vport_destroy
this avoided checks made for equality.
So just add the equality check to that path to resolve.
While most of the APIs are okay with 16M messages, the bulk stats API
can run into the limit in big configurations. Before we devise a new
plan for this, bump this limit slightly to accomodate some more configs.
If the first console is just a copy of the first serial device we
don't need to iterate over the same device twice in order to perform
actions like security labeling, cgroup configuring, etc.
Currently only security SELinux manager was aware of this fact.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Put domain access after acquiring job condition, otherwise
another job can change it meanwhile.
Signed-off-by: Konstantin Neumoin <kneumoin@virtuozzo.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
We have to use waitDomainJob instead of waitJob, because of it
unlock the domain until job has finished, so domain will be available
for other clients.
Signed-off-by: Konstantin Neumoin <kneumoin@virtuozzo.com>
Setting the 'group_name' for a disk would falsely trigger a error path
as in commit 4b57f76502 we did not properly check the return value of
VIR_STRDUP.
Attempting to start a domain with USB hostdevs but no USB controllers
fails with the rather cryptic error
libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an
error message from QMP server: Bus 'xenusb-0.0' not found
This can be fixed by creating default USB controllers. When no USB
controllers are defined, create the number of 8 port controllers
necessary to accommodate the number of defined USB devices.
Note that USB controllers are already created as needed in the
domainAttachDevice code path. E.g. a USB controller will be created,
if necessary, when attaching a USB device with
'virsh attach-device dom usbdev.xml'.
This reverts commit 2841e675.
It turns out that adding the host_mtu field to the PCI capabilities in
the guest bumps the length of PCI capabilities beyond the 32 byte
boundary, so the virtio-net device gets 64 bytes of ioport space
instead of 32, which offsets the address of all the other following
devices. Migration doesn't work very well when the location and length
of PCI capabilities of devices is changed between source and
destination.
This means that we need to make sure that the absence/presence of
host_mtu on the qemu commandline always matches between source and
destination, which means that we need to make setting of host_mtu an
opt-in thing (it can't happen automatically when the bridge being used
has a non-default MTU, which is what commit 2841e675 implemented).
I do want to re-implement this feature with an <mtu auto='on'/>
setting, but probably won't backport that to any stable branches, so
I'm first reverting the original commit, and that revert can be pushed
to the few releases that have been made since the original (3.1.0 -
3.3.0)
Resolves: https://bugzilla.redhat.com/1449346
If a VNC listen address is not specified in domXML, libxl
will default to 127.0.0.1, but this is never reflected in the domXML.
In the case of spice, a missing listen address resulted in listening
on all interfaces, i.e. '0.0.0.0'. If not specified, set the listen
address in virDomainGraphicsDef struct to the libxl default when
creating the frame buffer device. Additionally, set default spice
listen address to 127.0.0.1.
There's a slight problem with the current function. Assume we are
currently in a data section and we have say 42 bytes until next
section. Therefore, just before (handler) is called to fill up
the buffer with data, @want is changed to 42 to match the amount
of data left in the current section. However, after hole is
processed, we are back in data section but with incredibly small
@want size. Nobody will ever reset it back. This results in
incredible data fragmentation.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
To every virDirOpen we must have VIR_DIR_CLOSE otherwise FD is
leaked.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The error message would contain first vcpu id after the list of vcpus
selected for modification. To print the proper vcpu id remember the
first vcpu selected to be modified.
@reply is a DBusMessage object returned by virDBusCallMethod in
get machine object call path, dereference it before calling
virDBusCallMethod again to get machine name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
It is possible to crash libvirtd when converting xl native config to
domXML when the xl config contains an empty disk source, e.g. an empty
CDROM. Fix by checking that the disk source is non-NULL before parsing it.
Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
Some older systems (such as RHEL6) lack SEEK_HOLE and SEEK_DATA
which virFileInData relies on. Provide a stub for these systems.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The code causes the 'offset' variable to be overwritten (possibly with
NULL if neither of the vCPUs is halted) which causes a crash since the
variable is still used after that part.
Additionally there's a bug, since strstr() would look up the '(halted)'
string in the whole string rather than just the currently processed line
the returned data is completely bogus.
Rather than switching to single line parsing let's remove the code
altogether since it has a commonly used JSON monitor alternative and
the data itself is not very useful to report.
The code was introduced in commit cc5e695bde
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1452106
There is a wrong 'return' statement after a 'goto' statement inside the
function virConnectCloseCallbackDataRegister(). This commit only removes
the 'return'.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Currently, we don't assign any meaning to that. Our current view
on virStream is that it's merely a pipe. And pipes don't support
seeking.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Commit e3ba4025 introduced srv->handles and VIR_RESIZE_N to allocate
@handles as necessary, but did not free the handles during when calling
virNetlinkEventServiceStop.
Commit 15a71e60 introduced the virNetlinkEventServiceStopAll function, and
the code in virNetlinkEventServiceStop is copied to this function, so just
call virNetlinkEventServiceStop instead.
Start discovering the mediated devices on the host system and format the
attributes for the mediated device into the XML. Compared to the parent
device which reports generic information about the abstract mediated
devices types, a child device only reports the type name it has been
instantiated from and the IOMMU group number, since that's device
specific compared to the rest of the info that can be gathered about
mediated devices at the moment.
This patch introduces both the formatting and parsing routines, updates
nodedev.rng schema, adding a testcase as well.
The resulting mdev child device XML:
<device>
<name>mdev_4b20d080_1b54_4048_85b3_a6a62d165c01</name>
<path>/sys/devices/.../4b20d080-1b54-4048-85b3-a6a62d165c01</path>
<parent>pci_0000_06_00_0</parent>
<driver>
<name>vfio_mdev</name>
</driver>
<capability type='mdev'>
<type id='vendor_supplied_type_id'/>
<iommuGroup number='NUM'/>
<capability/>
<device/>
https://bugzilla.redhat.com/show_bug.cgi?id=1452072
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The parent device needs to report the generic stuff about the supported
mediated devices types, like device API, available instances, type name,
etc. Therefore this patch introduces a new nested capability element of
type 'mdev_types' with the resulting XML of the following format:
<device>
...
<capability type='pci'>
...
<capability type='mdev_types'>
<type id='vendor_supplied_id'>
<name>optional_vendor_supplied_codename</name>
<deviceAPI>vfio-pci</deviceAPI>
<availableInstances>NUM</availableInstances>
</type>
...
<type>
...
</type>
</capability>
</capability>
...
</device>
https://bugzilla.redhat.com/show_bug.cgi?id=1452072
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The reason for introducing two capabilities, one for the device itself
(cap 'mdev') and one for the parent device listing the available types
('mdev_types'), is that we should be able to do
'virsh nodedev-list --cap' not only for existing mdev devices but also
for devices that support creation of mdev devices, since one day libvirt
might be actually able to create the mdev devices in an automated way
(just like we do for NPIV/vHBA).
https://bugzilla.redhat.com/show_bug.cgi?id=1452072
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Since there's at least SRIOV and MDEV sub-capabilities to be parsed,
let's make the code more readable by splitting it to several logical
blocks.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Namely, this patch is about virMediatedDeviceGetIOMMUGroup{Dev,Num}
functions. There's no compelling reason why these functions should take
an object, on the contrary, having to create an object every time one
needs to query the IOMMU group number, discarding the object afterwards,
seems odd.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Commit 8e09663 "pci: recognize/report GEN4 (PCIe 4.0) card 16GT/s Link
speed" introduced another speed into enum, but mistakenly also altered
field width, so one bit of link width was included there.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
These flags to APIs will tell if caller wants to use sparse
stream for storage transfer. At the same time, it's safe to
enable them in storage driver frontend and rely on our backends
checking the flags. This way we can enable specific flags only on
some specific backends, e.g. enable
VIR_STORAGE_VOL_DOWNLOAD_SPARSE_STREAM for filesystem backend but
not iSCSI backend.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Now, not all APIs are going to support sparse streams. To some it
makes no sense at all, e.g. virDomainOpenConsole() or
virDomainOpenChannel(). To others, we will need a special flag to
indicate that client wants to enable sparse streams. Instead of
having to write RPC dispatchers by hand we can just annotate in
our .x files that a certain flag to certain RPC call enables this
feature. For instance:
/**
* @generate: both
* @readstream: 1
* @sparseflag: VIR_SPARSE_STREAM
* @acl: storage_vol:data_read
*/
REMOTE_PROC_DOMAIN_SOME_API = XXX,
Therefore, whenever client calls virDomainSomeAPI(..,
VIR_SPARSE_STREAM); daemon will mark that down and send stream
skips when possible.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Basically, what is needed here is to introduce new message type
for the messages passed between the event loop callbacks and the
worker thread that does all the I/O. The idea is that instead of
a queue of read buffers we will have a queue where "hole of size
X" messages appear. That way the event loop callbacks can just
check the head of the queue and see if the worker thread is in
data or a hole section and how long the section is.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Whenever server sends a client stream packet (either regular with
actual data or stream skip one) it is queued on @st->rx. So the
list is a mixture of both types of stream packets. So now that we
have all the helpers needed we can wire their processing up. But
since virNetClientStreamRecvPacket doesn't support
VIR_STREAM_RECV_STOP_AT_HOLE flag yet, let's turn all received
skips into zeroes repeating requested times.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Now that we have RPC wrappers over VIR_NET_STREAM_HOLE we can
start wiring them up. This commit wires up situation when a
client wants to send a hole to daemon.
To keep stream offsets synchronous, upon successful call on the
daemon skip the same hole in local part of the stream.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This is a function that handles an incoming STREAM_HOLE packet.
Even though it is not wired up yet, it will be soon. At the
beginning do couple of checks whether server plays nicely and
sent us a STREAM_HOLE packed only after we've enabled sparse
streams. Then decodes the message payload to see how big the hole
is and stores it in passed @length argument.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
While the previous commit implemented a helper for sending a
STREAM_HOLE packet for daemon, this is a client's counterpart.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This is just a helper function that takes in a length value,
encodes it into XDR and sends to client.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This is a special type of stream packet, that is bidirectional
and contains information regarding how many bytes each side will
be skipping in the stream.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Add a new argument to daemonCreateClientStream in order to allow for
future expansion to mark that a specific stream can be used to skip
data, such as the case with sparsely populated files. The new flag will
be the eventual decision point between client/server to decide whether
both ends can support and want to use sparse streams.
A new bool 'allowSkip' is added to both _virNetClientStream and
daemonClientStream in order to perform the tracking.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Add a virStreamPtr pointer to the _virNetClientStream
in order to reverse track the parent stream.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This is just an internal API, that calls corresponding function
in stream driver. This function will set @data = 1 if the
underlying file is in data section, or @data = 0 if it is in a
hole. At any rate, @length is set to number of bytes remaining in
the section the file currently is.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This is just a wrapper over new function that have been just
introduced: virStreamSendHole() . It's very similar to
virStreamSendAll() except it handles sparse streams well.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This is just a wrapper over new functions that have been just
introduced: virStreamRecvFlags(), virStreamRecvHole(). It's very
similar to virStreamRecvAll() except it handles sparse streams
well.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Add a new flag to virStreamRecvFlags in order to handle being able to
stop reading from the stream so that the consumer can generate a "hole"
in stream target. Generation of a hole replaces the need to receive and
handle a sequence of zero bytes for sparse stream targets.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This function is basically a counterpart for virStreamSendHole().
If one side of a stream called virStreamSendHole() the other
should call virStreamRecvHole() to get the size of the hole.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This API is used to tell the other side of the stream to skip
some bytes in the stream. This can be used to create a sparse
file on the receiving side of a stream.
It takes @length argument, which says how big the hole is. This
skipping is done from the current point of stream. Since our
streams are not rewindable like regular files, we don't need
@whence argument like seek(2) has.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
There are three virStreamDriver's currently supported:
* virFDStream
* remote driver
* ESX driver
For now, backend virStreamRecvFlags support for only remote driver and
ESX driver is sufficient. Future patches will update virFDStream.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This patch is adding the virStreamRecvFlags as a variant to the
virStreamRecv function in order to allow for future expansion of
functionality for processing sparse streams using a @flags
argument.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This function takes a FD and determines whether the current
position is in data section or in a hole. In addition to that,
it also determines how much bytes are there remaining till the
current section ends.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
One big downside of using the pipe to transfer the data is that
we can really transfer just bare data. No metadata can be carried
through unless some formatted messages are introduced. That would
be quite painful to achieve so let's use a message queue. It's
fairly easy to exchange info between threads now that iohelper is
no longer used.
The reason why we cannot use the FD for plain files directly is
that despite us setting noblock flag on the FD, any
read()/write() blocks regardless (which is a show stopper since
those parts of the code are run from the event loop) and poll()
reports such FD as always readable/writable - even though the
subsequent operation might block.
The pipe is still not gone though. It is used to signal the event
loop that an event occurred (e.g. data is available for reading
in the queue, or vice versa).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Since we allow active layer block commit the users are allowed to commit
the top of the chain (e.g. vda) into the backing image. The API would
not accept that parameter, as it tried to look up the image in the
backing chain.
Add the ability to use the top level image target name explicitly as the
top image of the block commit operation.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1451394
The QEMU default is GICv2, and some of the code in libvirt
relies on the exact value. Stop pretending that's not the
case and use GICv2 explicitly where needed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
There are currently some limitations in the emulated GICv3
that make it unsuitable as a default. Use GICv2 instead.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1450433
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Currently we consider all UNIX paths with specific prefix as generated
by libvirt, but that's a wrong assumption. Let's make the detection
better by actually checking whether the whole path matches one of the
paths that we generate or generated in the past.
The UNIX path isn't stored in config XML since libvirt-1.3.1.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1446980
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The debian etch distro was end-of-life a long time ago so we no
longer need the ULLONG_MAX hack. In any case gnulib now provides
an equivalent fix by default, and so our definition now triggers
syntax-check rule failure
src/internal.h:# define ULLONG_MAX ULONG_LONG_MAX
maint.mk: define the above via some gnulib .h file
maint.mk:843: recipe for target 'sc_prohibit_always-defined_macros' failed
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add kernel_irqchip=split/on to the QEMU command line
and a capability that looks for it in query-command-line-options
output. For the 'split' option, use a version check
since it cannot be reasonably probed.
https://bugzilla.redhat.com/show_bug.cgi?id=1427005
Add a new <ioapic> element with a driver attribute.
Possible values are qemu and kvm. With 'qemu', the I/O
APIC can be put in the userspace even for KVM domains.
https://bugzilla.redhat.com/show_bug.cgi?id=1427005
There should be no need to make dir based pools world/group readable.
So use 0711, not 0755, as the default perms for storage dirs.
Updates in v2:
- adapt commit wording to mention dropping group readable as well
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
The metadata libvirt cares about is identical for version 3
as for previous versions, so we merely need list the new
version number.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
If a shutdown is expected because it was triggered via libvirt we can
also expect the monitor to close. In those cases do not report an
internal error like:
"internal error: End of file from qemu monitor"
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Simply tries to match the provided regex on a string and returns
the result. Useful if caller don't care about the matched substring
and want to just test if some pattern patches a string.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The @type from virFileReadValueString needs to be VIR_FREE each time
through the loop since it's not saved and since cleanup can be reached
prior to decoding it for @kernel_type amd bank->type, the cleanup code
needs to also have a VIR_FREE
Found by Coverity
Adjust the current message to make it clear, that it is the hotplug
operation that is unsupported with the given host device type.
https://bugzilla.redhat.com/show_bug.cgi?id=1450072
Signed-off-by: Erik Skultety <eskultet@redhat.com>
When running on a NUMA machine, populate the sibling node
and distance information using data supplied by Xen.
With locality distances information, under Xen, new host
capabilities would like:
<topology>
<cells num='4'>
<cell id='0'>
<memory unit='KiB'>263902380</memory>
<distances>
<sibling id='0' value='10'/>
<sibling id='1' value='21'/>
</distances>
...
</cell>
...
</cells>
...
</topology>
Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
GCC complains that inlining virStringTrimOptionalNewline is not
likely on some platforms:
cc1: warnings being treated as errors
../../src/util/virfile.c: In function 'virFileReadValueBitmap':
../../src/util/virstring.h:292: error: inlining failed in call to 'virStringTrimOptionalNewline': call is unlikely and code size would grow [-Winline]
../../src/util/virfile.c:3987: error: called from here [-Winline]
Inlining this function is not going to be a measurable performance
benefit either, since the time required to execute it is going to
be dominated by running of strlen() over the string, not by the
function call overhead.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Added only in drivers that were already calling
virCapabilitiesInitNUMA(). Instead of refactoring all the callers to
behave the same way in case of error, just follow what the callers are
doing for all the functions.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
We're only adding only info about L3 caches, we can add more
later (just by changing one line), but for now that's more than enough
without overwhelming anyone.
XML snippet of how this should look like (also seen as part of the commit):
<cache>
<bank id='0' level='3' type='both' size='8192' unit='KiB' cpus='0-7'/>
</cache>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
It is no longer needed thanks to the great virfilewrapper.c. And this
way we don't have to add a new set of functions for each prefixed
path.
While on that, add two functions that weren't there before, string and
scaled integer reading ones. Also increase the length of the string
being read by one to accompany for the optional newline at the
end (i.e. change INT_STRLEN_BOUND to INT_BUFSIZE_BOUND).
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
So, because mingw is somehow OK with dereferencing a pointer within a
VIR_DEBUG macro, compared to outside of it to which it complained with a
"potential NULL pointer dereference" error (still a false positive), we
can make the code a tiny bit cleaner.
Sighed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
When adding a nwfilter onto the list in
virNWFilterObjListAssignDef() this array is re-allocated to match
demand for new size. However, it is never freed leading to a
leak:
==26535== 136 bytes in 1 blocks are definitely lost in loss record 1,079 of 1,250
==26535== at 0x4C2E2BE: realloc (vg_replace_malloc.c:785)
==26535== by 0x54BA28E: virReallocN (viralloc.c:245)
==26535== by 0x54BA384: virExpandN (viralloc.c:294)
==26535== by 0x54BA657: virInsertElementsN (viralloc.c:436)
==26535== by 0x55DB011: virNWFilterObjListAssignDef (virnwfilterobj.c:362)
==26535== by 0x55DB530: virNWFilterObjListLoadConfig (virnwfilterobj.c:503)
==26535== by 0x55DB635: virNWFilterObjListLoadAllConfigs (virnwfilterobj.c:539)
==26535== by 0x2AC5A28B: nwfilterStateInitialize (nwfilter_driver.c:250)
==26535== by 0x5621C64: virStateInitialize (libvirt.c:770)
==26535== by 0x124379: daemonRunStateInit (libvirtd.c:881)
==26535== by 0x554AC78: virThreadHelper (virthread.c:206)
==26535== by 0x8F5F493: start_thread (in /lib64/libpthread-2.23.so)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
After bdcf6e481 there is a crasher in libvirt. The commit assumes
that priv->perf is always set. That is not true. For inactive
domains, the priv->perf is not allocated as it is set in
qemuProcessLaunch(). Now, usually we differentiate between
accesses to inactive and active definition and it works just
fine. Except for 'domstats'. There priv->perf is accessed without
prior check for domain inactivity. While we could check for that,
more robust solution is to make virPerfEventIsEnabled() accept
NULL.
How to reproduce:
1) ensure you have at least one inactive domain
2) virsh domstats
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
This patch fixes the following MinGW error (although actually being a
false positive):
../../src/util/virmdev.c: In function 'virMediatedDeviceListMarkDevices':
../../src/util/virmdev.c:453:21: error: potential null pointer
dereference [-Werror=null-dereference]
const char *mdev_path = mdev->path;
^~~~~~~~~
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The problem resides in virHostdevUpdateActiveMediatedDevices which gets
called during qemuProcessReconnect. The issue here is that
virMediatedDeviceListAdd takes a pointer to the item to be added to the
list to which VIR_APPEND_ELEMENT is used, which also clears the pointer.
However, in this case only the local copy of the pointer got cleared,
leaving the original pointing to valid memory. To sum it up, during
cleanup phase, the original pointer is freed and the daemon crashes
basically any time it would access it.
Backtrace:
0x00007ffff3ccdeba in __strcmp_sse2_unaligned
0x00007ffff72a444a in virMediatedDeviceListFindIndex
0x00007ffff7241446 in virHostdevReAttachMediatedDevices
0x00007fffc60215d9 in qemuHostdevReAttachMediatedDevices
0x00007fffc60216dc in qemuHostdevReAttachDomainDevices
0x00007fffc6046e6f in qemuProcessStop
0x00007fffc6091596 in processMonitorEOFEvent
0x00007fffc6091793 in qemuProcessEventHandler
0x00007ffff7294bf5 in virThreadPoolWorker
0x00007ffff7294184 in virThreadHelper
0x00007ffff3fdc3c4 in start_thread () from /lib64/libpthread.so.0
0x00007ffff3d269cf in clone () from /lib64/libc.so.6
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1446455
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
Use a local variable to hold data, rather than accessing the pointer
after calling virMediatedDeviceListAdd (therefore VIR_APPEND_ELEMENT).
Although not causing an issue at the moment, this change is a necessary
prerequisite for tweaking virMediatedDeviceListAdd in a separate patch,
which will take a reference for the source pointer (instead of pointer
value) and will clear it along the way.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Even though there are several checks before calling this function
and for some scenarios we don't call it at all (e.g. on disk hot
unplug), it may be possible to sneak in some weird files (e.g. if
domain would have RNG with /dev/shm/some_file as its backend). No
matter how improbable, we shouldn't unlink it as we would be
unlinking a file from the host which we haven't created in the
first place.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cedric Bosdonnat <cbosdonnat@suse.com>
Just like in previous commit, this fixes the same issue for
hotplug.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cedric Bosdonnat <cbosdonnat@suse.com>
While the code allows devices to already be there (by some
miracle), we shouldn't try to create devices that don't belong to
us. For instance, we shouldn't try to create /dev/shm/file
because /dev/shm is a mount point that is preserved. Therefore if
a file is created there from an outside (e.g. by mgmt application
or some other daemon running on the system like vhostmd), it
exists in the qemu namespace too as the mount point is the same.
It's only /dev and /dev only that is different. The same
reasoning applies to all other preserved mount points.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cedric Bosdonnat <cbosdonnat@suse.com>
Currently, all we need to do in qemuDomainCreateDeviceRecursive() is to
take given @device, get all kinds of info on it (major & minor numbers,
owner, seclabels) and create its copy at a temporary location @path
(usually /var/run/libvirt/qemu/$domName.dev), if @device live under
/dev. This is, however, very loose condition, as it also means
/dev/shm/* is created too. Therefor, we will need to pass more arguments
into the function for better decision making (e.g. list of mount points
under /dev). Instead of adding more arguments to all the functions (not
easily reachable because some functions are callback with strictly
defined type), lets just turn this one 'const char *' into a 'struct *'.
New "arguments" can be then added at no cost.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cedric Bosdonnat <cbosdonnat@suse.com>
When setting up mount namespace for a qemu domain the following
steps are executed:
1) get list of mountpoints under /dev/
2) move them to /var/run/libvirt/qemu/$domName.ext
3) start constructing new device tree under /var/run/libvirt/qemu/$domName.dev
4) move the mountpoint of the new device tree to /dev
5) restore original mountpoints from step 2)
Note the problem with this approach is that if some device in step
3) requires access to a mountpoint from step 2) it will fail as
the mountpoint is not there anymore. For instance consider the
following domain disk configuration:
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/dev/shm/vhostmd0'/>
<target dev='vdb' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
</disk>
In this case operation fails as we are unable to create vhostmd0
in the new device tree because after step 2) there is no /dev/shm
anymore. Leave aside fact that we shouldn't try to create devices
living in other mountpoints. That's a separate bug that will be
addressed later.
Currently, the order described above is rearranged to:
1) get list of mountpoints under /dev/
2) start constructing new device tree under /var/run/libvirt/qemu/$domName.dev
3) move them to /var/run/libvirt/qemu/$domName.ext
4) move the mountpoint of the new device tree to /dev
5) restore original mountpoints from step 3)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cedric Bosdonnat <cbosdonnat@suse.com>
When we get a POLLHUP or VIR_EVENT_HANDLE_HANGUP event for a client, we
still want to read from the socket to process any accumulated data. But
doing so inevitably results in an error and a call to
virNetClientMarkClose before we get to processing the hangup event (and
another call to virNetClientMarkClose). However the close reason passed
to the second virNetClientMarkClose call is ignored because another one
was already set. We need to pass the correct close reason when marking
the socket to be closed for the first time.
https://bugzilla.redhat.com/show_bug.cgi?id=1373859
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
While fixing a bug with incorrectly freed memory in commit
v3.1.0-399-g5498aa29a, I accidentally broke persistent migration of
transient domains. Before adding qemuDomainDefCopy in the path, the code
just took NULL from vm->newDef and used it as the persistent def, which
resulted in no persistent XML being sent in the migration cookie. This
scenario is perfectly valid and the destination correctly handles it by
using the incoming live definition and storing it as the persistent one.
After the mentioned commit libvirtd would just segfault in the described
scenario.
https://bugzilla.redhat.com/show_bug.cgi?id=1446205
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
If we are encoding a block of data that is 16 bytes in length,
we cannot leave it as 16 bytes, we must pad it out to the next
block boundary, 32 bytes. Without this padding, the decoder will
incorrectly treat the last byte of plain text as the padding
length, as it can't distinguish padded from non-padded data.
The problem exhibited itself when using a 16 byte passphrase
for a LUKS volume
$ virsh secret-set-value 55806c7d-8e93-456f-829b-607d8c198367 \
$(echo -n 1234567812345678 | base64)
Secret value set
$ virsh start demo
error: Failed to start domain demo
error: internal error: process exited while connecting to monitor: >>>>>>>>>>Len 16
2017-05-02T10:35:40.016390Z qemu-system-x86_64: -object \
secret,id=virtio-disk1-luks-secret0,data=SEtNi5vDUeyseMKHwc1c1Q==,\
keyid=masterKey0,iv=zm7apUB1A6dPcH53VW960Q==,format=base64: \
Incorrect number of padding bytes (56) found on decrypted data
Notice how the padding '56' corresponds to the ordinal value of
the character '8'.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When creating v3.2.0-77-g8be3ccd04 commit, I completely forgot that one
migration capability is very special. It's the "events" capability which
tells QEMU to report "MIGRATION" events. Since libvirt always wants the
events, it is enabled in qemuConnectMonitor and the rest of the code
should not touch it.
https://bugzilla.redhat.com/show_bug.cgi?id=1439841https://bugzilla.redhat.com/show_bug.cgi?id=1441165
Messed-up-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
... with VIR_NET_GENERATED_MACV???_PREFIX, which is defined in
util/virnetdevmacvlan.h.
Since VIR_NET_GENERATED_PREFIX is used for plain tap devices, it is
renamed to VIR_NET_GENERATED_TAP_PREFIX and moved to virnetdev.h
The parser had been clearing out *all* suggested device names for
type='direct' (aka macvtap) interfaces. All of the code implementing
macvtap allows for a user-specified device name, so we should allow
it. In the case that an interface name starts with "macvtap" or
"macvlan" though, we do still clear it out, just as we do with "vnet"
(which is the prefix used for automatically generated tap device
names), since those are the prefixes for the names we autogenerate for
macvtap and macvlan devices.
Resolves: https://bugzilla.redhat.com/1335798
MACVTAP_NAME_PREFIX and MACVLAN_NAME_PREFIX could be useful to other
files if they were defined in virnetdevmacvlan.h instead of
virnetdevmacvlan.c, so do that (while slightly renaming them and also
adding yet another #define that chooses between macvlan/macvtap based
on flags).
This is a prerequisite to fix: https://bugzilla.redhat.com/1335798
If the network isn't active during networkNotifyActualDevice(), we
would log an error message stating that the bridge device didn't
exist. This patch adds a check to see if the network is active, making
the logs more useful in the case that it isn't.
Partially resolves: https://bugzilla.redhat.com/1442700
Nothing that could happen during networkNotifyActualDevice() could
justify unceremoniously killing the qemu process, but that's what we
were doing.
In particular, new code added in commit 85bcc022 (first appearred in
libvirt-3.2.0) attempts to reattach tap devices to their assigned
bridge devices when libvirtd restarts (to make it easier to recover
from a restart of a libvirt network). But if the network has been
stopped and *not* restarted, the bridge device won't exist and
networkNotifyActualDevice() will fail.
This patch changes networkNotifyActualDevice() and
qemuProcessNotifyNets() to return void, so that qemuProcessReconnect()
will soldier on regardless of what happens (any errors will still be
logged though).
Partially resolves: https://bugzilla.redhat.com/1442700
After 1eb6647979 nobody calls the iohelper with 6 arguments.
Everybody uses the other mode. Well, the only user of iohelper
after the previous commit is virFileWrapperFd really.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Currently we use iohelper for virFDStream implementation. This is
because UNIX I/O can lie sometimes: even though a FD for a
file/block device is set as unblocking, actual read()/write() can
block. To avoid this, a pipe is created and one end is kept for
read/write while the other is handed over to iohelper to
write/read the data for us. Thus it's iohelper which gets blocked
and not our event loop.
This approach has two problems:
1) we are spawning a new process.
2) any exchange of information between daemon and iohelper can be
done only through the pipe.
Therefore, iohelper is replaced with an implementation in thread
which is created just for the stream lifetime. The data are still
transferred through pipe (for now), but both problems described
above are solved.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
While this is no functional change, it makes the code look a bit
nicer. Moreover, it prepares ground for future work.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
There is really no reason why we should have to have 'struct'
everywhere.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This is a USB3 controller and it's a better choice than piix3-uhci.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Acked-by: Andrea Bolognani <abologna@redhat.com>
The new logic will set the piix3-uhci if available regardless of
any architecture and it will be updated to better model based on
architecture and device existence.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Acked-by: Andrea Bolognani <abologna@redhat.com>
Since commit c5f6151390 qemuDomainBlockInfo tries to update the
"physical" storage size for all network storage and not only block
devices.
Since the storage driver APIs to do this are not implemented for certain
storage types (RBD, iSCSI, ...) the code would fail to retrieve any data
since the failure of qemuDomainStorageUpdatePhysical is fatal.
Since it's desired to return data even if the total size can't be
updated we need to ignore errors from that function and return plausible
data.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1442344
Since the private data structure is not freed upon stopping a VM, the
usbaddrs pointer would be leaked:
==15388== 136 (16 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 893 of 1,019
==15388== at 0x4C2CF55: calloc (vg_replace_malloc.c:711)
==15388== by 0x54BF64A: virAlloc (viralloc.c:144)
==15388== by 0x5547588: virDomainUSBAddressSetCreate (domain_addr.c:1608)
==15388== by 0x144D38A2: qemuDomainAssignUSBAddresses (qemu_domain_address.c:2458)
==15388== by 0x144D38A2: qemuDomainAssignAddresses (qemu_domain_address.c:2515)
==15388== by 0x144ED1E3: qemuProcessPrepareDomain (qemu_process.c:5398)
==15388== by 0x144F51FF: qemuProcessStart (qemu_process.c:5979)
[...]
Clean the stale data after shutting down the VM. Otherwise the data
would be leaked on next VM start. This happens due to the fact that the
private data object is not freed on destroy of the VM.
Per xen-xl conversions from and to native under host-passthrough
mode we take care for Xen (nestedhvm = mode) applied and inherited
settings generating or processing correct feature policy:
[On Intel (VT-x) architectures]
<feature policy='disable' name='vmx'/>
or
[On AMD (AMD-V) architectures]
<feature policy='disable' name='svm'/>
It will then generate (or parse) for nestedhvm=1 in/from xl format.
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
Xen feature nestedhvm is the option on Xen 4.4+ which enables
nested virtualization when mode host-passthrough is applied.
nested HVM is enabled by adding below on the target domain;
<cpu mode='host-passthrough'/>
Virtualization on target domain can be disabled by specifying
such under feature policy rule on target name;
[On Intel (VT-x) architecture]
<feature policy='disable' name='vmx'/>
or:
[On AMD (AMD-V) architecture]
<feature policy='disable' name='svm'/>
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
This patch maps /domain/cpu/cache element into -cpu parameters:
- <cache mode='passthrough'/> is translated to host-cache-info=on
- <cache level='3' mode='emulate'/> is transformed into l3-cache=on
- <cache mode='disable'/> is turned in host-cache-info=off,l3-cache=off
Any other <cache> element is forbidden.
The tricky part is detecting whether QEMU supports the CPU properties.
The 'host-cache-info' property is introduced in v2.4.0-1389-ge265e3e480,
earlier QEMU releases enabled host-cache-info by default and had no way
to disable it. If the property is present, it defaults to 'off' for any
QEMU until at least 2.9.0.
The 'l3-cache' property was introduced later by v2.7.0-200-g14c985cffa.
Earlier versions worked as if l3-cache=off was passed. For any QEMU
until at least 2.9.0 l3-cache is 'off' by default.
QEMU 2.9.0 was the first release which supports probing both properties
by running device-list-properties with typename=host-x86_64-cpu. Older
QEMU releases did not support device-list-properties command for CPU
devices. Thus we can't really rely on probing them and we can just use
query-cpu-model-expansion QMP command as a witness.
Because the cache property probing is only reliable for QEMU >= 2.9.0
when both are already supported for quite a few releases, we let QEMU
report an error if a specific cache mode is explicitly requested. The
other mode (or both if a user requested CPU cache to be disabled) is
explicitly turned off for QEMU >= 2.9.0 to avoid any surprises in case
the QEMU defaults change. Any older QEMU already turns them off so not
doing so explicitly does not make any harm.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
This patch introduces
<cache level='N' mode='emulate'/>
<cache mode='passthrough'/>
<cache mode='disable'/>
sub element of /domain/cpu. Currently only a single <cache> element is
allowed.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The type of this parameter is virCPUType so calling it 'mode' is pretty
strange, 'type' is a much better name.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Not all async jobs are visible via virDomainGetJobStats (either they are
too fast or getting the stats is not allowed during the job), but
forcing all of them to advertise the operation is easier than hunting
the jobs for which fetching statistics is allowed. And we won't need to
think about this when we add support for getting stats for more jobs.
https://bugzilla.redhat.com/show_bug.cgi?id=1441563
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
As with virtio-scsi, the "internal error" messages after
preparing a vhost-scsi hostdev overwrites more meaningful
error messages deeper in the callchain. Remove it too.
Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
I tried to attach a SCSI LUN to two different guests, and forgot
to specify "shareable" in the hostdev XML. Attaching the device
to the second guest failed, but the message was not helpful in
telling me what I was doing wrong:
$ cat scsi_scratch_disk.xml
<hostdev mode='subsystem' type='scsi'>
<source>
<adapter name='scsi_host3'/>
<address bus='0' target='15' unit='1074151456'/>
</source>
</hostdev>
$ virsh attach-device dasd_sles_d99c scsi_scratch_disk.xml
Device attached successfully
$ virsh attach-device dasd_fedora_0e1e scsi_scratch_disk.xml
error: Failed to attach device from scsi_scratch_disk.xml
error: internal error: Unable to prepare scsi hostdev: scsi_host3:0:15:1074151456
I eventually discovered my error, but thought it was weird that
Libvirt doesn't provide something more helpful in this case.
Looking over the code we had just gone through, I commented out
the "internal error" message, and got something more useful:
$ virsh attach-device dasd_fedora_0e1e scsi_scratch_disk.xml
error: Failed to attach device from scsi_scratch_disk.xml
error: Requested operation is not valid: SCSI device 3:0:15:1074151456 is already in use by other domain(s) as 'non-shareable'
Looking over the error paths here, we seem to issue better
messages deeper in the callchain so these "internal error"
messages overwrite any of them. Remove them, so that the
more detailed errors are seen.
Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
0feebab2 adds calling qemuBlockNodeNamesDetect for completed job
on updating block jobs. This affects cancelling drive mirror logic as
this function drops vm lock. Now we have to recheck all disks
before the disk with the completed block job before going
to wait for block job events.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
qemuDomainGetNumaParameters would return the automatic nodeset even for
the persistent config if the domain was running. This is incorrect since
the automatic nodeset will be re-queried upon starting the vm.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1445325
While peer-to-peer migration enters the Confirm phase even if the
Perform phase fails, the client which initiated a non-p2p migration will
never call virDomainMigrateConfirm* API if the Perform phase failed.
Thus we need to explicitly reset migration before reporting a failure
from the Perform phase API.
https://bugzilla.redhat.com/show_bug.cgi?id=1425003
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The recently added sanlock_strerror function can be used to translate
sanlock's numeric errors into human readable strings.
https://bugzilla.redhat.com/show_bug.cgi?id=1409511
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Migration with old QEMU which does not support query-migrate-parameters
would fail because the QMP command is called unconditionally since the
introduction of TLS migration. Previously it was only called if the user
explicitly requested a feature which uses QEMU migration parameters. And
even then the situation was not ideal, instead of reporting an
unsupported feature we'd just complain about missing QMP command.
Trivially no migration parameters are supported when
query-migrate-parameters QMP command is missing. There's no need to
report an error if it is missing, the callers will report better error
if needed.
https://bugzilla.redhat.com/show_bug.cgi?id=1441934
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Rather than waiting for the first save to fail, let's generate the
directory with the correct privs during initialization.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than overloading one function - split apart the logic to have
separate interfaces and local/private structures to manage the data
for which the helper is collecting.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than 'nuuids' it should be 'maxuuids' and rather than 'got'
it should be 'nuuids'. Alter the logic of the list traversal to
utilize those names.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than using "ret = -1" and cleanup processing, alter the return
path on failure to goto error and then just return the data.got.
In the error path, we no longer check for ret < 0, we just can free
anything added to the array and return -1 directly.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than dereferencing obj->def->X, create a local 'def' variable
that will dereference the def and use directly.
Signed-off-by: John Ferlan <jferlan@redhat.com>
When processing a virSecretPtr use 'secret' as a variable name.
When processing a virSecretObjPtr use 'obj' as a variable name.
When processing a virSecretDefPtr use 'def' as a variable name,
unless a distinction needs to be made with a 'newdef' such as
virSecretObjListAddLocked (which also used the VIR_STEAL_PTR macro
for the configFile and base64File).
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than have the caller check if !obj before calling, just check
in the function for !obj and return.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Make various virSecretObjList*Locked functions static and make
virSecretObjNew static since they're only called within virtsecretobj.c.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Only save the config when using a generated UUID if we were able to
create an object for the def. There could have been "other reasons"
for the assignment to fail, so saving the config could be incorrect.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than "wait" for the first config file to be created, force creation
of the configDir during driver state initialization.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Essentially virNWFilterSaveDef executed in a different order the same
sequence of calls, so let's just make one point of reference.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than separate calls, use a common call and generate a better
error message which includes the incorrect uuidstr.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Move from virnwfilterobj.h to virnwfilterobj.c.
Create the virNWFilterObjListNew() API in order to allocate.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Move the structure to virnwfilterobj.c and create necessary accessor API's
for the various fields.
Also make virNWFilterObjFree static since there's no external callers.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than dereferencing obj->def->XXX or nwfilters->objs[i]->X
create local virNWFilterObjPtr and virNWFilterDefPtr variables.
Future adjustments will be privatizing the object more, so this just
prepares the code for that reality.
Signed-off-by: John Ferlan <jferlan@redhat.com>
When processing a virNWFilterPtr use 'nwfilter' as a variable name.
When processing a virNWFilterObjPtr use 'obj' as a variable name.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Instead of figuring out upfront whether <input> will be a single
or a pair element, format the subelements into a separate buffer
and close <input/> early if this buffer is empty.
https://bugzilla.redhat.com/show_bug.cgi?id=1439132
During 'matrix' testing of all possible combinations I found that if
device is formated with "gpt" first, then an attempt is made to format
using "mac", a startup will fail.
Deeper analysis by Peter Krempa indicates that the "mac" table fits
into the first block on the disk. Since the GPT disklabel is stored
at LBA address 1 it is not overwritten at all. Thus it's apparent that
the (blkid) detection tool then prefers GPT over a older disklabel.
The GPT disklabel has also a secondary copy at the last LBA of the disk.
So, follow the same logic as the logical pool in clearing a 1MB swath
at the beginning and end of the device to avoid potential issues with
larger sector sizes for the device.
Also fixed a minor formatting nit in virStorageBackendDeviceIsEmpty call.
Create a wrapper/helper that can be used to call the storage backend
wipe helper - storageBackendVolWipeLocalFile for future use by logical
and disk backends to clear out the partition table rather than having
each open code the same algorithm.
Add bool 'zero_end' and logic that would allow a caller to wipe specific
portions of a target device either from the beginning (the default) or
from the end when zero_end is true.
This will allow for this code to wipe out partition table information
from a device.
There were a few bugs in keycodemap tool that broke it
when run on python circa 2.7.5 or older, which affected
RHEL builds.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
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: Daniel P. Berrange <berrange@redhat.com>
Shorten the time needed to keep the list lock and alter the cleanup
path to be more of an error path.
Utilize the the virObjectListFree function to handle the calls for
virObjectUnref on each list element and the VIR_FREE of the list
instead of open coding it.
Change the name of the virHashForEach callback to match the name
of the Export function with the Callback added onto it.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Commit id '865f479da' altered the logic to use a common test*ObjFindByName
helpers which would lock/unlock the test driver; however, a few cleanup paths
in that cleanup missed removing the Unlock, so remove it now.
Signed-off-by: John Ferlan <jferlan@redhat.com>
it should be a comparison of modes between new and old devices. So
the argument of the second virDomainNetGetActualDirectMode should be
newdev.
Signed-off-by: ZhiPeng Lu <lu.zhipeng@zte.com.cn>
Currently, virNetDevSetCoalesce() stub is always returning error. As
it's used by virNetDevTapCreateInBridgePort(), it essentially breaks
bridged networking if coalesce is not supported.
To make it work, relax the stub to trigger error only when its
coalesce argument is not NULL, otherwise report success.
Since we have that information provided by @def which is not a private
object, there is really no need for the variable.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
So udevGetDeviceDetails was one those functions using an enum in a
switch, but since it had a 'default' case, compiler didn't warn about an
unhandled enum. Moreover, the error about an unsupported device type
reported in the default case is unnecessary, since by the time we get
there, udevGetDeviceType (which was called before) already made sure
that any unrecognized device types had been handled properly.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
ka maybe have been freeed in virObjectUnref, application using
virKeepAliveTimer will segfault when unlock ka. We should keep
ka's refs positive before using it.
#0 0x00007fd8f79970e8 in virClassIsDerivedFrom (klass=0xdeadbeef, parent=0x7fd8e8001b80) at util/virobject.c:169
#1 0x00007fd8f799742e in virObjectIsClass (anyobj=anyobj entry=0x7fd8e800b9c0, klass=＜optimized out＞) at util/virobject.c:365
#2 0x00007fd8f79974e4 in virObjectUnlock (anyobj=0x7fd8e800b9c0) at util/virobject.c:338
#3 0x00007fd8f7ac477e in virKeepAliveTimer (timer=＜optimized out＞, opaque=0x7fd8e800b9c0) at rpc/virkeepalive.c:177
#4 0x00007fd8f7e5c9cf in libvirt_virEventInvokeTimeoutCallback () from /usr/lib64/python2.7/site-packages/libvirtmod.so
#5 0x00007fd8ff64db94 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#6 0x00007fd8ff64f1ad in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#7 0x00007fd8ff64d85f in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#8 0x00007fd8ff64d950 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#9 0x00007fd8ff64d950 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#10 0x00007fd8ff64f1ad in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#11 0x00007fd8ff5dc098 in function_call () from /lib64/libpython2.7.so.1.0
#12 0x00007fd8ff5b7073 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#13 0x00007fd8ff5c6085 in instancemethod_call () from /lib64/libpython2.7.so.1.0
#14 0x00007fd8ff5b7073 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#15 0x00007fd8ff648ff7 in PyEval_CallObjectWithKeywords () from /lib64/libpython2.7.so.1.0
#16 0x00007fd8ff67d7e2 in t_bootstrap () from /lib64/libpython2.7.so.1.0
#17 0x00007fd8ff358df3 in start_thread () from /lib64/libpthread.so.0
#18 0x00007fd8fe97d3ed in clone () from /lib64/libc.so.6
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
It was left there after removing a macro it was part of in first
version or so. Now it will always be NULL.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Commit f4ef3a71 made a variation of virNetDevSetMAC that would return
without logging an error message if errno was set to
EADDRNOTAVAIL. This errno is set by some SRIOV VF drivers (in
particular igbvf) when they fail to set the device's MAC address due
to the PF driver refusing the request. This is useful if we want to
try a different method of setting the VF MAC address before giving up
(Commit 86556e16 actually does this, setting the desired MAC address
to the "admin MAC in the PF, then detaching and reattaching the VF
netdev driver to force a reinit of the MAC address).
During testing of Bug 1442040 t was discovered that the ixgbe driver
returns EPERM in this situation, so this patch changes the exception
case for silent+non-terminal failure to account for this difference.
Completes resolution to: https://bugzilla.redhat.com/1415609 (RHEL 7.4)
https://bugzilla.redhat.com/1442040 (RHEL 7.3.z)
The current fallback stub for virNetDevSetCoalesce is inside an
earlier conditional block. This deals with the feature being
missing on older Linux platforms. We need a second fallback stub
though, outside the top level conditional, to ensure builds work
on Win32/FreeBSD platforms too.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch makes use of the virNetDevSetCoalesce() function to make
appropriate settings effective for devices that support them.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1414627
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
We are currently parsing only rx/frames/max because that's the only
value that makes sense for us. The tun device just added support for
this one and the others are only supported by hardware devices which
we don't need to worry about as the only way we'd pass those to the
domain is using <hostdev/> or <interface type='hostdev'/>. And in
those cases the guest can modify the settings itself.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
That function is able to configure coalesce settings for an interface,
similarly to 'ethtool -C'. This function also updates back the
structure so that it contains actual data on the device (if the device
doesn't support some settings kernel might just return 0 and not set
whatever is not supported), so this way we'll have up-to-date
information in the live domain XML.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reported by Rafał Wojciechowski <it@rafalwojciechowski.pl>.
Thread 1 (Thread 0x7f194b99d700 (LWP 5631)):
0 virNetDevGetifaddrsAddress (addr=0x7f194b99c7c0, ifname=0x7f193400e2b0 "ovirtmgmt") at util/virnetdevip.c:738
1 virNetDevIPAddrGet (ifname=0x7f193400e2b0 "ovirtmgmt", addr=addr@entry=0x7f194b99c7c0) at util/virnetdevip.c:795
2 0x00007f19467800d6 in networkGetNetworkAddress (netname=<optimized out>, netaddr=netaddr@entry=0x7f1924013f18) at network/bridge_driver.c:4780
3 0x00007f193e43a33c in qemuProcessGraphicsSetupNetworkAddress (listenAddr=0x7f19340f7650 "127.0.0.1", glisten=0x7f1924013f10) at qemu/qemu_process.c:4062
4 qemuProcessGraphicsSetupListen (vm=<optimized out>, graphics=0x7f1924014f10, cfg=0x7f1934119f00) at qemu/qemu_process.c:4133
5 qemuProcessSetupGraphics (flags=17, vm=0x7f19240155d0, driver=0x7f193411f1d0) at qemu/qemu_process.c:4196
6 qemuProcessPrepareDomain (conn=conn@entry=0x7f192c00ab50, driver=driver@entry=0x7f193411f1d0, vm=vm@entry=0x7f19240155d0, flags=flags@entry=17) at qemu/qemu_process.c:4969
7 0x00007f193e4417c0 in qemuProcessStart (conn=conn@entry=0x7f192c00ab50, driver=driver@entry=0x7f193411f1d0, vm=0x7f19240155d0,asyncJob=asyncJob@entry=QEMU_ASYNC_JOB_START, migrateFrom=migrateFrom@entry=0x0, migrateFd=migrateFd@entry=-1, migratePath=migratePath@entry=0x0,snapshot=snapshot@entry=0x0, vmop=vmop@entry=VIR_NETDEV_VPORT_PROFILE_OP_CREATE, flags=17, flags@entry=1) at qemu/qemu_process.c:5553
Man page for getifaddrs also states that the "ifa_addr" may contain
a null pointer which happens if there is an existing network interface
on the host without IP address.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
In the RPC client event loop code, if poll() returns only a POLLHUP
or POLLERR status, then we end up reporting a bogus error message:
error: failed to connect to the hypervisor
error: An error occurred, but the cause is unknown
We do actually report an error, but we virNetClientMarkClose method
has already captured the error status before we report it, so the
real error gets thrown away. The key fix is to report the error
before calling virNetClientMarkClose(). In changing this, we also
split out reporting of POLLHUP vs POLLERR to make any future bugs
easier to diagnose.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In the vcpu hotplug code if exit from the monitor failed we would still
attempt to save the status XML. When the daemon is terminated the
monitor socket is closed. In such case, the written status XML would not
contain the monitor path and thus be invalid.
Avoid this issue by only saving status XML on success of the monitor
command.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1439452
The history of USB controller for ppc64 guest is complex and goes
back to libvirt 1.3.1 where the fun started.
Prior Libvirt 1.3.1 if no model for USB controller was specified
we've simply passed "-usb" on QEMU command line.
Since Libvirt 1.3.1 there is a patch (8156493d8d) that fixes this
issue by using "-device pci-ohci,..." but it breaks migration with
older Libvirts which was agreed that's acceptable. However this
patch didn't reflect this change in the domain XML and the model
was still missing.
Since Libvirt 2.2.0 there is a patch (f55eaccb0c) that fixes the
issue with not setting the USB model into domain XML which we need
to know about to not break the migration and since the default
model was *pci-ohci* it was used as default in this patch as well.
This patch tries to take all the previous changes into account and
also change the default for newly defined domains that don't specify
any model for USB controller.
The VIR_DOMAIN_DEF_PARSE_ABI_UPDATE is set only if new domain is
defined or new device is added into a domain which means that in
all other cases we will use the old *pci-ohci* model instead of the
better and not broken *nec-usb-xhci* model.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1373184
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
So far there is probably no change that is allowed to be done
by the VIR_DOMAIN_DEF_PARSE_ABI_UPDATE flag that would break
guest ABI but this may change in the future.
This introduces new VIR_DOMAIN_DEF_PARSE_ABI_UPDATE_MIGRATION
which should be used only for ABI updates that are "safe" for
persistent migration.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
