Only set releaseaddr to true after the address has been
reserved successfully.

https://bugzilla.redhat.com/show_bug.cgi?id=1452581Reviewed-by: NJohn Ferlan <jferlan@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.

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=1450072Signed-off-by: NErik Skultety <eskultet@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: NEric 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: NEric Farman <farman@linux.vnet.ibm.com>

Signed-off-by: NEric Farman <farman@linux.vnet.ibm.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: NZhiPeng Lu <lu.zhipeng@zte.com.cn>

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 function is used only in the hotplug module.

Introduce new wrapper functions without *Machine* in the function
name that take the whole virDomainDef structure as argument and
call the existing functions with *Machine* in the function name.

Change the arguments of existing functions to *machine* and *arch*
because they don't need the whole virDomainDef structure and they
could be used in places where we don't have virDomainDef.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Make sure that non-hotpluggable vcpus stay clustered at the beginning
after modifying persistent definition.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1437010

Validate that users don't try to disable vcpu 0.

Vcpu order is required to stay sequential. Clear the order on cpu
coldplug to avoid issues with removing vcpus out of sequence.

'next' is declared as 'ssize_t' so use '%zd'

Buggy condition meant that vcpu0 would not be iterated in the checks.
Since it's not hotpluggable anyways we would not be able to break the
configuration of a live VM.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1437013

A mediated device will be identified by a UUID (with 'model' now being
a mandatory <hostdev> attribute to represent the mediated device API) of
the user pre-created mediated device. We also need to make sure that if
user explicitly provides a guest address for a mdev device, the address
type will be matching the device API supported on that specific mediated
device and error out with an incorrect XML message.

The resulting device XML:
<devices>
  <hostdev mode='subsystem' type='mdev' model='vfio-pci'>
    <source>
      <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'>
    </source>
  </hostdev>
</devices>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Add an asyncJob argument for add/delete TLS Objects. A future patch will
add/delete TLS objects from a migration which may have a job to join.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some users might want to pass a blockdev or a chardev as a
backend for NVDIMM. In fact, this is expected to be the mostly
used configuration. Therefore libvirt should allow the device in
devices CGroup then.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Now that we have APIs for relabel memdevs on hotplug, fill in the
missing implementation in qemu hotplug code.

The qemuSecurity wrappers might look like overkill for now,
because qemu namespace code does not deal with the nvdimms yet.
Nor does our cgroup code.  But hey, there's cgroup_device_acl
variable in qemu.conf. If users add their /dev/pmem* device in
there, the device is allowed in cgroups and created in the
namespace so they can successfully passthrough it to the domain.
It doesn't look like overkill after all, does it?
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Frankly, this function is one big mess. A lot of arguments,
complicated behaviour. It's really surprising that arguments were
in random order (input and output arguments were mixed together),
the documentation was outdated, the description of return values
was bogus.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

If the delivery of the DEVICE_DELETED event for the vCPU being deleted
would time out, the code would not call 'qemuDomainResetDeviceRemoval'.

Since the waiting thread did not unregister itself prior to stopping the
waiting the monitor code would try to wake it up instead of dispatching
it to the event worker. As a result the unplug process would not be
completed and the definition would not be updated.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1428893
          https://bugzilla.redhat.com/show_bug.cgi?id=1427801

Note that the waiting thread is signaled in the debug logs to simplify
debugging.

Split apart and rename qemuDomainGetChardevTLSObjects in order to make a
more generic API that can create the TLS JSON prop objects (secret and
tls-creds-x509) to be used to create the objects
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move the call to inside the qemuDomainAddChardevTLSObjects in order to
further converge the code.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move the call to inside the qemuDomainAddChardevTLSObjects in order to
further converge the code.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Create a qemuDomainAddChardevTLSObjects which will encapsulate the
qemuDomainGetChardevTLSObjects and qemuDomainAddTLSObjects so that
the callers don't need to worry about the props.

Move the dev->type and haveTLS checks in to the Add function to avoid
an unnecessary call to qemuDomainAddTLSObjects
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Refactor the TLS object adding code to make two separate API's that will
handle the add/remove of the "secret" and "tls-creds-x509" objects including
the Enter/Exit monitor commands.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since qemuDomainObjExitMonitor can also generate error messages,
let's move it inside any error message saving code on error paths
for various hotplug add activities.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Now that we have some qemuSecurity wrappers over
virSecurityManager APIs, lets make sure everybody sticks with
them. We have them for a reason and calling virSecurityManager
API directly instead of wrapper may lead into accidentally
labelling a file on the host instead of namespace.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1420668

This has worked in previous releases.
My commit c266b604 broke it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It's not really 'Chardev' specific - we can reuse this for other objects.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add code that validates user's selection of cores and then uses the
existing code to plug in the vCPU.

These functions do not need to see the whole virDomainDiskDef.
Moreover, they are going to be called from places where we don't
have access to the full disk definition. Sticking with
virStorageSource is more than enough.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Again, one missed bit. This time without this commit there is no
/dev entry in the namespace of the qemu process when attaching
vhost SCSI device.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since we have qemuSecurity wrappers over
virSecurityManagerSetHostdevLabel and
virSecurityManagerRestoreHostdevLabel we ought to use them
instead of calling secdriver APIs directly.  Without those
wrappers the labelling won't be done in the correct namespace
and thus won't apply to the nodes seen by qemu itself.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

libvirt was able to set the host_mtu option when an MTU was explicitly
given in the interface config (with <mtu size='n'/>), set the MTU of a
libvirt network in the network config (with the same named
subelement), and would automatically set the MTU of any tap device to
the MTU of the network.

This patch ties that all together (for networks based on tap devices
and either Linux host bridges or OVS bridges) by learning the MTU of
the network (i.e. the bridge) during qemuInterfaceBridgeConnect(), and
returning that value so that it can then be passed to
qemuBuildNicDevStr(); qemuBuildNicDevStr() then sets host_mtu in the
interface's commandline options.

The result is that a higher MTU for all guests connecting to a
particular network will be plumbed top to bottom by simply changing
the MTU of the network (in libvirt's config for libvirt-managed
networks, or directly on the bridge device for simple host bridges or
OVS bridges managed outside of libvirt).

One question I have about this - it occurred to me that in the case of
migrating a guest from a host with an older libvirt to one with a
newer libvirt, the guest may have *not* had the host_mtu option on the
older machine, but *will* have it on the newer machine. I'm curious if
this could lead to incompatibilities between source and destination (I
guess it all depends on whether or not the setting of host_mtu has a
practical effect on a guest that is already running - Maxime?)

Likewise, we could run into problems when migrating from a newer
libvirt to older libvirt - The guest would have been told of the
higher MTU on the newer libvirt, then migrated to a host that didn't
understand <mtu size='blah'/>. (If this really is a problem, it would
be a problem with or without the current patch).

The current ordering is as follows:
1) set label
2) create the device in namespace
3) allow device in the cgroup

While this might work for now, it will definitely not work if the
security driver would use transactions as in that case there
would be no device to relabel in the domain namespace as the
device is created in the second step.
Swap steps 1) and 2) to allow security driver to use more
transactions.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1375410