There's no argument named @result, use @matches instead.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
These are already exported at header file level because of
VIR_ENUM_DECL being in numa_conf.h. However, they are not being
exported at object level because of missing libvirt_private.syms
record.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
QEMU 2.7 and newer don't allow guests to start unless the initial
vCPUs count is a multiple of the vCPU hotplug granularity, so
validate it and report an error if needed.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1283700
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
While at the moment we're only performing a single check that is
connected to vCPU hotplugging, we're going to introduce a second
one soon. Move the topology check underneath the capability check
to make that easier; since, after this change, the 'topologycpus'
variable doesn't need to have function scope, we move its
declaration to the inner scope as well.
The comments around the check are modified in order to explain
the different QEMU versions involved.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Similar to qemuDomainAddChardevTLSObjects let's move the chardev
source must be TCP and it has the @haveTLS flag set checks before
trying to delete the TLS objects.
For the Chr device this represents no change; however, for RNG device
this is an additionaly check that was missed in commit id '68808516'.
Before adding the objects, TCP and haveTLS are checked.
Let's make a comment deletion helper similar to the Add helper
that can be called after the ExitMonitor.
The modify qemuDomainRemoveChrDevice and qemuDomainRemoveRNGDevice
to call the helper instead of inlining the copy and pasted code.
So far clients were closed when disposing the daemon, after the state
driver cleanup. This was leading to libvirtd crashing at shutdown due
to missing driver.
Moving the client close in virNetServerClose() fixes the problem.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Prior to this change, we relied solely on the inherited readonly
attribute of a service's socket. This only worked for our UNIX sockets
(and only to some degree), but doesn't work for TCP sockets which are RW
by default, but such connections support RO as well. This patch forces
an update on the client object once we have established a connection to
reflect the nature of the connection itself rather than relying on the
underlying socket's attributes.
Clients connected to the admin server have always been connected as RW
only.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1524399
Signed-off-by: Erik Skultety <eskultet@redhat.com>
ebtables/iptables processing is skipped for any interface connected to
Open vSwitch (they have their own packet filtering), likewise for
midonet (according to
http://blog.midokura.com/2016/04/midonet-rule-chains), but libvirt
would allow adding a <filterref> to interfaces connected in these
ways, so the user might mistakenly believe they were being protected.
This patch checks for a non-NULL <virtualport> element for an
interface (or its network) and logs an error if <virtualport> and
<filterref> are both present. This could cause some previously working
domains to no longer start, but that's really the whole point of this
patch - to warn people that their filterref isn't protecting them as
they might have thought.
I don't bother checking this during post-parse validation, because
such a check would be incomplete - it's possible that a network would
have a <virtualport> that would be applied to an interface, and you
can't know that until the domain is started.
Resolves: https://bugzilla.redhat.com/1502754
When the <bandwidth> of an interface is changed with update-device,
the old settings are cleared with tc, then new settings added with
tc. But if the <bandwidth has been removed, the old settings weren't
being removed, so the bandwidth restrictions would still be active on
the interface although the interface status in libvirt showed that
they had been removed.
This patch fixes it by calling virNetDevBandwidthClear() if the
"modification" to the interface bandwidth was to completely clear
it.
An alternative could have been to modify virNetDevBandwidthSet() to
always clear existing bandwith settings at the beginning of the
function (currently it short circuits in that case, doing nothing),
but that would have led to cases where virNetDevBandwidthClear() was
now being called in cases where it previously wasn't, and while many
of those cases would be NOPs, there could be cases where it would
cause an error. The way this patch works, the ...Clear() function is
only called in cases where the ...Set() function had previously been
called successfully, so the risk of regression is minimized.
Resolves: https://bugzilla.redhat.com/1454709
Also call qemuDomainRemoveInputDevice if we receive the
event after the Detach API ends.
Commit 67486bb failed to include this.
https://bugzilla.redhat.com/show_bug.cgi?id=1524837
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
VM drivers may need to store additional private data to the status XML
so that it can be restored after libvirtd restart. Since not everything
is needed add a callback infrastructure, where VM drivers can add only
stuff they need.
Note that the private data is formatted as a <privateData> sub-element
of the <disk> or <backingStore> <source> sub-element. This is done since
storing it out of band (in the VM private data) would require a complex
matching process to allow to put the data into correct place.
https://bugzilla.redhat.com/show_bug.cgi?id=1523564
If the vhost-scsi device file cannot be found, the generic error
"error: An error occurred, but the cause is unknown"
is returned. Let's add a real error message to make it clear
why the failure occurred.
We cannot be sure someone initialized the passed *vhostfd and we
certainly don't want or need to be calling VIR_FORCE_CLOSE on what
probably is -1. So let's just return -1 immediately.
Commit id '70249927b' neglected to cover this case because the test
had taken the "shortcut" to already add the <address>; however, when
the PCI address assignment code was adjusted by commit id '70249927'
the vhost-scsi (VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI_HOST) wasn't
covered thus returning a 0 for pciFlags. So I altered the tests too
to make sure it doesn't happen again.
Previously the qemuxml2xmloutdata was a softlink to the source
qemuxml2argvdata, so I unlinked and recreated the output file to
force generation of the adddress. Without the test changes, an
address generation returns:
libvirt: Domain Config error : internal error: Cannot automatically
add a new PCI bus for a device with connect flags 00
if an address was supplied in the test, a restart of libvirtd or
edit of a guest would display the following opaque message:
warning : qemuDomainCollectPCIAddress:1237 :
qemuDomainDeviceCalculatePCIConnectFlags() thinks that the device
with PCI address 0000:00:09.0 should not have a PCI address
where the address is related to the guest PCI address provided.
virStringSplit may return NULL, so we must handle that.
Cc: John Ferlan <jferlan@redhat.com>
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Remove the unnecessary clearing of address_array as VIR_ALLOC_N
initialized the array already.
Cc: John Ferlan <jferlan@redhat.com>
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Commit id 'c5c96545' neglected to validate that the srcPriv was
non-NULL before dereferencing. Similar problem to what was fixed
by commit id '8056721c' but missed during multiple rebases and
code reworks.
Now that we have a private storage pool list, we can take the next
step and convert to using objects. In this case, we're going to use
RWLockable objects (just like every other driver) with two hash
tables for lookup by UUID or Name.
Along the way the ForEach and Search API's will be adjusted to use
the related Hash API's and the various FindBy functions altered and
augmented to allow for HashLookup w/ and w/o the pool lock already
taken.
After virStoragePoolObjRemove we will need to virObjectUnref(obj)
after to indicate the caller is "done" with it's reference. The
Unlock occurs during the Remove.
The NumOf, GetNames, and Export functions all have their own callback
functions to return the required data and the FindDuplicate code
can use the HashSearch function callbacks.
Commit id '5ab746b8' introduced the function as perhaps a copy
of storageVolLookupByPath; however, it did not use the @cleanpath
variable even though it used the virFileSanitizePath. So in essance
the only "check" being done for failure is whether it was possible
to strdup the path.
Looking at the virStoragePoolDefParseXML one will note that the
target.path is stored using the result of virFileSanitizePath.
Therefore, this function should sanitize and use the input @path
for the argument to storagePoolLookupByTargetPathCallback which
is comparing against stored target.path values.
Additionally, if there was an error we should use the proper error
of VIR_ERR_NO_STORAGE_POOL (instead of VIR_ERR_NO_STORAGE_VOL).
Replace the error message during startup of libvirtd with an info
message if audit_level < 2 and audit is not supported by the
kernel. Audit is not supported by the current kernel if the kernel
does not have audit compiled in or if audit is disabled (e.g. by the
kernel cmdline).
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
==32171== 32 bytes in 1 blocks are definitely lost in loss record 44 of 107
==32171== at 0x4C2DEF6: calloc (vg_replace_malloc.c:711)
==32171== by 0x55744A9: virAllocN (viralloc.c:191)
==32171== by 0x12CED2: xenMakeIPList (xen_common.c:1186)
==32171== by 0x12D0BE: xenFormatNet (xen_common.c:1221)
==32171== by 0x12F0D2: xenFormatVif (xen_common.c:1889)
==32171== by 0x12F2B4: xenFormatConfigCommon (xen_common.c:1944)
==32171== by 0x13BA32: xenFormatXL (xen_xl.c:1971)
==32171== by 0x1186CA: testCompareParseXML (xlconfigtest.c:105)
==32171== by 0x118A64: testCompareHelper (xlconfigtest.c:205)
==32171== by 0x119E36: virTestRun (testutils.c:180)
==32171== by 0x11970E: mymain (xlconfigtest.c:301)
==32171== by 0x11BEE3: virTestMain (testutils.c:1119)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
==30399== 180 (144 direct, 36 indirect) bytes in 3 blocks are definitely lost in loss record 91 of 111
==30399== at 0x4C2E0FF: realloc (vg_replace_malloc.c:785)
==30399== by 0x5574572: virReallocN (viralloc.c:245)
==30399== by 0x5574668: virExpandN (viralloc.c:294)
==30399== by 0x55747AB: virResizeN (viralloc.c:352)
==30399== by 0x560074D: virStringSplitCount (virstring.c:115)
==30399== by 0x137A59: xenParseXLVnuma (xen_xl.c:442)
==30399== by 0x13952B: xenParseXL (xen_xl.c:1064)
==30399== by 0x11884D: testCompareFormatXML (xlconfigtest.c:152)
==30399== by 0x118A87: testCompareHelper (xlconfigtest.c:207)
==30399== by 0x119E36: virTestRun (testutils.c:180)
==30399== by 0x119186: mymain (xlconfigtest.c:274)
==30399== by 0x11BEE3: virTestMain (testutils.c:1119)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
ncpus would be -1 on error and the cleanup for loop would not be skipped
in this case.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1522706
If domain is active, but the undefine API was called without the
VIR_DOMAIN_UNDEFINE_KEEP_NVRAM flag set, the following incorrect
error message is produced:
error: Requested operation is not valid: cannot delete inactive domain with nvram
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Move the IDE controller check from command line building to
controller def validation. Also explicitly include the avoidance
check for the implicit IDE controller from qemuBuildSkipController.
Cause the IDE case for command line building to generate a
failure if called to add an IDE since that shouldn't happen
if the Validate code did the right thing.
Move the call to qemuDomainCheckCCWS390AddressSupport from
qemuBuildControllerDevStr to qemuDomainDeviceDefValidateController.
This means we will get the qemuCaps from the driver opaque
variable passed to qemuDomainDeviceDefValidate.
Xen's xl config format has long supported specifying multiple IP
addresses for virtual interfaces. E.g.
vif = [ "ip=10.0.0.1 10.1.1.1 2000::1, ..." ]
Add support for converting multiple IP addresses to/from domXML.
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
vif-* scripts support it for a long time, and expect addresses to be
separated by spaces. Add appropriate support to libxl driver.
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
When reconnecting to a running domain started by old libvirt, which did
not change host-model into a custom CPU definition, we replace the CPU
definition with a specific CPU model from host capabilities. However,
that CPU model may not be supported by the running qemu process. We need
to translate the CPU model to one of the models which libvirt could have
used when starting the domain.
https://bugzilla.redhat.com/show_bug.cgi?id=1521202
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
virQEMUCapsProbeQMPCPUDefinitions is now a small wrapper which fills in
qemuCaps with CPU models fetched by virQEMUCapsFetchCPUDefinitions.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Since we are re-detecting the backing chain after pivoting to the active
block commit target (or block copy target) the disk index needs to be
reset to 0. This is necessary since we move a member of the backing
chain to disk->src but clear indexes only starting from
disk->src->backingStore. The freshly detected images have indexes
starting from 1, but since we've pivoted into an image which was
previously a backing store it would have a non-0 index.
The lookup function would then return the top of the chain for queries
like 'vda[1]' instead of the first backing store.
This problem will not be present once we keep the disk indexes stable.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1519745
Since commit 5e5019bf, we've no longer use
VIR_ERR_AGENT_UNSYNCED anymore.
Mark it as DEPRECATED.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
virStorageFileReportBrokenChain uses data from the driver private data
pointer to print the user and group. This would lead to a crash in call
paths where we did not initialize the storage backend as recently added
in commit 24e47ee2b9 to qemuDomainDetermineDiskChain.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1522682
Separate the logic of creating devices from their gathering.
Use this new function in qemuDomainNamespaceSetupHostdev and
qemuDomainNamespaceSetupDisk.
This patch pass event error up to the place where we can
use it. Error is passed only for sync blockjob event mode
as we can't use the error in async mode. In async mode we
just pass the event details to the client thru event API
but current blockjob event API can not carry extra parameter.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The unprivileged libvirtd does not support nwfilter config, by leaves the
driver active. It is supposed to result in all APIs being an effective
no-op, but several APIs rely on driver->nwfilters being non-NULL, or they
will reference a NULL pointer. Rather than adding checks for NULL in many
places, just make sure driver->nwfilters is always initialized.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
SELinux and DAC drivers already have both functions but they were not
exported as public API of security manager.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The manual page clearly states that
gettid() is Linux-specific and should not be used in programs
that are intended to be portable.
Unfortunately, it looks like macOS implemented the functionality
and defined SYS_gettid accordingly, only to deprecate syscall()
altogether with 10.12 (Sierra), released last late year.
To avoid compilation errors, call gettid() on Linux only.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Clean up the style a bit w/r/t to not using a unary operator on an
integer value that could be zero - compare vs. zero instead.
Set the def->mem_nodes[*].distances to rdist or ldist inside the
if condition - no need to set outside since the value being set
to is what was fetched.
During cleanup, be sure to initialize the ndistances on error and
use the < 0 comparison not the unary one.
==899== 39 bytes in 1 blocks are definitely lost in loss record 732 of 1,003
==899== at 0x4C2AEDF: malloc (vg_replace_malloc.c:299)
==899== by 0x8B68CE7: vasprintf (in /lib64/libc-2.25.so)
==899== by 0x55498D2: virVasprintfInternal (virstring.c:708)
==899== by 0x55499E7: virAsprintfInternal (virstring.c:729)
==899== by 0x2BECFFF0: qemuGetMemoryBackingBasePath (qemu_conf.c:1757)
==899== by 0x2BF23225: qemuStateInitialize (qemu_driver.c:893)
==899== by 0x563073D: virStateInitialize (libvirt.c:770)
==899== by 0x124CC4: daemonRunStateInit (libvirtd.c:834)
==899== by 0x55521CD: virThreadHelper (virthread.c:206)
==899== by 0x88D9686: start_thread (in /lib64/libpthread-2.25.so)
==899== by 0x8BEAEFE: clone (in /lib64/libc-2.25.so)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
==1277== 8 bytes in 4 blocks are definitely lost in loss record 39 of 131
==1277== at 0x4C2AEDF: malloc (vg_replace_malloc.c:299)
==1277== by 0x68BBBC8: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
==1277== by 0x53B1DC2: virXMLPropString (virxml.c:510)
==1277== by 0x53D696A: virDomainDiskBackingStoreParse (domain_conf.c:8639)
==1277== by 0x53DA684: virDomainDiskDefParseXML (domain_conf.c:9590)
==1277== by 0x53F619F: virDomainDefParseXML (domain_conf.c:19233)
==1277== by 0x53F96EE: virDomainDefParseNode (domain_conf.c:20083)
==1277== by 0x53F9540: virDomainDefParse (domain_conf.c:20027)
==1277== by 0x53F95E6: virDomainDefParseFile (domain_conf.c:20053)
==1277== by 0x44D1D4: testCompareDomXML2XMLFiles (testutils.c:1265)
==1277== by 0x42FC7C: testXML2XMLActive (qemuxml2xmltest.c:71)
==1277== by 0x44AD20: virTestRun (testutils.c:180)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
==861== 3 bytes in 1 blocks are definitely lost in loss record 3 of 168
==861== at 0x4C2AEDF: malloc (vg_replace_malloc.c:299)
==861== by 0x8C7FBC8: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
==861== by 0x5DCCDC2: virXMLPropString (virxml.c:510)
==861== by 0x5DF1232: virDomainDiskSourceNetworkParse (domain_conf.c:8445)
==861== by 0x5DF1728: virDomainDiskSourceParse (domain_conf.c:8576)
==861== by 0x5DF41A5: virDomainDiskDefParseXML (domain_conf.c:9238)
==861== by 0x5E1119F: virDomainDefParseXML (domain_conf.c:19233)
==861== by 0x5E146EE: virDomainDefParseNode (domain_conf.c:20083)
==861== by 0x5E14540: virDomainDefParse (domain_conf.c:20027)
==861== by 0x5E145E6: virDomainDefParseFile (domain_conf.c:20053)
==861== by 0x4053CC: testCompareXMLToArgv (qemuxml2argvtest.c:455)
==861== by 0x41F135: virTestRun (testutils.c:180)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Raw local files do not pass through the backing store detector and thus
the code did not allocate the required backing store terminator for
them. Previously the terminating element would be formatted into the XML
since the default values used for the metadata allowed that. This is a
regression since a693fdba01 which was not detected in the review.
This patch also reverts all the changes in the test files.
Until now we would skip loading of the backing chain for files which
don't support backing chains only when starting up the VM. Move the
check from qemuProcessPrepareHostStorage with some adaptations so that's
always applied.
The graphics code is complex and there are a lot of exceptions and
backward compatible combinations. One of them is the possibility
to configure "spice_auto_unix_socket" in qemu.conf which will convert
all spice graphics with listen type "address" without any address
specified to listen type "socket" when the guest is started.
We don't format this generated socket into migratable XML to make
migration work with older libvirt. However, spice has another
exception that if autoport='no' and there is no port configured
it is converted to listen type "none". Because of this we need
to format autoport='yes' to make sure that the listen type will
be the same as the offline XML.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1511407
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
In status XML, we do not store the QEMU version information, we only
format all the capabilities. We dropped QEMU_CAPS_PCI_MULTIBUS
in commit 5b783379 which was released in libvirt 3.2.0.
Therefore the only way of telling if the already running domain
at the time of daemon restart has been started with a QEMU that does
use 'pci.0' or not on PPC is to look at the pci-root controller's
alias. This is not an option if the domain has a user-specified alias
for the pci-root.
Instead of reintroducing the capability, assume 'pci.0' when we have
no version information. That way the only left broken use case would
be the combination of user aliases and very old QEMU.
Partially reverts commit 3a37af1e4.
https://bugzilla.redhat.com/show_bug.cgi?id=1518148
We do not fill out qemuCaps->arch when parsing status XML.
Use def->os.arch like we do for PPC.
This fixes hotplug after daemon restart for domains that use
a user alias for the implicit pci-root on x86.
https://bugzilla.redhat.com/show_bug.cgi?id=1518148
For some corner cases, virQEMUCapsHasPCIMultiBus depends on the QEMU
version, which is by design not stored in the status XML and therefore
it cannot be fixed for all existing running domains.
Prefer the controller alias read from the status XML when formatting
PCI addresses and only fall back to using virQEMUCapsHasPCIMultiBus
if the alias is a user alias.
This fixes hotplug after daemon restart for domains not using user
aliases.
Partially reverts commit 937f3195.
https://bugzilla.redhat.com/show_bug.cgi?id=1518148
Adjust function descriptions of virQEMUCapsInitCPUModelS390 and
virQEMUCapsInitCPUModel to the changes introduced with
commitID 74fc32a955.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Even though we never format the device on the QEMU command line,
as it's a platform serial device that's not user-instantiable,
we should still make sure it's available before using it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
All serial devices shoule have an associated capability.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We should make sure the isa-serial device is available before
formatting it on the QEMU command line.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
All serial devices shoule have an associated capability.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Now that <serial> and <console> on s390/s390x behave a bit more like the
other architectures, remove this extra differentation, and use sclp
console by default for new guests. New virtio consoles can still be
added, and it is actually needed because of the limited number of
instances for sclp and sclplm.
This reverts commit b1c88c1476, whose
reasons are not totally clear.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Introduce specific a target types with two models for the console
devices (sclp and sclplm) used in s390 and s390x guests, so isa-serial
is no more used for them.
This makes <serial> usable on s390 and s390x guests, with at most only
a single sclpconsole and one sclplmconsole devices usable in a single
guest (due to limitations in QEMU, which will enforce already at
runtime).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1449265
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We can finally introduce a specific target model for the pl011 device
used by mach-virt guests, which means isa-serial will no longer show
up to confuse users.
We make sure migration works in both directions by interpreting the
isa-serial target type, or the lack of target type, appropriately
when parsing the guest XML, and skipping the newly-introduced type
when formatting if for migration. We also verify that pl011 is not
used for non-mach-virt guests and add a bunch of test cases.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=151292
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The existing implementation set the address type for all serial
devices to spapr-vio, which made it impossible to use other devices
such as usb-serial and pci-serial; moreover, some decisions were
made based on the address type rather than the device type.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1512934
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We can finally introduce a specific target model for the spapr-vty
device used by pSeries guests, which means isa-serial will no longer
show up to confuse users.
We make sure migration works in both directions by interpreting the
isa-serial target type, or the lack of target type, appropriately
when parsing the guest XML, and skipping the newly-introduced type
when formatting if for migration. We also verify that spapr-vty is
not used for non-pSeries guests and add a bunch of test cases.
This commit is best viewed with 'git show -w'.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1511421
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Instead duplicating the capability check for each possible target
model, introduce a small helper that matches the target model with
the corresponding capability and collapse all existing checks into
a single one.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Now that we've created a distinction between target type and target
model, with the latter being the concrete device name, it's time to
switch to formatting the model instead of the type.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Target model and target type must agree for the configuration
to make sense, so check that's actually the case and error out
otherwise.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This information will be used to select, and store in the guest
configuration in order to guarantee ABI stability, the concrete
(hypervisor-specific) model for serial devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Instead of validating each target type / address type combination
separately, create a small helper to perform the matching and
collapse all existing checks into a single one.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Instead of waiting until we get to command line generation, we can
validate the target for a char device much earlier.
Move all the checks out of qemuBuildSerialChrDeviceStr() and into
the new fuction. This will later allow us to validate the target
for platform devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Formatting the <target/> element for serial devices will become a
bit more complicated later on, and leaving the fallthrough behavior
there would do nothing but complicate it further.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Make the switch statement type-aware, avoid calling
virDomainChrTargetTypeToString() more than once and check its
return value before using it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The function can fail, but none of the caller were accounting
for that.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We don't need to store the return value since we never modify it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Move formatting of the <target/> element for char devices out of
virDomainChrDefFormat() and into its own function.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This attribute was used to decide whether to format the type
attribute of the <target> element, but the logic didn't take into
account all possible cases and as such could lead to unexpected
results. Moreover, it's one more thing to keep track of, and can
easily fall out of sync with other attributes.
Now that we have VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_NONE, we can
use that value to signal that no specific target type has been
configured for the serial device and as such the attribute should
not be formatted at all. All other values are now formatted.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This is the first step in getting rid of the assumption that
isa-serial is the default target type for serial devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The devicePostParse() callback is invoked for all devices so that
drivers have a chance to set their own specific values; however,
virDomainDefAddImplicitDevices() runs *after* the devicePostParse()
callbacks have been invoked and can add new devices, in which case
the driver wouldn't have a chance to customize them.
Work around the issue by invoking the devicePostParse() callback
after virDomainDefAddImplicitDevices(), only for the first serial
devices, which might have been added by it. The same was already
happening for the first video device for the very same reason.
This will become important later on, when we will change
virDomainDefAddConsoleCompat() not to set a targetType for
automatically added serial devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Having a separate function for char device handling is better than
adding even more code to qemuDomainDeviceDefPostParse().
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1425757
The blockdev-add code provides a mechanism to sanely provide user
and password-secret arguments for iscsi without placing them on the
command line to be viewable by a 'ps -ef' type command or needing
to create separate -iscsi devices for each disk/volume found.
So modify the iSCSI command line building to check for the presence
of the capability in order properly setup and use the domain master
secret object to encrypt the password in a secret object and alter
the parameters for the command line to utilize.
Modify the xml2argvtest to exhibit the syntax for both disk and
hostdev configurations.
