Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 16 6月, 2015 2 次提交
  3. 15 6月, 2015 3 次提交
  5. 12 6月, 2015 1 次提交
  7. 11 6月, 2015 6 次提交
  9. 10 6月, 2015 1 次提交
  11. 09 6月, 2015 1 次提交
  13. 08 6月, 2015 1 次提交
    • M
      utiltest: Use int8_t instead of char. · ceb46a66
      由 Michal Privoznik 提交于 
      Not every architecture out there has 'char' signed by default.
For instance, my arm box has it unsigned by default:

  $ gcc -dM -E - < /dev/null | grep __CHAR_UNSIGNED__
  #define __CHAR_UNSIGNED__ 1

Therefore, after 65c61e50 the test if failing for me. Problem is,
we are trying to assign couple of negative values into char
assuming some will overflow and some don't. That can't be the
case if 'char' is unsigned by default. Lets use more explicit types
instead: int8_t and uint8_t where is no ambiguity.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      ceb46a66
  15. 04 6月, 2015 1 次提交
    • J
      Always add 'console' matching the 'serial' device · 8728a78e
      由 Ján Tomko 提交于 
      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
      8728a78e
  17. 03 6月, 2015 3 次提交
    • P
      util: Add macro to overflow check integer assignments · 65c61e50
      由 Peter Krempa 提交于 
      Add a macro that will allow to simplify overflow checks and make them
more universal in case data types change.
      65c61e50
    • L
      network: validate DHCP ranges are completely within defined network · 1e334a0a
      由 Laine Stump 提交于 
      virSocketAddrGetRange() has been updated to take the network address
and prefix, and now checks that both the start and end of the range
are within that network, thus validating that the entire range of
addresses is in the network. For IPv4, it also checks that ranges to
not start with the "network address" of the subnet, nor end with the
broadcast address of the subnet (this check doesn't apply to IPv6,
since IPv6 doesn't have a broadcast or network address)

Negative tests have been added to the network update and socket tests
to verify that bad ranges properly generate an error.

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=985653
      1e334a0a
    • L
      test: fix IP address range failure test · 48e8b95d
      由 Laine Stump 提交于 
      This was revealed when I made a cut-paste mistake in an upgrade to
virSocketAddrGetRange(), leading to failure to check for the end
address being outside of the defined network, but a negative test case
that should have caught the error instead returned success.

The problem was that testRange in sockettest.c was written so that
when it expected a failure, even an "unexpected success" would be
considered as an "expected failure" because of the way the check in
testRange was done. testRange had this:

 if (gotsize < 0 || gotsize != size) {
     return pass ? -1 : 0;
 } else {
     return pass ? 0 : -1;
 }

but all the tests that expected a failure give "-1" as the expected
size. So in a case where we expect a failure, we would have pass ==
false and size == -1. If virSocketAddrGetRange() was incorrectly
*successful* (returned some positive number), then "gotsize != size"
would be, e.g. "276 != -1", so we would take the if clause and, since
pass == false, we would return 0 (success i.e. expected failure).

The solution is that in the case where we expect failure, we should
just ignore size - virSocketAddrGetRange() must return -1 in order for
us to report "expected failure == success".

Part of fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653
      48e8b95d
  19. 02 6月, 2015 3 次提交
  21. 01 6月, 2015 2 次提交
  23. 27 5月, 2015 1 次提交
  25. 26 5月, 2015 2 次提交
    • C
      conf: storage: Don't emit empty <permissions> block · 42dd6a99
      由 Cole Robinson 提交于
      42dd6a99
    • C
      storage: conf: Don't set any default <mode> in the XML · 7c2d65dd
      由 Cole Robinson 提交于 
      The XML parser sets a default <mode> if none is explicitly passed in.
This is then used at pool/vol creation time, and unconditionally reported
in the XML.

The problem with this approach is that it's impossible for other code
to determine if the user explicitly requested a storage mode. There
are some cases where we want to make this distinction, but we currently
can't.

Handle <mode> parsing like we handle <owner>/<group>: if no value is
passed in, set it to -1, and adjust the internal consumers to handle
it.
      7c2d65dd
  27. 24 5月, 2015 1 次提交
  29. 22 5月, 2015 3 次提交
  31. 21 5月, 2015 3 次提交
  33. 19 5月, 2015 3 次提交
    • J
      xenconfig: fix spice mousemode and copypaste · a5b55bd9
      由 Jim Fehlig 提交于 
      From xl.cfg950 man page:

spiceagent_mouse=BOOLEAN
Whether SPICE agent is used for client mouse mode. The default is
true (1) (turn on)

spicevdagent=BOOLEAN
Enables spice vdagent. The Spice vdagent is an optional component for
enhancing user experience and performing guest-oriented management
tasks. Its features includes: client mouse mode (no need to grab
mouse by client, no mouse lag), automatic adjustment of screen
resolution, copy and paste (text and image) between client and domU.
It also requires vdagent service installed on domU o.s. to work.
The default is 0.

spice_clipboard_sharing=BOOLEAN
Enables Spice clipboard sharing (copy/paste). It requires spicevdagent
enabled. The default is false (0).

So if spiceagent_mouse is enabled (client mouse mode) or
spice_clipboard_sharing is enabled, spicevdagent must be enabled.
Along with this change, s/spicedvagent/spicevdagent, set
spiceagent_mouse correctly, and add a test for these spice
features.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      a5b55bd9
    • J
      xenconfig: fix spicepasswd handling · a460295f
      由 Jim Fehlig 提交于 
      The logic related to spicedisable_ticketing and spicepasswd was
inverted.  As per man xl.cfg(5), 'spicedisable_ticketing = 1'
means no passwd is required.  On the other hand, a passwd is
required if 'spicedisable_ticketing = 0'.  Fix the logic and
produce and error if 'spicedisable_ticketing = 0' but spicepasswd
is not provided.  Also fix the spice cfg test file.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      a460295f
    • J
      xenconfig: format spice listenAddr when formating ports · e21b1180
      由 Jim Fehlig 提交于 
      Move formating of spice listenAddr to the section of code
where spice ports are formatted.  It is more logical to
format address and ports together.  Account for the change
in spice cfg test file by moving 'spicehost'.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      e21b1180
  35. 18 5月, 2015 2 次提交
  37. 16 5月, 2015 1 次提交
    • L
      qemu: log error when domain has an unsupported IDE controller · eadd757c
      由 Laine Stump 提交于 
      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)
      eadd757c