Commit Graph

690 Commits

Author SHA1 Message Date
Ján Tomko
971f5f229d qemu: build command line for virtio-input-host device
<input type='passthrough' bus='virtio'>
  <source evdev='/dev/input/event1234'/>
</input>

results in:

-device virtio-input-host-pci,id=input0,evdev=/dev/input/event1234

https://bugzilla.redhat.com/show_bug.cgi?id=1231114
2015-11-30 13:00:04 +01:00
Ján Tomko
1a538a07c7 conf: add XML for input device passthrough
Add xml for the new virtio-input-host-pci device:
<input type='passthrough' bus='virtio'>
  <source evdev='/dev/input/event1234'/>
</input>

https://bugzilla.redhat.com/show_bug.cgi?id=1231114
2015-11-30 12:29:03 +01:00
Ján Tomko
7210cef452 qemu: build command line for virtio input devices
Add support for these qemu devices:
virtio-mouse-{pci,device}
virtio-keyboard-{pci,device}
virtio-tablet-{pci,device}

https://bugzilla.redhat.com/show_bug.cgi?id=1231114
2015-11-30 12:25:36 +01:00
Ján Tomko
bebdfafb2b conf: parse and format virtio input bus in domain XML
To be used by the family of virtio input devices:

<input type='mouse' bus='virtio'/>
<input type='tablet' bus='virtio'/>
<input type='keyboard' bus='virtio'/>

https://bugzilla.redhat.com/show_bug.cgi?id=1231114
2015-11-30 12:22:06 +01:00
Marc-André Lureau
06198b9c73 qemu: add virtio-gpu virgl support
Check if virtio-gpu provides virgl option, and add qemu command line
formatter.

It is enabled with the existing accel3d attribute:
<model type='virtio' heads='1'>
 <acceleration accel3d='yes'/>
</model>

Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-11-27 16:48:53 +01:00
Marc-André Lureau
21373feb4e qemu: add virtio video device
qemu 2.5 provides virtio video device.  It can be used with -device
virtio-vga for primary devices, or -device virtio-gpu for non-vga
devices. However, only the primary device (VGA) is supported with this
patch.

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

Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-11-27 16:48:53 +01:00
Ján Tomko
7ec235ed09 schema: use a better regex for listen addresses
A domain with '::' as the listen address fails to validate.

Reuse the 'ipAddr' and 'dnsName' regexes from basictypes instead
of reinventing them.

https://bugzilla.redhat.com/show_bug.cgi?id=1285665
2015-11-26 11:05:18 +01:00
Dmitry Andreev
59fc0d0609 Allow multiple panic devices
'model' attribute was added to a panic device but only one panic
device is allowed. This patch changes panic device presence
from 'optional' to 'zeroOrMore'.
2015-11-25 14:46:21 +01:00
Dmitry Andreev
ca6ddffe2c qemu: add support for hv_crash feature as a panic device
Panic device type used depends on 'model' attribute.

If no model is specified then device type depends on hypervisor
and guest arch. 'pseries' model is used for pSeries guest and
'isa' model is used in other cases.

XML:
<devices>
  <panic model='hyperv'/>
</devices>

QEMU command line:
qemu -cpu <cpu_model>,hv_crash
2015-11-25 14:46:20 +01:00
Dmitry Andreev
5e8d2ebd7a tests: add tests for the new panic device attribute - 'model' 2015-11-25 12:30:05 +01:00
Peter Krempa
4ad31f8f65 qemu: ppc64: Support memory hotplug without NUMA enabled
ppc64 guests don't require adding a NUMA node for hotplug memory to
work. Lift the requirement and add test cases.
2015-11-18 10:32:18 +01:00
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
Michal Privoznik
70d75ffc79 qemuBuildMemoryBackendStr: Honour passed @pagesize
So far the argument has not much meaning and was practically ignored.
This is not good since when doing memory hotplug, the size of desired
hugepage backing is passed in that argument. Taking closer look at the
tests I'm fixing reveals the bug. For instance, while the following is
in the test:

    <memory model='dimm'>
      <source>
        <nodemask>1-3</nodemask>
        <pagesize unit='KiB'>4096</pagesize>
      </source>
      <target>
        <size unit='KiB'>524287</size>
        <node>0</node>
      </target>
      <address type='dimm' slot='0' base='0x100000000'/>
    </memory>

the generated commandline corresponding to this XML was:

    -object memory-backend-ram,id=memdimm0,size=536870912,\
    host-nodes=1-3,policy=bind

Have you noticed? Yes, memory-backend-ram! Nothing can be further away
from the right answer. The hugepage backing is requested in the XML
and we happily ignore it. This is just not right. It's
memory-backend-file which should have been used:

    -object memory-backend-file,id=memdimm0,prealloc=yes,\
    mem-path=/dev/hugepages4M/libvirt/qemu,size=536870912,\
    host-nodes=1-3,policy=bind

The problem is, that @pagesize passed to qemuBuildMemoryBackendStr
(where this part of commandline is built) was ignored. The hugepage to
back memory was searched only and only by NUMA nodes pinning. This
works only for regular guest NUMA nodes.

Then, I'm changing the hugepages size in the test XMLs too. This is
simply because in the test suite we create dummy mount points just for
2M and 1G hugepages. And in the test 4M was requested. I'm sticking to
2M, but 1G should just work too.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-06-26 09:23:06 +02:00
Michal Privoznik
f8e9deb1d4 qemuBuildMemoryBackendStr: Fix hugepages lookup process
https://bugzilla.redhat.com/show_bug.cgi?id=1196644

This function constructs the backend (host facing) part of the
memory device.  At the beginning, the configured hugepages are
searched to find the best match for given guest NUMA node.
Configured hugepages can have a @nodeset attribute to specify on
which guest NUMA nodes should be the hugepages backing used.
There is, however, one 'corner case'. Users may just tell 'use
hugepages to back all the nodes'. In other words:

  <memoryBacking>
    <hugepages/>
  </memoryBacking>

  <cpu>
    <numa>
      <cell id='0' cpus='0-1' memory='1024000' unit='KiB'/>
    </numa>
  </cpu>

Our code fails in this case. Well, since there's no @nodeset (nor
any <page/> child element to <hugepages/>) we fail to lookup the
default hugepage size to use.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-06-26 09:15:26 +02:00
Luyao Huang
786539d6bf conf: Format scheduler priority when it is zero
https://bugzilla.redhat.com/show_bug.cgi?id=1235116

According to our XML definition, zero is as valid as any other value.
Mainly because it should be kernel-agnostic.

Signed-off-by: Luyao Huang <lhuang@redhat.com>
2015-06-25 23:25:30 +02:00
Boris Fiuczynski
366e31a6ef Test for the new watchdog model diag288
Adding a test for the new watchdog model diag288.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2015-06-24 15:26:32 +02:00
Boris Fiuczynski
4fda44940b Test for the new watchdog action inject-nmi
Adding a test for the new watchdog action "inject-nmi".

Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2015-06-24 15:26:31 +02:00
Eric Farman
c733e97323 docs: Fix XML schema handling of LUN address in hostdev tag
Defining a domain with a SCSI disk attached via a hostdev
tag and a source address unit value longer than two digits
causes an error when editing the domain with virsh edit,
even if no changes are made to the domain definition.
The error suggests invalid XML, somewhere:

  # virsh edit lmb_guest
  error: XML document failed to validate against schema:
  Unable to validate doc against /usr/local/share/libvirt/schemas/domain.rng
  Extra element devices in interleave
  Element domain failed to validate content

The virt-xml-validate tool fails with a similar error:

  # virt-xml-validate lmb_guest.xml
  Relax-NG validity error : Extra element devices in interleave
  lmb_guest.xml:17: element devices: Relax-NG validity error :
  Element domain failed to validate content
  lmb_guest.xml fails to validate

The hostdev tag requires a source address to be specified,
which includes bus, target, and unit address attributes.
According to the SCSI Architecture Model spec (section
4.9 of SAM-2), a LUN address is 64 bits and thus could be
up to 20 decimal digits long.  Unfortunately, the XML
schema limits this string to just two digits.  Similarly,
the target field can be up to 32 bits in length, which
would be 10 decimal digits.

  # lsscsi -xx
  [0:0:19:0x4022401100000000]  disk    IBM      2107900          3.44 /dev/sda
  # lsscsi
  [0:0:19:1074872354]disk    IBM      2107900          3.44  /dev/sda
  # cat lmb_guest.xml
  <domain type='kvm'>
    <name>lmb_guest</name>
    <memory unit='MiB'>1024</memory>
  ...trimmed...
    <devices>
      <controller type='scsi' model='virtio-scsi' index='0'/>
      <hostdev mode='subsystem' type='scsi'>
        <source>
          <adapter name='scsi_host0'/>
          <address bus='0' target='19' unit='1074872354'/>
        </source>
      </hostdev>
  ...trimmed...

Since the reference unit and target fields are used in
several places in the XML schema, create a separate one
specific for SCSI Logical Units that will permit the
greater length.  This permits both the validation utility
and the virsh edit command to succeed when a hostdev
tag is included.

Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Reviewed-by: Stefan Zimmermann <stzi@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2015-06-22 16:15:49 -04:00
James Cowgill
f486bb0494 qemu: implement address for isa-serial
I needed to specify the iobase address for certain exotic mips configurations.

Signed-off-by: James Cowgill <james410@cowgill.org.uk>
2015-06-18 08:17:20 -04:00
Michal Privoznik
a9a27e602c virSysinfo: Introduce SMBIOS type 2 support
https://bugzilla.redhat.com/show_bug.cgi?id=1220527

This type of information defines attributes of a system
baseboard. With one exception: board type is yet not implemented
in qemu so it's not introduced here either.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-06-18 10:10:26 +02:00
Maxime Leroy
366c22f2bc qemu: add multiqueue vhost-user support
This patch adds the support of queues attribute of the driver element
for vhost-user interface type. Example:

<interface type='vhostuser'>
      <mac address='52:54:00:ee:96:6d'/>
      <source type='unix' path='/tmp/vhost2.sock' mode='client'/>
      <model type='virtio'/>
      <driver queues='4'/>
</interface>

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

Signed-off-by: Maxime Leroy <maxime.leroy@6wind.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-06-11 14:28:29 +02:00
Martin Kletzander
181e02dfda conf: Ignore multiqueue with one queue.
Multi != One.  And indeed, libvirt behaves the same way for queues='1'
as without such setting.  Let's make it clear in the XML.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-06-11 14:17:46 +02:00
Cole Robinson
29ce1693fa qemu: command: Support arm 32-on-64 KVM with -cpu aarch64=off
qemu 2.3.0 added the -cpu host,aarch64=off option, which allows using
qemu-system-aarch64 KVM to run armv7l VMs.

Add a capabilities check for it, wire it up in qemu_command, and test
the command line generation.
2015-06-08 17:51:06 -04:00
Ján Tomko
8728a78e90 Always add 'console' matching the 'serial' device
We have been formatting the first serial device also
as a console device, but only if there were no other consoles.

If there is a <serial> device present in the XML, but no serial
<console>, or if there isn't any <console> at all but the domain
definition hasn't gone through a parse->format->parse round-trip,
the <console> device would not be formatted.

Change the code to always add the stub device for the first
serial device.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1089914
2015-06-04 10:04:44 +02:00
Andrea Bolognani
778c56f000 qemu: Automatically add <panic> element for pSeries guests.
The guest firmware provides the same functionality as the pvpanic
device, and the relevant element should always be present in the
domain XML to reflect this fact, so add it after parsing the
definition if it wasn't there already.
2015-06-01 06:44:37 -04:00
Andrea Bolognani
7bd769e0ab qemu: Allow panic device for pSeries guests
The guest firmware provides the same functionality as the pvpanic
device, which is not available in QEMU on pSeries, so the domain
XML should be allowed to contain the <panic> element.

On the other hand, unlike the pvpanic device, the guest firmware
can't be configured, so report an error if an address has been
provided in the XML.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1182388
2015-06-01 06:16:29 -04:00
Michal Privoznik
8e33cb41f3 qemu: Implement pci-serial
https://bugzilla.redhat.com/show_bug.cgi?id=998813

Implementation is pretty straight-forward. Of course, not all qemus
out there supports the device, so new capability is introduced and
checked prior each use of the device.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-05-21 17:49:02 +02:00
Michal Privoznik
335b834d95 Introduce pci-serial
https://bugzilla.redhat.com/show_bug.cgi?id=998813

Like usb-serial, the pci-serial device allows a serial device to be
attached to PCI bus. An example XML looks like this:

  <serial type='dev'>
    <source path='/dev/ttyS2'/>
    <target type='pci-serial' port='0'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
  </serial>

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-05-21 17:49:02 +02:00
Luyao Huang
aef2a0a26c conf: Restore the XML parser context in virDomainMemoryDefParseXML
After parsing the memory device XML the function would not restore the
XML parser context causing invalid XPath starting point for the rest of
the elements. This is a regression since 3e4230d2.

The test case addition uses the <idmap> element that is currently unused
by qemu, but parsed after the memory device definition and formatted
always.

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

Signed-off-by: Luyao Huang <lhuang@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2015-05-21 11:06:18 +02:00
Tony Krowiak
8ed0bcfd81 libvirt: tests: test protected key mgmt ops support
Test the support for enabling/disabling CPACF protected key management
operations for a guest.

Signed-off-by: Tony Krowiak <akrowiak@linux.vnet.ibm.com>
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-05-18 09:54:16 +02:00
Laine Stump
eadd757cce qemu: log error when domain has an unsupported IDE controller
We have previously effectively ignored all <controller type='ide'>
elements in a domain definition.

On the i440fx-based machinetypes there is an IDE controller that is
included in the chipset and can't be removed (which is the ide
controller with index='0'>), so it makes sense to ignore that one
controller. However, if an i440fx domain definition has a 2nd
controller, nothing catches this error (unless you also have a disk
attached to it, in which case qemu will complain that you're trying to
use the ide controller named "ide1", which doesn't exist), and if any
other type of domain has even a single controller defined, it will be
incorrectly ignored.

Ignoring a bogus controller definition isn't such a big problem, as
long as an error is logged when any disk is attached to that
non-existent controller. But in the case of q35-based machinetypes,
the hardcoded id ("alias" in libvirt terms) of its builtin SATA
controller is "ide", which happens to be the same id as the builtin
IDE controller on i440fx machinetypes. So libvirt creates a
commandline believing that it is connecting the disk to the builtin
(but actually nonexistent) IDE controller, qemu thinks that libvirt
wanted that disk connected to the builtin SATA controller, and
everybody is happy.

Until you try to connect a 2nd disk to the IDE controller. Then qemu
will complain that you're trying to set unit=1 on a controller that
requires unit=0 (SATA controllers are organized differently than IDE
controllers).

After this patch, if a domain has an IDE controller defined for a
machinetype that has no IDE controllers, libvirt will log an error
about the controller itself as it is building the qemu commandline
(rather than a (possible) error from qemu about disks attached to that
controller). This is done by adding IDE to the list of controller
types that are handled in the loop that creates controller command
strings in qemuBuildCommandline() (previously it would *always* skip
IDE controllers). Then qemuBuildControllerDevStr() is modified to log
an appropriate error in the case of IDE controllers.

In the future, if we add support for extra IDE controllers (piix3-ide
and/or piix4-ide) we can just add it into the IDE case in
qemuBuildControllerDevStr(). For now, nobody seems anxious to add
extra support for an aging and very slow controller, when there are so
many better options available.

Resolves:

https://bugzilla.redhat.com/show_bug.cgi?id=1176071 (Fedora)
2015-05-15 15:40:43 -04:00
Laine Stump
548ba43028 qemu: remove test for allowing ide controller in s390, rename usb tests
Back in 2013, commit 877bc089 added in some tests that made sure no
error was generated on a domain definition that had an automatically
added usb controller if that domain didn't have a PCI bus to attach
the usb controller to. This was done because, at that time, libvirt
was automatically adding a usb controller to *any* domain definition
that didn't have one.  Along with permitting the controller, two
s390-specific tests were added to ensure this behavior was maintained
- one with <controller type='usb' model='none'/> and another (called
"s390-piix-controllers") that had both usb and ide controllers, but
nothing attached to them.

Then in February of this year, commit 09ab9dcc eliminated the annoying
auto-adding of a usb device for s390 and s390x machines, stating:

 "Since s390 does not support usb the default creation of a usb
  controller for a domain should not occur."

Although, as verified here, the s390 doesn't support usb, and usb
controllers aren't currently added to s390 domain definitions
automatically, there are likely still some domain definitions in the
wild that have a usb controller (which was added *by libvirt*, not by
the user), so we will keep the tests verifying that behavior for
now. But this patch changes the names of the tests to reflect that
they don't actually contain a valid s390 config; this way future
developers won't propagate the incorrect idea that an s390 virtual
machine can have a USB (or IDE) bus.

In the case of the IDE controller, though, libvirt has never
automatically added an IDE controller unless a user added an IDE disk
(which itself would have caused an error), and we specifically *do*
want to begin generating an error when someone tries to add an IDE
controller to a domain that can't support one. For that reason, while
renaming the sz390-piix-controllers patch, this patch removes the
<controller type='ide'...> from it (otherwise the upcoming patch would
break make check)
2015-05-15 15:37:51 -04:00
Laine Stump
0260506c65 qemu: use controller alias when constructing device/controller args
This makes sure that that the commandlines generated for devices and
controller devices are all using the alias that has been set in the
controller's object as the id of the controller, rather than
hardcoding a printf (or worse, encoding exceptions to the standard
${controller}${index} into the logic)

Since this "fixes" the controller name used for the sata controller,
the commandline arg for the sata controller in the sata test case had
to be adjusted to be "sata0" instead of "ahci0". All other tests
remain unchanged, verifying that the patch causes no other functional
change.

Because the function that finds a controller alias based on a device
def requires a pointer to the full domainDef in order to get the list
of controllers, the arglist of a few functions had to have this added.
2015-05-15 15:36:28 -04:00
Cole Robinson
8910e063db caps: Fix regression defaulting to host arch
My commit 747761a79 (v1.2.15 only) dropped this bit of logic when filling
in a default arch in the XML:

-    /* First try to find one matching host arch */
-    for (i = 0; i < caps->nguests; i++) {
-        if (caps->guests[i]->ostype == ostype) {
-            for (j = 0; j < caps->guests[i]->arch.ndomains; j++) {
-                if (caps->guests[i]->arch.domains[j]->type == domain &&
-                    caps->guests[i]->arch.id == caps->host.arch)
-                    return caps->guests[i]->arch.id;
-            }
-        }
-    }

That attempt to match host.arch is important, otherwise we end up
defaulting to i686 on x86_64 host for KVM, which is not intended.
Duplicate it in the centralized CapsLookup function.

Additionally add some testcases that would have caught this.

https://bugzilla.redhat.com/show_bug.cgi?id=1219191
2015-05-08 11:11:32 -04:00
Cole Robinson
fd74e23175 tests: Remove redundant aarch64 tests
My commit 7b9de914 added some aarch64 CPU test cases. I wanted to test
two different code paths but inadvertently added two of the same test
cases.

The second code path (using <cpu><model>host</model</cpu>) isn't easily
exercised via the qemu tests anyways, I'll need to look elsewhere.

Regardless, remove the redundant tests for now
2015-05-07 11:54:46 -04:00
Michal Privoznik
608c95c76c qemu: Implement GIC
The only version that's supported in QEMU is version 2, currently.
Fortunately, it is enabled by aarch64 automatically, so there's
nothing for us that needs to be put onto command line.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-05-05 09:45:52 +02:00
Marc-André Lureau
620655f353 tests: add machine vmport qemu test
Check that the vmport feature is correctly used in qemu commande line.
2015-05-04 13:19:38 +02:00
Jiri Denemark
6280294574 qemu: Check address type for USB disks
Only USB addresses are allowed for USB disks. Report an error if another
address is configured.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-04-30 15:34:57 +02:00
Jiri Denemark
01ecee247a cpu: Honor vendor_id override in host-model
https://bugzilla.redhat.com/show_bug.cgi?id=858147

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-04-30 15:34:57 +02:00
John Ferlan
4dec8a0160 conf: Adjust the iothreadsched expectations
With iothreadid's allowing any 'id' value for an iothread_id, the
iothreadsched code needs a slight adjustment to allow for "any"
unsigned int value in order to create the bitmap of ids that will
have scheduler adjustments. Adjusted the doc description as well.
2015-04-27 12:36:35 -04:00
John Ferlan
8d4614a512 qemu: Use domain iothreadids to IOThread's 'thread_id'
Add 'thread_id' to the virDomainIOThreadIDDef as a means to store the
'thread_id' as returned from the live qemu monitor data.

Remove the iothreadpids list from _qemuDomainObjPrivate and replace with
the new iothreadids 'thread_id' element.

Rather than use the default numbering scheme of 1..number of iothreads
defined for the domain, use the iothreadid's list for the iothread_id

Since iothreadids list keeps track of the iothread_id's, these are
now used in place of the many places where a for loop would "know"
that the ID was "+ 1" from the array element.

The new tests ensure usage of the <iothreadid> values for an exact number
of iothreads and the usage of a smaller number of <iothreadid> values than
iothreads that exist (and usage of the default numbering scheme).
2015-04-27 12:36:35 -04:00
Cole Robinson
7b9de91404 tests: qemu: Couple aarch64 CPU tests
- Make sure aarch64 host-passthrough works correctly
- Make sure libvirt doesn't choke on cpu model=host, which is what
  virt-install/virt-manager were incorrectly specifying up until recently.
2015-04-24 10:27:01 -04:00
Daniel P. Berrange
615bdfda07 rng: fix port number range validation
The PortNumber data type is declared to derive from 'short'.
Unfortunately this is an signed type, so validates the range
[-32,768, 32,767] which excludes valid port numbers between
32767 and 65535.

We can't use 'unsignedShort', since we need -1 to be a valid
port number too.

This change is to use 'int' and set an explicit max boundary
instead of relying on the data types' built-in max.

One of the existing tests is changed to use a high port number
to validate the schema.

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

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-04-23 12:59:52 +01:00
Erik Skultety
cea1b86fa7 rng: Forbid to validate mismatched <disk> 'device' and 'type' attributes
According to docs, using 'lun' as a value for device attribute is only valid
with disk types 'block' and 'network'. However current RNG schema also allows
a combination type='file' device='lun' which results in a successfull
xml validation, but fails at qemuBuildCommandLine.
Besides fixing the RNG schema, this patch also adds a qemuxml2argvtest
for this case.

https://bugzilla.redhat.com/show_bug.cgi?id=1210669
2015-04-20 10:04:06 +02:00
Michal Privoznik
7cf87f750b RNG schema: allow plain @floor to <bandwidth/>
The <inbound/> element to <bandwidth/> has several attributes from
which two are mandatory. Well, from two at least one has to be
present: @average or @floor or both. Instead of inventing crazy RNG
schema, let's make all the attributes optional there and rely on our
parsing code to correctly handle the situation.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-04-16 09:07:43 +02:00
Ján Tomko
a75069be35 Fix usb device version parsing issues
Request that the number be parsed as decimal, to allow 08
and 09.

Format it with the leading zero, 1.01 and 1.10 are two
different versions.

https://bugzilla.redhat.com/show_bug.cgi?id=1210650
2015-04-13 12:33:41 +02:00
Andrea Bolognani
e4d7ddfdd2 conf: Don't output <cpu> tag if it contains no information.
The tag is already marked as optional in the schema, so no changes
are needed there.

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1202606
2015-04-13 09:27:26 +02:00
Ján Tomko
1371ea92f0 Auto add virtio-serial controllers
In virDomainVirtioSerialAddrNext, add another controller
if we've exhausted all ports of the existing controllers.

https://bugzilla.redhat.com/show_bug.cgi?id=1076708
2015-04-02 15:00:13 +02:00
Ján Tomko
5903378834 Allocate virtio-serial addresses when starting a domain
Instead of always using controller 0 and incrementing port number,
respect the maximum port numbers of controllers and use all of them.

Ports for virtio consoles are quietly reserved, but not formatted
(neither in XML nor on QEMU command line).

Also rejects duplicate virtio-serial addresses.
https://bugzilla.redhat.com/show_bug.cgi?id=890606
https://bugzilla.redhat.com/show_bug.cgi?id=1076708

Test changes:
* virtio-auto.args
  Filling out the port when just the controller is specified.
  switched from using
    maxport + 1
  to:
    first free port on the controller
* virtio-autoassign.args
  Filling out the address when no <address> is specified.
  Started using all the controllers instead of 0, also discards
  the bus value.
* xml -> xml output of virtio-auto
  The port assignment is no longer done as a part of XML parsing,
  so the unspecified values stay 0.
2015-04-02 15:00:13 +02:00
Ján Tomko
8945d6a805 Add test for virtio serial port assignment
Add a test to demonstrate the effect of automatic virtio-serial
address assignment.
2015-04-02 15:00:13 +02:00
Eric Blake
dfc708750b relaxng: allow : in /dev/disk/by-path names
On IRC, Hydrar pointed a problem where 'virsh edit' failed on
his domain created through an ISCSI pool managed by virt-manager,
all because the XML included a block device with colons in the
name.

* docs/schemas/basictypes.rng (absFilePath): Add colon as safe.
* tests/qemuxml2argvdata/qemuxml2argv-disk-iscsi.xml: New file.
* tests/qemuxml2argvdata/qemuxml2argv-disk-iscsi.args: Likewise.
* tests/qemuxml2argvtest.c (mymain): Test it.

Signed-off-by: Eric Blake <eblake@redhat.com>
2015-03-26 16:57:26 -06:00