1
0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-25 01:34:11 +03:00
Commit Graph

20125 Commits

Author SHA1 Message Date
Pavel Hrdina
d28fefc66a qemu_driver: live/config checks cleanup
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2015-07-03 15:30:33 +02:00
Daniel Veillard
cf739b3568 better patch for the XSS search issue
Since the query string could be output when displaying the results too
2015-07-03 21:04:24 +08:00
Daniel Veillard
d51876bc8e Avoid XSS vulnerability on the search engine
Raised by https://www.xssposed.org/incidents/69566/
Need to escape the user provided query before displaying it back
2015-07-03 20:47:08 +08:00
Nikolay Shirokovskiy
2854079496 vz: fix SDK event dispatching
Current version of SDK event dispatcing is incorrect. For most VM events (add,
delete etc) issuer type is PIE_DISPATCHER. Actually analyzing issuer type
doesn't have any benifints so this patch get rid of it. All dispatching is done
only on event type.

Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
2015-07-02 18:57:45 +03:00
John Ferlan
2c05841246 util: Avoid Coverity FORWARD_NULL
Avoid a false positive since Coverity find a path in virResizeN which
could return 0 prior to the allocation of memory and thus flags a
possible NULL dereference. Instead allocate the output buffer based
on 'nparams' and only fill it partially if need be - shouldn't be too
much a waste of space. Quicker than multiple VIR_RESIZE_N calls or
two loops of STREQ's sandwiched around a single VIR_ALLOC_N using
'n' matches from a first loop to generate the 'n' addresses to return

Signed-off-by: John Ferlan <jferlan@redhat.com>
2015-07-02 06:30:27 -04:00
Luyao Huang
848ab685f7 virsh: report error if vcpu number exceed the guest maxvcpu number
Commit id '81dd81e' caused a regression when attempting to print a
specific vcpuid that is out of the range of the maximum vcpus for
the guest, such as:

 $ virsh vcpupin $dom 1000
 VCPU: CPU Affinity
 ----------------------------------

 $

Rather than just recover the old message, let's adjust the message based
on what would be displayed for a similar failure in the set path, such as:

 $ virsh vcpupin $dom 1000
 error: vcpu 1000 is out of range of persistent cpu count 2

 $ virsh vcpupin $dom 1000 --live
 error: vcpu 1000 is out of range of live cpu count 2

 $

Signed-off-by: Luyao Huang <lhuang@redhat.com>
2015-07-02 06:26:37 -04:00
Michal Dubiel
a188c57d54 virt-aa-helper: Fix permissions for vhost-user socket files
QEMU working in vhost-user mode communicates with the other end (i.e.
some virtual router application) via unix domain sockets. This requires
that permissions for the socket files are correctly written into
/etc/apparmor.d/libvirt/libvirt-UUID.files.

Signed-off-by: Michal Dubiel <md@semihalf.com>
2015-07-02 11:17:03 +02:00
Michal Privoznik
20078964d9 Post-release version bump to 1.2.18
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-07-02 11:17:03 +02:00
Jiri Denemark
0cad264832 cpu_map.xml: Expand Opteron_G4 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:18:29 +02:00
Jiri Denemark
45145693d3 cpu_map.xml: Expand Opteron_G2 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:18:29 +02:00
Jiri Denemark
dcc6d4f495 cpu_map.xml: Expand Opteron_G1 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:18:29 +02:00
Jiri Denemark
71dd1dab91 cpu_map.xml: Expand Broadwell-noTSX CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:18:04 +02:00
Jiri Denemark
ec479971e2 cpu_map.xml: Expand Haswell-noTSX CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:16:05 +02:00
Jiri Denemark
732d3d147a cpu_map.xml: Expand SandyBridge CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:41 +02:00
Jiri Denemark
9e2829ca1a cpu_map.xml: Expand Westmere CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:41 +02:00
Jiri Denemark
add70a456a cpu_map.xml: Expand Nehalem CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:41 +02:00
Jiri Denemark
81b8d42891 cpu_map.xml: Expand Penryn CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:41 +02:00
Jiri Denemark
25a831ae80 cpu_map.xml: Expand Conroe CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:41 +02:00
Jiri Denemark
765f49cea4 cpu_map.xml: Expand kvm64 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:40 +02:00
Jiri Denemark
adcb209b26 cpu_map.xml: Expand cpu64-rhel5 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:40 +02:00
Jiri Denemark
f7e1677cf8 cpu_map.xml: Expand kvm32 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:40 +02:00
Jiri Denemark
5dda684bfa cpu_map.xml: Expand qemu32 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:40 +02:00
Jiri Denemark
1122296737 cpu_map.xml: Expand n270 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:40 +02:00
Jiri Denemark
427e17589e cpu_map.xml: Expand coreduo CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:39 +02:00
Jiri Denemark
272ef5be93 cpu_map.xml: Expand pentiumpro CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:39 +02:00
Jiri Denemark
0556d32cff cpu_map.xml: Expand pentium2 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:39 +02:00
Jiri Denemark
ac7d160724 cpu_map.xml: Expand pentium CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:39 +02:00
Jiri Denemark
7298abcfd2 cpu_map.xml: Expand 486 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:39 +02:00
Jiri Denemark
eb9274b345 cpu_map.xml: Sort features in x86 CPU models
Sorted feature list is easier to review or compare.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-07-02 10:09:39 +02:00
Daniel Veillard
845184b2fd Release of libvirt-1.2.17
* docs/news.html.in libvirt.spec.in: updated for the release
* po/*po*: regenerated
2015-07-02 13:22:30 +08:00
John Ferlan
78f1aca076 phyp: Resolve Coverity FORWARD_NULL
Commit id 'cd490086' added a VIR_FORCE_CLOSE of the 'sock', but it
was after the VIR_FREE() of phyp_driver, resulting in a possible/likely
NULL dereference.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2015-07-01 12:15:20 -04:00
John Ferlan
c50c664de5 util: Resolve Coverity FORWARD_NULL
Convert virPCIDriverDir to return the buffer allocated (or not) and make the
appropriate check in the caller.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2015-07-01 12:15:16 -04:00
John Ferlan
e3939e86ba util: Resolve Coverity FORWARD_NULL
Convert virPCIDriverFile to return the buffer allocated (or not) and make the
appropriate check in the caller.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2015-07-01 12:15:12 -04:00
John Ferlan
d7ddb4c2f0 util: Resolve Coverity FORWARD_NULL
Convert virPCIFile to return the buffer allocated (or not) and make the
appropriate check in the caller.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2015-07-01 12:15:08 -04:00
Michal Privoznik
302146b16d lxc: Don't pass a local variable address randomly
So, recently I was testing the LXC driver. You know, startup some
domains. But to my surprise, I was not able to start a single one:

  virsh # start --console test
  error: Reconnected to the hypervisor
  error: Failed to start domain test
  error: internal error: guest failed to start: unexpected exit status 125

So I've start digging. It turns out, that in virExec(), when I printed
out the @cmd, I got strange values: *(cmd->outfdptr) was certainly not
valid FD number: it has random value of several millions. This
obviously made prepareStdFd(childout, STDOUT_FILENO) fail (line 611).
But outfdptr is set in virCommandSetOutputFD(). The only place within
LXC driver where the function is called is in
virLXCProcessBuildControllerCmd(). If you take a closer look at the
function it looks like this:

static virCommandPtr
virLXCProcessBuildControllerCmd(virLXCDriverPtr driver,
                                ..
                                int logfd,
                                const char *pidfile)
{
    ...
    virCommandSetOutputFD(cmd, &logfd);
    virCommandSetErrorFD(cmd, &logfd);
    ...
}

Yes, you guessed it. @logfd is passed into the function by value.
However, in the function we try to get its address (an address of a
local variable) which is no longer valid once function is finished and
stack is cleaned. Therefore when cmd->outfdptr is evaluated at any
point after this function, we may get a random number, depending on
what's currently on the stack. Of course, this may work sometimes too
- it depends on the compiler how it arranges the code, when the stack
is wiped out.

In order to fix this, lets pass a pointer to @logfd instead of
figuring out (wrong) its value in a function.

The bug was introduced in e1de5521.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-07-01 17:49:35 +02:00
John Ferlan
ebd62ebaaa qemu: Resolve Coverity DEADCODE
Commit id 'f967e7a6' didn't place the closing parentheses quite right
causing DEADCODE errors since the rc setting/comparison was wrong.
2015-07-01 06:28:12 -04:00
Peter Krempa
4b48ba4af5 conf: qemu: Taint VMs using custom device tree blob
Using a custom device tree image may cause unexpected behavior in
architectures that use this approach to detect platform devices. Since
usually the device tree is generated by qemu and thus it's not normally
used let's taint VMs using it to make it obvious as a possible source of
problems.
2015-07-01 10:34:25 +02:00
Peter Krempa
91081979dd qemu: Audit memory size with memory hotplug operations
The memory device hot(un)plug was missing calls to the auditing code.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1226234
2015-07-01 10:19:54 +02:00
Peter Krempa
1a13677460 conf: audit: Audit physical memory size rather than balloon request
Since the balloon driver does not guarantee that it returns memory to
the host, using the value in the audit message is not a good idea.

This patch removes auditing from updating the balloon size and reports
the total physical size at startup.
2015-07-01 10:18:10 +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
Peter Krempa
18c9d1578b qemu: agent: Don't automatically disable CPU0 via guest agent
While CPU0 was made unpluggable in Linux a while ago it's not desirable
to unplug it since some parts of the kernel (suspend-to-ram) still
depend on it.

This patch fixes the vCPU selection code in libvirt so that it will not
be disabled.
2015-07-01 09:38:02 +02:00
Luyao Huang
91c9e4d920 qemu: End job even if exiting monitor after OpenGraphics(FD) fails
Signed-off-by: Luyao Huang <lhuang@redhat.com>
2015-07-01 08:36:48 +02:00
Ján Tomko
224456fc4a qemu: properly free addresses on non-serial chardev unplug
The target type comparison in qemuDomainDetachChrDevice
used the VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE enum, so virtio-serial
addresses were not freed properly for channel devices.

Call qemuDomainReleaseDeviceAddress uncoditionally and decide
based on the address type instead of the target/device types.
2015-07-01 08:09:43 +02:00
Luyao Huang
f967e7a669 qemu: fix address allocation on chardev attach
Also check the device type when deciding what type the address should
be. Commit 9807c47 (aiming to fix another error in address allocation)
only checked the target type, but its value is different for different
device types. This resulted in an error when trying to attach
a channel with target type 'virtio':

error: Failed to attach device from channel-file.xml
error: internal error: virtio serial device has invalid address type

Make the logic for releasing the address dependent only on
* the address type
* whether it was allocated earlier
to avoid copying the device and target type checks.

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

Signed-off-by: Luyao Huang <lhuang@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
2015-07-01 08:09:43 +02:00
Jim Fehlig
04597f8f0d libxl: Set def->vcpus after successfully modifying live vcpu count
def->vcpus was never updated after successfully changing the live
vcpu count of a domain. Subsequent queries for vcpu info would
return incorrect results.  E.g.:

virsh vcpucount test
maximum      config         4
maximum      live           4
current      config         4
current      live           4

virsh setvcpus test 2

virsh vcpucount test
maximum      config         4
maximum      live           4
current      config         4
current      live           4

After patch, live current config is reported correctly:

virsh vcpucount test
maximum      config         4
maximum      live           4
current      config         4
current      live           2

While fixing this, noticed that the live config was not saved
to cfg->stateDir via virDomainSaveStatus. Save the live config
and change error handling of virDomainSave{Config,Status} to
log a message via VIR_WARN, instead of failing the entire
DomainSetVcpusFlags operation.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2015-06-30 11:02:30 -06:00
Jim Fehlig
33be48d78e libxl: honor domainGetXMLDesc() --inactive flag
The libxl driver always uses virDomainObj->def when formatting
the domain XML description.  Use virDomainObj->newDef when
--inactive flag is set.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2015-06-30 11:02:30 -06:00
Jim Fehlig
4b53d0d4ac libxl: don't remove persistent domain on start failure
libxlDomainCreateXML() would remove a persistent domain if
libxlDomainStart() failed.  Check if domain is persistent
before removing.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2015-06-30 11:02:30 -06:00
Jim Fehlig
29b154e29a libxl: don't overwrite domain state from statedir config
When restarting libvirtd and reconnecting to running domains,
libxlReconnectDomain() would unconditionally set the domain state
to VIR_DOMAIN_RUNNING, overwriting the state maintained in
$statedir/<domname>.xml.  A domain in a paused state would have
the state changed to running, even though it was actually in a
paused state.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2015-06-30 11:02:29 -06:00
John Ferlan
0b32838394 qemu: Add missing on_crash lifecycle type
https://bugzilla.redhat.com/show_bug.cgi?id=1201760

When the domain "<on_crash>coredump-destroy</on_crash>" is set, the
domain wasn't being destroyed, rather it was being rebooted.

Add VIR_DOMAIN_LIFECYCLE_CRASH_COREDUMP_DESTROY to the list of
on_crash types that cause "-no-reboot" to be added to the qemu
command line.
2015-06-30 11:32:50 -04:00
John Ferlan
5cd985221b Use the correct symbol for 'onCrash'
Although defined the same way, fortunately there hadn't been any deviation.
Ensure any assignments to onCrash use VIR_DOMAIN_LIFECYCLE_CRASH_* defs and
not VIR_DOMAIN_LIFECYCLE_* defs
2015-06-30 11:32:50 -04:00