This is required for following patches where new listen types will be
introduced.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

We have both in the code.  Let's use only one format.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

For some disk types (SD), we want to emit the syntax
we used for disks before -device was available even
if QEMU supports -device.

Use the qemuDiskBusNeedsDeviceArg helper to figure out
whether to use the old or new syntax.

Replace the two uses of the withDeviceArg bool in
qemuBuildDiskDriveCommandLine and allow this function to be reused in
qemuBuildDriveStr.

We no longer need to handle -usbdevice and the withDeviceArg
logic becomes clearer.

We have stopped supporting Xenner some time ago.

Since we always asumme support of QEMU_CAPS_DEVICE.

The only QEMU versions that don't have such capability are <0.11,
which we no longer support anyway

The only QEMU versions that don't have such capability are <0.11,
which we no longer support anyway

The only QEMU versions that don't have such capability are <0.12,
which we no longer support anyway.

Additionally, this solves the issue of some QEMU binaries being
reported as not having such capability just because they lacked
the {kvm-}pci-assign QMP object.

-name guest= is the explicit parameter for passing a VM name. Using
it is required to allow a VM with an '=' in the name

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

After this, a default virt-manager VM will startup with a comma
in the VM name:

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

This path can be dependent on the VM libdir, which contains its name

Need to convert the local function to virBuffer usage, so we
can use qemuBufferEscapeComma

This isn't sufficient on its own, since the VM name is used for things
like monitor paths, which we don't escape yet

Centralize the magic invocation for escaping commas on the qemu
command line, and document it a bit

QEMU_CAPS_DEVICE is always set nowadays, so we can drop the
non-DEVICE code paths

Rather than returning a "char *" indicating perhaps some sized set of
characters that is NUL terminated, alter the function to return 0 or -1
for success/failure and add two parameters to handle returning the
buffer and it's size.

The function no longer encodes the returned secret, rather it returns
the unencoded secret forcing callers to make the necessary adjustments.

Alter the callers to handle the adjusted model.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The preferred name will be AES not IV, change current references
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This matches how we handle spice gl='no' even if spice GL isn't
supported. Not too interesting in practice but I figure we should
be consistent

Extract the relevant parts of the existing checker and reuse them for
blockcopy since copying to a non-block device creates an invalid
configuration.

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

In qemuCheckDiskConfig would now use virDomainDiskSourceIsBlockType just
as a glorified version of virStorageSourceIsBlockLocal that reports
error messages. Replace it with the latter including the message for
clarity.

Commit c820fbff added support for iSCSI
disk as backing for <disk device='lun'>. We would not use it for a disk
type="volume" with direct access mode which basically maps to direct
iSCSI usage. Fix it by adding the storage source type accessor that
resolves the volume type.

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Add the data structure and infrastructure to support an initialization
vector (IV) secrets. The IV secret generation will need to have access
to the domain private master key, so let's make sure the prepare disk
and hostdev functions can accept that now.

Anywhere that needs to make a decision over which secret type to use
in order to fill in or use the IV secret has a switch added.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Create helper API's in order to build the network URI as shortly we will
be adding a new SecretInfo type
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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

Now that we have all the pieces in place, we can add the 'iothread=#' to
the command line for the (two) controllers that support it (virtio-scsi-pci
and virtio-scsi-ccw). Add the tests as well...

Rather than an if statement, use a switch.

The switch will also catch the illegal usage of 'iothread' with some other
kind of unsupported bus configuration.

This adds a ports= attribute to usb controller XML, like

  <controller type='usb' model='nec-xhci' ports='8'/>

This maps to:

  qemu -device nec-usb-xhci,p2=8,p3=8

Meaning, 8 ports that support both usb2 and usb3 devices. Gerd
suggested to just expose them as one knob.

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

Use it everywhere except for virQEMUCapsFillDomainFeatureGICCaps.

If a panic device is being defined without a model in a domain
the default value is always overwritten with model ISA. An ISA
bus does not exist on S390 and therefore specifying a panic device
results in an unsupported configuration.
Since the S390 architecture inherently provides a crash detection
capability the panic device should be defined in the domain xml.

This patch adds an s390 panic device model and prevents setting a
device address on it.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>

Adding the default bus type ISA to the message.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

Rather than take username and password as parameters, now take
a qemuDomainSecretInfoPtr and decode within the function.

NB: Having secinfo implies having the username for a plain type
    from a successful virSecretGetSecretString
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Similar to the qemuDomainSecretDiskPrepare, generate the secret
for the Hostdev's prior to call qemuProcessLaunch which calls
qemuBuildCommandLine. Additionally, since the secret is not longer
added as part of building the command, the hotplug code will need
to make the call to add the secret in the hostdevPriv.

Since this then is the last requirement to pass a virConnectPtr
to qemuBuildCommandLine, we now can remove that as part of these
changes. That removal has cascading effects through various callers.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than needing to pass the conn parameter to various command
line building API's, add qemuDomainSecretPrepare just prior to the
qemuProcessLaunch which calls qemuBuilCommandLine. The function
must be called after qemuProcessPrepareHost since it's expected
to eventually need the domain masterKey generated during the prepare
host call. Additionally, future patches may require device aliases
(assigned during the prepare domain call) in order to associate
the secret objects.

The qemuDomainSecretDestroy is called after the qemuProcessLaunch
finishes in order to clear and free memory used by the secrets
that were recently prepared, so they are not kept around in memory
too long.

Placing the setup here is beneficial for future patches which will
need the domain masterKey in order to generate an encrypted secret
along with an initialization vector to be saved and passed (since
the masterKey shouldn't be passed around).

Finally, since the secret is not added during command line build,
the hotplug code will need to get the secret into the private disk data.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit 98c5c53d partially reverted the effort to use typecasted enums
for compiler notification. Turn it back.

Similarly to what commit 71408079 did with some internal paths,
clear vnc socket paths that were generated by us.  Having such path in
the definition can cause trouble when restoring the domain.  The path is
generated to the per-domain directory that contains the domain ID.
However, that ID will be different upon restoration, so qemu won't be
able to create that socket because the directory will not be prepared.

To be able to migrate to older libvirt, skip formatting the socket path
in migratable XML if it was autogenerated.  And mark it as autogenerated
if it already exists and we're parsing live XML.

Best viewed with '-C'.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1326270Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

QEMU_BLOCK_IOTUNE_MAX is the maximum inclusively, so let's modify the
message so it makes sense.

https://bugzilla.redhat.com/show_bug.cgi?id=1329041Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The values are currently limited to LLONG_MAX which causes some
problems.  QEMU conveniently changed their maximum to 1e15 (1 PB) which
is enough for some time and we need to adapt to that so that we don't
throw "Unknown error" messages.  Strictly limiting these values actually
fixes some corner case values (off-by-one checks in QEMU probably).

Since values out of the new specified range do not overflow anything,
change the type of error as well.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1317531Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>