Commit Graph

629 Commits

Author SHA1 Message Date
Jiri Denemark
3c7059528d tests: Remove qemuxmlnstest
It's just a copy&paste of qemuxml2argv test anyway. We can test most of
them (except for qemuxmlns-qemu-ns-domain.xml which fails to validate
against our schema) by qemuxml2argv test.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-11-11 17:02:53 +01:00
Pavel Hrdina
fc03eb53c0 domain-conf: reorder usb controllers so the master is first
USB controllers can share the same 'index' which indicates, that there
is some sort of master-companion relationship.  Reorder the controllers
in XML in to place the master controller before its companions.  This is
required by QEMU to not fail with error message:

error: internal error: process exited while connecting to monitor:
2015-10-26T16:25:17.630265Z qemu-system-x86_64:
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6:
USB bus 'usb.0' not found

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

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2015-11-11 15:30:49 +01:00
Daniel P. Berrange
4e8993a250 qemu: assume various QEMU 0.10 features are always available
The -sdl and -net ...name=XXX arguments were both introduced
in QEMU 0.10, so the QEMU driver can assume they are always
available.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:18 +00:00
Daniel P. Berrange
72edc90a65 qemu: assume -vga is always available
As of QEMU 0.10.0 the -vga argument was introduced, so the
QEMU driver can assume it is always available.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:17 +00:00
Daniel P. Berrange
f81e0d480e qemu: assume -drive format is always available
As of QEMU 0.10.0 the -drive format= parameter was added,
so the QEMU driver can assume it is always available.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:17 +00:00
Daniel P. Berrange
468273a69c qemu: assume -drive cache always uses v2 option names
As of QEMU 0.10.0, the -drive cache option stopped using
the on/off value names, so the QEMU driver can assume
use of the new value names.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:17 +00:00
Daniel P. Berrange
2e90c9daf9 qemu: assume support for all migration protocols except rdma
Since we require QEMU 0.12.0, we can assume that QEMU supports
all of the fd, tcp, unix and exec migration protocols.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:17 +00:00
Daniel P. Berrange
257e2056e7 qemu: really remove last traces of Xenner support
We have twice previously attempted to remove Xenner
support

  commit de9be0ab4d
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Wed Aug 22 17:29:01 2012 +0100

    Remove xenner support

  commit 92572c3d71
  Author: Ján Tomko <jtomko@redhat.com>
  Date:   Wed Feb 18 16:33:50 2015 +0100

    Remove code handling the QEMU_CAPS_DOMID capability

This change really does remove the last traces of it
in the capabilities handling code

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:15 +00:00
Daniel P. Berrange
dc7f6c3d30 qemu: assume -uuid is always available
The -uuid arg was added in QEMU 0.10.0, so the QEMU driver can
assume it is always available.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:02 +00:00
Daniel P. Berrange
4588c2ce97 qemu: assume -name is always available
The -name arg was added in QEMU 0.9.1, so the QEMU driver can
assume it is always available.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:02 +00:00
Daniel P. Berrange
f78610038d qemu: assume -drive argument is always available
As of QEMU 0.9.1 the -drive argument can be used to configure
all disks, so the QEMU driver can assume it is always available
and drop support for -hda/-cdrom/etc.

Many of the tests need updating because a great many were
running without CAPS_DRIVE set, so using the -hda legacy
syntax.

Fixing the tests uncovered a bug in the argv -> xml
convertor which failed to handle disk with if=floppy.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:01 +00:00
Daniel P. Berrange
8afd34f2d8 tests: redo test argv file line wrapping
Back in

  commit bd6c46fa0c
  Author: Juerg Haefliger <juerg.haefliger@hp.com>
  Date:   Mon Jan 31 06:42:57 2011 -0500

    tests: handle backspace-newline pairs in test input files

all the test argv files were line wrapped so that the args
were less than 80 characters.

The way the line wrapping was done turns out to be quite
undesirable, because it often leaves multiple parameters
on the same line. If we later need to add or remove
individual parameters, then it leaves us having to redo
line wrapping.

This commit changes the line wrapping so that every
single "-param value" is one its own new line. If the
"value" is still too long, then we break on ',' or ':'
or ' ' as needed.

This means that when we come to add / remove parameters
from the test files line, the patch diffs will only
ever show a single line added/removed which will greatly
simplify review work.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-09 15:50:39 +00:00
John Ferlan
cc2d49f9be qemu: Fix qemu startup check for QEMU_CAPS_OBJECT_IOTHREAD
https://bugzilla.redhat.com/show_bug.cgi?id=1249981

When qemuDomainPinIOThread was added in commit id 'fb562614', a check
for the IOThread capability was not needed since a check for iothreadpids
covered the condition where the support for IOThreads was not present.
The iothreadpids array was only created if qemuProcessDetectIOThreadPIDs
was able to query the monitor for IOThreads. It would only do that if
the QEMU_CAPS_OBJECT_IOTHREAD capability was set.

However, when iothreadids were added in commit id '8d4614a5' and the
check for iothreadpids was replaced by a search through the iothreadids[]
array for the matching iothread_id that left open the possibility that
an iothreadids[] array was defined, but the entries essentially pointed
to elements with only the 'iothread_id' defined leaving the 'thread_id'
value of 0 and eventually the cpumap entry of NULL.

This was because, the original IOThreads commit id '72edaae7' only
checked if IOThreads were defined and if the emulator had the IOThreads
capability, then IOThread objects were added at startup. The "capability
failure" check was only done when a disk was assigned to an IOThread in
qemuCheckIOThreads. This was because the initial implementation had no way
to dynamically add IOThreads, but it was possible to dynamically add a
disk to the domain. So the decision was if the domain supported it, then
add the IOThread objects. Then if a disk with an IOThread defined was
added, it could check the capability and fail to add if not there. This
just meant the 'iothreads' value was essentially ignored.

Eventually commit id 'a27ed6e7' allowed for the dynamic addition and
deletion of IOThread objects. So it was no longer necessary to generate
IOThread objects to dynamically attach a disk to. However, the startup
and disk check code was not modified to reflect this.

This patch will move the capability failure check to when IOThread
objects are being added to the command line. Thus a domain that has
IOThreads defined will not be started if the emulator doesn't support
the capability. This means when qemuCheckIOThreads is called to add
a disk, it's no longer necessary to check the capability. Instead the
code can use the IOThreadFind call to indicate that the IOThread
doesn't exist.

Finally because it could be possible to have a domain running with the
iothreadids[] defined prior to this change if libvirtd is restarted each
having mostly empty elements, qemuProcessDetectIOThreadPIDs will check
if there are niothreadids when the QEMU_CAPS_OBJECT_IOTHREAD capability
check fails and remove the elements and array if it exists.

With these changes in place, it turns out the cputune-numatune test
was failing because the right bit wasn't set in the test. So used the
opportunity to fix that and create a test that would expect to fail
with some sort of iothreads defined and used, but not having the
correct capability.
2015-10-16 06:55:45 -04:00
Cole Robinson
1a83a068e4 tests: qemu: Add aarch64 virtio pci tests
- qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default
  to virtio-mmio even if qemu is new enough to support PCI
- qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
2015-10-06 10:27:10 -04:00
Martin Kletzander
7d19413955 tests: Check GIC-related XMLs in qemuxml2xmltest
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-10-06 15:10:36 +02:00
Peter Krempa
51a4178f24 conf: Remove <metadata> elements with no namespace
Our docs state that subelements of <metadata> shall have a namespace
and the medatata APIs expect that too. To avoid inaccessible
<metadata> sub-elements, just remove those that don't conform to the
documentation.

Apart from adding the new condition this patch renames the function and
refactors the code flow to allow the changes.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1245525
2015-10-06 13:36:12 +02:00
Martin Kletzander
41c2aa729f qemu: Use memory-backing-file only when needed
We are using memory-backing-file even when it's not needed, for example
if user requests hugepages for memory backing, but does not specify any
pagesize or memory node pinning.  This causes migrations to fail when
migrating from older libvirt that did not do this.  So similarly to
commit 7832fac847 which does it for
memory-backend-ram, this commit makes is more generic and
backend-agnostic, so the backend is not used if there is no specific
pagesize of hugepages requested, no nodeset the memory node should be
bound to, no memory access change required, and so on.

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

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-10-02 16:14:26 +02:00
Martin Kletzander
ad8ab88c91 qemu: Extract -mem-path building into its own function
That function is called qemuBuildMemPathStr() and will be used in
other places in the future.  The change in the test suite is proper due
to the fact that -mem-prealloc makes only sense with -mem-path (from
qemu documentation -- html/qemu-doc.html).

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-10-02 16:14:26 +02:00
Pavel Fedin
12a73cf14a qemu: Add test cases for gic-version option
These tests make sure that we can use this option only when the capability is
set.

Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
2015-10-02 16:14:26 +02:00
Peter Krempa
624ec1c2f9 qemu: Align memory module sizes to 2MiB
My original implementation was based on a qemu version that still did
not have all the checks in place. Using sizes that would align to odd
megabyte increments will produce the following error:

qemu-kvm: -device pc-dimm,node=0,memdev=memdimm0,id=dimm0: backend memory size must be multiple of 0x200000
qemu-kvm: -device pc-dimm,node=0,memdev=memdimm0,id=dimm0: Device 'pc-dimm' could not be initialized

Introduce an alignment retrieval function for memory devices and use it
to align the devices separately and modify a test case to verify it.
2015-09-23 13:54:54 +02:00
Peter Krempa
3b2db51430 test: Add test to validate that memory sizes don't get updated on migration 2015-09-22 16:09:28 +02:00
Peter Krempa
bd874b6c42 qemu: ppc64: Align memory sizes to 256MiB blocks
For some machine types ppc64 machines now require that memory sizes are
aligned to 256MiB increments (due to the dynamically reconfigurable
memory). As now we treat existing configs reasonably in regards to
migration, we can round all the sizes unconditionally. The only drawback
will be that the memory size of a VM can potentially increase by
(256MiB - 1byte) * number_of_NUMA_nodes.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1249006
2015-09-22 16:09:28 +02:00
Peter Krempa
c7d7ba85a6 qemu: command: Align memory sizes only on fresh starts
When we are starting a qemu process for an incomming migration or
snapshot reloading we should not modify the memory sizes in the domain
since we could potentially change the guest ABI that was tediously
checked before. Additionally the function now updates the initial memory
size according to the NUMA node size, which should not happen if we are
restoring state.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1252685
2015-09-22 16:09:28 +02:00
Luyao Huang
83ae3ee39b conf: fix crash when parsing a unordered NUMA <cell/>
https://bugzilla.redhat.com/show_bug.cgi?id=1260846

Introduced by 8fedbbdb, if we parse an unordered NUMA cell, will
get a segfault. This is because of a check for overlapping @cpus
sets we have there. However, since the array to hold guest NUMA
cells is allocated upfront and therefore it contains all zeros,
an out of order cell will break our assumption that cell IDs have
increasing character. At this point we try to access yet NULL
bitmap and therefore segfault.

Signed-off-by: Luyao Huang <lhuang@redhat.com>
2015-09-08 10:40:20 +02:00
Jonathan Toppins
5c668a78d8 qemu: add udp interface support
Adds a new interface type using UDP sockets, this seems only applicable
to QEMU but have edited tree-wide to support the new interface type.

The interface type required the addition of a "localaddr" (local
address), this then maps into the following xml and qemu call.

<interface type='udp'>
  <mac address='52:54:00:5c:67:56'/>
  <source address='127.0.0.1' port='11112'>
    <local address='127.0.0.1' port='22222'/>
  </source>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</interface>

QEMU call:
	-net socket,udp=127.0.0.1:11112,localaddr=127.0.0.1:22222

Notice the xml "local" entry becomes the "localaddr" for the qemu call.

reference:
http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.html

Signed-off-by: Jonathan Toppins <jtoppins@cumulusnetworks.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
2015-09-02 10:17:50 +02:00
Martin Kletzander
f1f68ca334 qemu: Fix access to auto-generated socket paths
We are automatically generating some socket paths for domains, but all
those paths end up in a directory that's the same for multiple domains.
The problem is that multiple domains can each run with different
seclabels (users, selinux contexts, etc.).  The idea here is to create a
per-domain directory labelled in a way that each domain can access its
own unix sockets.

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

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-08-24 11:53:17 +02:00
Martin Kletzander
cf0404455c qemu: Enable ioeventfd usage for virtio-scsi controllers
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1150484

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-08-10 15:05:34 +02:00
Martin Kletzander
35eecddee3 conf: Add ioeventfd option for controllers
This will be used with a virtio-scsi controller later on.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-08-10 15:05:34 +02:00
Laine Stump
7d69387cd6 qemu: support new pci controller model "pcie-switch-downstream-port"
This is backed by the qemu device xio3130-downstream. It can only be
connected to a pcie-switch-upstream-port (x3130-upstream) on the
upstream side.
2015-08-09 22:32:00 -04:00
Laine Stump
76379a6ec1 conf: new pcie-controller model "pcie-switch-downstream-port"
This controller can be connected only to a port on a
pcie-switch-upstream-port. It provides a single hotpluggable port that
will accept any PCI or PCIe device, as well as any device requiring a
pcie-*-port (the only current example of such a device is the
pcie-switch-upstream-port).
2015-08-09 22:30:47 -04:00
Laine Stump
cb99086d1b qemu: support new pci controller model "pcie-switch-upstream-port"
this is backed by the qemu device x3130-upstream. It can only plug
into a pcie-root-port or pcie-switch-downstream-port.
2015-08-09 22:16:10 -04:00
Laine Stump
38ea9515af conf: new pci controller model "pcie-switch-upstream-port"
This controller can be connected only to a pcie-root-port or a
pcie-switch-downstream-port (which will be added in a later patch),
which is the reason for the new connect type
VIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides
32 ports (slot=0 to slot=31) on the downstream side, which can only
have pci controllers of model "pcie-switch-downstream-port" plugged
into them, which is the reason for the other new connect type
VIR_PCI_CONNECT_TYPE_PCIE_SWITCH.
2015-08-09 22:12:29 -04:00
Laine Stump
16328520f6 qemu: support new pci controller model "pcie-root-port"
This is backed by the qemu device ioh3420.

chassis and port from the <target> subelement are used to store/set the
respective qemu device options for the ioh3420. Currently, chassis is
set to be the index of the controller, and port is set to
"(slot << 3) + function" (per suggestion from Alex Williamson).
2015-08-09 21:58:55 -04:00
Laine Stump
dce3b8beb3 conf: new pci controller model "pcie-root-port"
This controller can be connected (at domain startup time only - not
hotpluggable) only to a port on the pcie root complex ("pcie-root" in
libvirt config), hence the new connect type
VIR_PCI_CONNECT_TYPE_PCIE_ROOT. It provides a hotpluggable port that
will accept any PCI or PCIe device.

New attributes must be added to the controller <target> subelement for
this - chassis and port are guest-visible option values that will be
set by libvirt with values derived from the controller's index and pci
address information.
2015-08-09 21:52:52 -04:00
Laine Stump
18c104516e qemu: implement <target chassisNr='n'/> subelement/attribute of <controller>
This uses the new subelement/attribute in two ways:

1) If a "pci-bridge" pci controller has no chassisNr attribute, it
will automatically be set to the controller's index as soon as the
controller's PCI address is known (during
qemuDomainAssignPCIAddresses()).

2) when creating the commandline for a pci-bridge device, chassisNr
will be used to set qemu's chassis_nr option (rather than the previous
practice of hard-coding it to the controller's index).
2015-08-09 21:40:40 -04:00
Laine Stump
8dc88aeed6 conf: add new <target> subelement with chassisNr attribute to <controller>
There are some configuration options to some types of pci controllers
that are currently automatically derived from other parts of the
controller's configuration. For example, in qemu a pci-bridge
controller has an option that is called "chassis_nr"; up until now
libvirt has always set chassis_nr to the index of the pci-bridge. So
this:

  <controller type='pci' model='pci-bridge' index='2'/>

will always result in:

  -device pci-bridge,chassis_nr=2,...

on the qemu commandline. In the future we may decide there is a better
way to derive that option, but even in that case we will need for
existing domains to retain the same chassis_nr they were using in the
past - that is something that is visible to the guest so it is part of
the guest ABI and changing it would lead to problems for migrating
guests (or just guests with very picky OSes).

The <target> subelement has been added as a place to put the new
"chassisNr" attribute that will be filled in by libvirt when it
auto-generates the chassisNr; it will be saved in the config, then
reused any time the domain is started:

  <controller type='pci' model='pci-bridge' index='2'>
    <model type='pci-bridge'/>
    <target chassisNr='2'/>
  </controller>

The one oddity of all this is that if the controller configuration
is changed (for example to change the index or the pci address
where the controller is plugged in), the items in <target> will
*not* be re-generated, which might lead to conflict. I can't
really see any way around this, but fortunately if there is a
material conflict qemu will let us know and we will pass that on
to the user.
2015-08-09 21:35:00 -04:00
Laine Stump
bf20251048 conf: add new <model> subelement with name attribute to <controller>
This new subelement is used in PCI controllers: the toplevel
*attribute* "model" of a controller denotes what kind of PCI
controller is being described, e.g. a "dmi-to-pci-bridge",
"pci-bridge", or "pci-root". But in the future there will be different
implementations of some of those types of PCI controllers, which
behave similarly from libvirt's point of view (and so should have the
same model), but use a different device in qemu (and present
themselves as a different piece of hardware in the guest). In an ideal
world we (i.e. "I") would have thought of that back when the pci
controllers were added, and used some sort of type/class/model
notation (where class was used in the way we are now using model, and
model was used for the actual manufacturer's model number of a
particular family of PCI controller), but that opportunity is long
past, so as an alternative, this patch allows selecting a particular
implementation of a pci controller with the "name" attribute of the
<model> subelement, e.g.:

  <controller type='pci' model='dmi-to-pci-bridge' index='1'>
    <model name='i82801b11-bridge'/>
  </controller>

In this case, "dmi-to-pci-bridge" is the kind of controller (one that
has a single PCIe port upstream, and 32 standard PCI ports downstream,
which are not hotpluggable), and the qemu device to be used to
implement this kind of controller is named "i82801b11-bridge".

Implementing the above now will allow us in the future to add a new
kind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge
device, but instead uses something else (which doesn't yet exist, but
qemu people have been discussing it), all without breaking existing
configs.

(note that for the existing "pci-bridge" type of PCI controller, both
the model attribute and <model> name are 'pci-bridge'. This is just a
coincidence, since it turns out that in this case the device name in
qemu really is a generic 'pci-bridge' rather than being the name of
some real-world chip)
2015-08-09 21:29:27 -04:00
Laine Stump
f8fe8f0345 conf: more useful error message when pci function is out of range
If a pci address had a function number out of range, the error message
would be:

  Insufficient specification for PCI address

which is logged by virDevicePCIAddressParseXML() after
virDevicePCIAddressIsValid returns a failure.

This patch enhances virDevicePCIAddressIsValid() to optionally report
the error itself (since it is the place that decides which part of the
address is "invalid"), and uses that feature when calling from
virDevicePCIAddressParseXML(), so that the error will be more useful,
e.g.:

  Invalid PCI address function=0x8, must be <= 7

Previously, virDevicePCIAddressIsValid didn't check for the
theoretical limits of domain or bus, only for slot or function. While
adding log messages, we also correct that ommission. (The RNG for PCI
addresses already enforces this limit, which by the way means that we
can't add any negative tests for this - as far as I know our
domainschematest has no provisions for passing XML that is supposed to
fail).

Note that virDevicePCIAddressIsValid() can only check against the
absolute maximum attribute values for *any* possible PCI controller,
not for the actual maximums of the specific controller that this
device is attaching to; fortunately there is later more specific
validation for guest-side PCI addresses when building the set of
assigned PCI addresses. For host-side PCI addresses (e.g. for
<hostdev> and for network device pools), we rely on the error that
will be logged when it is found that the device doesn't actually
exist.

This resolves:

  https://bugzilla.redhat.com/show_bug.cgi?id=1004596
2015-08-08 18:37:35 -04:00
Kothapally Madhu Pavan
d9557572ae Avoid starting a PowerPC VM with floppy disk
PowerPC pseries based VMs do not support a floppy disk controller.
This prohibits libvirt from creating qemu command with floppy device.

Signed-off-by: Kothapally Madhu Pavan <kmp@linux.vnet.ibm.com>

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

Signed-off-by: Ján Tomko <jtomko@redhat.com>
2015-08-04 10:17:07 +02:00
Martin Kletzander
a5bdb8459a Revert "qemu: Use heads parameter for QXL driver"
This reverts commit 7b401c3bda.

Until libvirt is able to differentiate whether heads='1' is just a
leftover from previous libvirt or whether that's added by user on
purpose and also whether the domain was started with the support for
qxl's max_outputs, we cannot incorporate this patch into the tree
due to compatibility reasons.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-07-24 13:06:47 +02:00
Frediano Ziglio
7b401c3bda qemu: Use heads parameter for QXL driver
Allows to specify maximum number of head to QXL driver.

Actually can be a compatiblity problem as heads in the XML configuration
was set by default to '1'.

Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
2015-07-20 10:35:18 +02:00
Boris Fiuczynski
35e3fb50ee qemu: Test for virtio-9p-ccw support
This patch adds a test for the qemu command line generation.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Jason J. Herne <jjherne@us.ibm.com>
Reviewed-by: Stefan Zimmermann <stzi@linux.vnet.ibm.com>
2015-07-15 14:37:30 +02:00
John Ferlan
2e09729b1c conf: Don't allow duplicated target names regardless of bus
https://bugzilla.redhat.com/show_bug.cgi?id=1142631

Commit id 'e0e290552' added a check to determine if the same bus
had the same target value.  It seems that's not quite good enough
as the check should check the target name value regardless of bus type.

Also added a DO_TEST_DIFFERENT to exhibit the issue
2015-07-09 08:30:02 -04:00
Luyao Huang
955d9bb8d0 qemu: report error when shmem has an invalid address
If user passes an invalid address for shared memory device to qemu,
neither libvirt nor qemu will report an error, but qemu will auto assign
a pci address to the shared memory device.

Signed-off-by: Luyao Huang <lhuang@redhat.com>
2015-07-08 16:30:42 +02:00
Luyao Huang
e9401342e1 qemu: Assign IDs for shared memory devices
Signed-off-by: Luyao Huang <lhuang@redhat.com>
2015-07-08 16:30:42 +02:00
Luyao Huang
e309ea6658 qemu: Auto assign pci addresses for shared memory devices
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1165029

Signed-off-by: Luyao Huang <lhuang@redhat.com>
2015-07-08 16:30:42 +02:00
Ján Tomko
4edf01c92c Explicitly format the isa-fdc controller for newer q35 machines
Since QEMU commit ea96bc6 [1]:
i386: drop FDC in pc-q35-2.4+ if neither it nor floppy drives are wanted
the floppy controller is no longer implicit.

Specify it explicitly on the command line if the machine type version
is 2.4 or later.

Note that libvirt's floppy drives do not result in QEMU implying the
controller, because libvirt uses if=none instead of if=floppy.

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

[1] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ea96bc6
2015-07-08 15:35:35 +02:00
Jiri Denemark
ffbafd4e88 qemu: Avoid using ".(null)" in UNIX socket path
The code which generates paths for UNIX socket blindly used target name
without checking if it was set. Thus for the following device XML

    <channel type='unix'>
      <source mode='bind'/>
      <target type='virtio'/>
    </channel>

we would generate "/var/lib/libvirt/qemu/channel/target/NAME.(null)"
path which works but is not really correct. Let's not use the
".target_name" suffix at all if target name is not set.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-01 09:47:32 +02:00
Jiri Denemark
365b454ed9 qemu: Fix assignment of the default spicevmc channel name
Make sure we only assign the default spicevmc channel name to spicevmc
virtio channels. Caused by commits 3269ee65 and 1133ee2b, which moved
the assignment from XML parsing code to QEMU but failed to keep the
logic.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-06-30 10:31:29 +02:00
Jiri Denemark
528e70a29a qemuxml2argv: Remove Haswell CPU from unrelated tests
Proper Haswell CPU model handling is tested in several
qemuxml2argv-cpu-* which are run in a special environment. Let's remove
the CPU model from other tests to make them less fragile.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-06-29 13:28:20 +02:00