Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 11 11月, 2019 13 次提交
    • P
      tests: make domaincapstest less anoying to debug · 63d60408
      由 Peter Krempa 提交于 
      Since 6a077cf2 domaincapstest does not run through all cases on
failure but terminates right away. This makes it super annoying to debug
or use in combination with VIR_TEST_REGENERATE_OUTPUT.

Fix it by remembering failure and still running through all cases.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      63d60408
    • D
      build: fix substitution of RUNSTATEDIR in man pages · d64f31dc
      由 Daniel P. Berrangé 提交于 
      When RUNSTATEDIR was introduced

  commit d29c917e
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Tue Aug 20 16:05:12 2019 +0100

    src: honour the RUNSTATEDIR variable in all code

The makefile rules for man pages were accidentally not updated for the
new variablle name.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      d64f31dc
    • D
      build: comment on why we're not adopting certain flake8 rules · 07943d35
      由 Daniel P. Berrangé 提交于 
      Simplify the list of ignored warnings now that we only have two left,
and document why we're not honouring them.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      07943d35
    • D
      python: sanitize indentation after line continuations · 3df69e62
      由 Daniel P. Berrangé 提交于 
      Line continuations should be 4 space indented unless a previous opening
brace required different alignment.

docs/apibuild.py:2014:24: E126 continuation line over-indented for hanging indent
                       token[0], token[1]))
                       ^
docs/apibuild.py:74:3: E121 continuation line under-indented for hanging indent
  "ATTRIBUTE_UNUSED": (0, "macro keyword"),
  ^
...more...
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      3df69e62
    • D
      python: sanitize spaces either side of operators · 43d29cb4
      由 Daniel P. Berrangé 提交于 
      There should be a single space either side of operators. Inline
comments should have two spaces before the '#'

src/hyperv/hyperv_wmi_generator.py:130:45: E261 at least two spaces before inline comment
            source += '    { "", "", 0 },\n' # null terminated
                                            ^
src/esx/esx_vi_generator.py:417:25: E221 multiple spaces before operator
    FEATURE__DESERIALIZE  = (1 << 6)
                        ^
tests/cputestdata/cpu-cpuid.py:187:78: E225 missing whitespace around operator
                f.write("  <msr index='0x%x' edx='0x%08x' eax='0x%08x'/>\n" %(
                                                                             ^
docs/apibuild.py:524:47: E226 missing whitespace around arithmetic operator
                            self.line = line[i+2:]
                                              ^
...more...
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      43d29cb4
    • D
      python: sanitize blank line usage · bc59247d
      由 Daniel P. Berrangé 提交于 
      Coding style expects 1 blank line between each method and 2 blank lines
before each class.

docs/apibuild.py:171:5: E303 too many blank lines (2)
    def set_header(self, header):
    ^
docs/apibuild.py:230:1: E302 expected 2 blank lines, found 1
class index:
^
docs/apibuild.py:175:5: E301 expected 1 blank line, found 0
    def set_module(self, module):
    ^
...more...
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      bc59247d
    • D
      python: avoid bare 'except:' clause · 2ba699cb
      由 Daniel P. Berrangé 提交于 
      Exception catching statements should always match on a class name, the
most specific one possible. Rather than analyse the code to look at what
the most specific one is, this just uses the base Exception class.

docs/apibuild.py:255:9: E722 do not use bare 'except'
        except:
        ^
docs/apibuild.py:279:9: E722 do not use bare 'except'
        except:
        ^
...more...
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      2ba699cb
    • D
      python: avoid variable named 'l' · cfdd871f
      由 Daniel P. Berrangé 提交于 
      Python code style recommends avoiding a variable named 'l' as it is
visually similar to '1'.

docs/apibuild.py:482:13: E741 ambiguous variable name 'l'
            l = len(line)
            ^
docs/apibuild.py:503:21: E741 ambiguous variable name 'l'
                    l = len(line)
                    ^
...more...
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      cfdd871f
    • D
      python: mark regex strings with 'r' prefix · d5c5d8af
      由 Daniel P. Berrangé 提交于 
      When writing regexes special regex matches like "\d" can get
misinterpreted as normal string escape sequences:

docs/apibuild.py:1359:51: W605 invalid escape sequence '\d'
                        value = value + re.sub("^(\d+)U$", "\\1", token[1])
                                                  ^
docs/apibuild.py:2134:31: W605 invalid escape sequence '\('
                m = re.match("\(?1<<(\d+)\)?", info[0])
                              ^
docs/apibuild.py:2134:38: W605 invalid escape sequence '\d'
                m = re.match("\(?1<<(\d+)\)?", info[0])
                                     ^
docs/apibuild.py:2134:42: W605 invalid escape sequence '\)'
                m = re.match("\(?1<<(\d+)\)?", info[0])
                                         ^

To avoid this probem all regexes should use the r"...." syntax for their
strings, which disables normal string escape sequences.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      d5c5d8af
    • D
      python: fix use of undeclared variables in python scripts · 524b377e
      由 Daniel P. Berrangé 提交于 
      docs/apibuild.py:2436:65: F821 undefined name 'first_letter'
                        chunks.append(["chunk%s" % (chunk - 1), first_letter, letter])
                                                                ^
src/hyperv/hyperv_wmi_generator.py:415:57: F821 undefined name 'number'
        report_error("line %d: invalid block header" % (number))
                                                        ^
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      524b377e
    • D
      build: change flake8 to use blacklist instead of whitelist · 3a5fea60
      由 Daniel P. Berrangé 提交于 
      The current flake8 check only looks at one item (semicolons at end of
line). This means that our code quality will continue to get worse,
violating an increasing number of checks.

Switching to a whitelist means that we freeze the badness at its
current level & can incrementally fix things up.

We are excluding the following...

Indentation:

  E114 indentation is not a multiple of four (comment)
  E115 expected an indented block (comment)
  E116 unexpected indentation (comment)
  E121 continuation line under-indented for hanging indent
  E125 continuation line with same indent as next logical line
  E126 continuation line over-indented for hanging indent
  E127 continuation line over-indented for visual indent
  E128 continuation line under-indented for visual indent
  E129 visually indented line with same indent as next logical line
  E131 continuation line unaligned for hanging indent

Whitespace:

  E211 whitespace before ‘(‘
  E221 multiple spaces before operator
  E222 multiple spaces after operator
  E225 missing whitespace around operator
  E226 missing whitespace around arithmetic operator
  E231 missing whitespace after ‘,’, ‘;’, or ‘:’
  E261 at least two spaces before inline comment

Blank lines

  E301 expected 1 blank line, found 0
  E302 expected 2 blank lines, found 0
  E303 too many blank lines (3)
  E305 expected 2 blank lines after end of function or class

Line length

  E501 line too long (82 > 79 characters)

Statements

  E722 do not use bare except, specify exception instead
  E741 do not use variables named ‘l’, ‘O’, or ‘I’

Errors:

  F821 undefined name 'name'

Warnings:

  W504 line break after binary operator
  W605 invalid escape sequence ‘x’

Later commits will enable most of these exclusions.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      3a5fea60
    • D
      docs: remove some dead code in apibuild.py · 55cbe0fb
      由 Daniel P. Berrangé 提交于 
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      55cbe0fb
    • P
      spec: fix rpm build with VPATH · c4192960
      由 Pavel Hrdina 提交于 
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
      c4192960
  3. 10 11月, 2019 1 次提交
  5. 09 11月, 2019 22 次提交
  7. 08 11月, 2019 4 次提交
    • M
      qemu: Check for job being set when getting iothread stats · 3d46d684
      由 Michal Privoznik 提交于 
      The qemuDomainGetStatsIOThread() accesses the monitor by calling
qemuDomainGetIOThreadsMon(). And it's also marked as "need
monitor" in qemuDomainGetStatsWorkers[]. However, it's not
checking if acquiring job was successful.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJonathon Jongsma <jjongsma@redhat.com>
      3d46d684
    • M
      qemu: Warn on possibly incorrect usage of EnterMonitor* · 1faf7405
      由 Michal Privoznik 提交于 
      The qemuDomainObjEnterMonitor() should not be called without a
job set. Catch this error and produce a warning message if such
call occurred.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJonathon Jongsma <jjongsma@redhat.com>
      1faf7405
    • W
      util: Set SIGPIPE to a no-op handler in virFork · ebd00429
      由 Wang Yechao 提交于 
      Libvirtd has set SIGPIPE to ignored, and virFork resets all signal
handlers to the defaults. But child process may write logs to
stderr/stdout, that may generate SIGPIPE if journald has stopped.

So set SIGPIPE to a dummy no-op handler before unmask signals in
virFork(), and the handler will get reset to SIG_DFL when execve()
runs. Now we can delete sigaction() call entirely in virExec().
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NWang Yechao <wang.yechao255@zte.com.cn>
      ebd00429
    • L
      util: set bridge device MAC address explicitly during virNetDevBridgeCreate · 13ec8270
      由 Laine Stump 提交于 
      When libvirt first implemented a stable and configurable MAC address
for the bridges created for libvirt virtual networks (commit
5754dbd5, in libvirt v0.8.8) most distro stable releases didn't
support explicitly setting the MAC address of a bridge; the bridge
just always assumed the lowest numbered MAC of all attached
interfaces. Because of this, we stabilized the bridge MAC address by
creating a "dummy" tap interface with a MAC address guaranteed to be
lower than any of the guest tap devices' MACs (which all started with
0xFE, so it's not difficult to do) and attached it to the bridge -
this was the inception of the "virbr0-nic" device that has confused so
many people over the years.

Even though the linux kernel had recently gained support for
explicitly setting a bridge MAC, we deemed it unnecessary to set the
MAC that way, because the other (indirect) method worked everywhere.

But recently there have been reports that the bridge MAC address was
not following the setting in the network config, and mismatched the
MAC of the dummy tap device (which was still correct). It turns out
that this is due to a change in systemd-242 that persists whatever MAC
address is set for a bridge when it's initially started. According to
the systemd NEWS file entry for version 242
(https://github.com/systemd/systemd/blob/master/NEWS):

  "if a bridge interface is created without any slaves, and gains
   a slave later, then now the bridge does not inherit slave's MAC."

This change was the result of:

  https://github.com/systemd/systemd/issues/3374

(apparently if there is no MAC saved for a bridge by the name of a
bridge being created, the random MAC generated during creation is
saved, and then that same MAC is used to explicitly set the MAC each
time it is created). Once a bridge has an explicitly set MAC, the "use
the lowest numbered MAC of attached devices" rule is ignored, so our
dummy tap device is like the goggles - it does nothing! (well, almost).

We could whine about changes in default behavior, etc. etc., but
because the change was in response to actual user problems, that seems
likely a fruitless task. Fortunately, time has marched on, and even
distro releases that are old enough that they are no longer supported
by upstream libvirt (e.g. RHEL6) have support for explicitly setting a
bridge device MAC address, either during creation or with a separate
ioctl after creation, so we can now do that.

To enable explicitly setting the mac during bridge creation, we add a
mac arg to virNetDevBridgeCreate().  In the case of platforms where
the bridge is created with a netlink RTM_NEWLINK message, we just add
that mac to the message. For platforms that still use an ioctl (either
SIOCBRADDBR or SIOCIFCREATE2), we make a separate call to
virNetDevSetMAC() after creating the bridge.

(NB: I was unable to test the calling of virNetDevSetMAC() from the
SIOCIFCREATE2 (BSD) version of virNetDevBridgeCreate(); even though I
managed to get a FreeBSD system setup and libvirt built there, when I
tried to start the default network the SIOCIFCREATE2 ioctl itself
failed, so it never even got to the virNetDevSetMAC(). That leaves the
FreeBSD implementation untested.)

This makes the dummy tap pointless for purposes of setting the MAC
address, but it is still useful for IPv6 DAD initialization (which
apparently requires at least one interface to be attached to the
bridge and online), as well as for setting an initial MTU for the
bridge, so it hasn't been removed.

(NB: we can safely *always* call virNetDevBridgeCreate() with
&def->mac from the network driver because, in spite of the existence
of a "mac_specified" bool in the config suggesting that it may not
always be present, in reality a mac address will always be added to
any network that doesn't have one - this is guaranteed in all cases by
commit a47ae7c0)

https://bugzilla.redhat.com/show_bug.cgi?id=1760851Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
      13ec8270