When setting parameters revolving around boot
mode, options, firmware, it is necessary to
extract and edit the XML document.
Some details, however, are not automatically
extracted and libvirt must be told to provide
secure information. This change prevents us
from accidently loosing such configuration
The current code logs the milliseconds twice:
2020-09-21 00:24:21,706.706 3484 DEBUG VirtualBMC [-] Get power...
The documentation for the logging module in py3 is quite
unambiguous about %(asctime) providing milliseconds.
The documentation in py2 is unclear on what is supposed
to offer, but in practice it works exactly as py3.
Now that we no longer support py27, we can use the standard library
unittest.mock module instead of the third party mock lib.
Signed-off-by: Sean McGinnis <firstname.lastname@example.org>
The new version enables a lot of standard flake8 checks, so a few
fixes are required. W503 is disabled as it conflicts with W504
and the latter seems to be preferred nowadays.
The daemon child processes do not respond to a SIGTERM. This means that
they stay running indefinitely. This is because the manager process
installs a SIGTERM handler to propagate the signal to children, and this
handler is inherited by the children.
Return children to the default handler for SIGTERM.
Removes the backward compatibility feature of `vbmc` to
automatically start up `vbmcd` daemon process if it is not running.
From now on, `vbmcd` should be started by systemd or some other
Added `error` status to `vbmc list` and `vbmc start`
commands output. If the instance is failing to start, such
instance will be shown as being in `error` satte rather
than being `down`.
Currently we log any exceptions as INFO and without much details.
Start logging them as ERROR with tracebacks. Add missing logging.
However, don't treat KeyboardInterrupt as an exception, just exit.
Also log the successful start-up, its absence is confusing.
Add validation to fix error of "'<' not supported between
instances of 'str' and 'int'" when defining server_response_timeout
value in virtualbmc.conf. The error is trigger because the
config parameters from the configuration file are read as strings
and everything else assume that value is an integer (as the default of 5000).
The patch also include validations for server_spawn_wait and server_port to
check the values are valid integers.
Updates test_config.test_validate for test coverage
Signed-off-by: William Caban <email@example.com>
Since we've dropped support for Python 2.7, it's time to look at
the bright future that Python 3.x will bring and stop forcing
compatibility with older versions.
This patch removes the six library from requirements, not
Adds the ability to override default configuration file location
by exporting the ``VIRTUALBMC_CONFIG`` variable, pointing to the
desired config file, into ``vbmcd`` and ``vbmc`` processes
This helps preserving backward-compatible behaviour, as previous
implementation has required the user to explicitly "start" enabled
instances. With current virtualbmc, only the master process needs to
Since log messages interpolation is frequently postponed
till the logging time, occasional bugs in message
templates may go unnoticed.
This patch attempts to enable full logging in unit tests.
Unfortunately, exceptions caused by interpolation failures
get inhibited by the logging module code so they do not
actually fail tests. But at least those exceptions are
noticeable on stdout.
When running with debug enabled, misnamed variable
in log message templates causes the whole app to
crash miserably. /o\
This patch makes vbmc immortal again.\o/
Apparently, variable interpolation in the log
messages turned out to be buggy and inconsistent.
This patch hopefully fixes all such issues and unifies
interpolation code across the project.
This is a followup patch to  making the `start` command accepting
multiple domain names in the same way as `stop` command does.
Possible duplicate domain names given on the command line removed
to avoid runtime errors.
This is a followup patch to  introducing configurable timing
parameters for the client to wait for automatic vbmcd start up and
vbmcd response timeout.
Original design of the VirtualBMC tool was that user manages
config files for individual VirtualBMC (via a cli tool), then
requests the tool to start the instances representing
individual VirtualBMC instances (via the cli tool). Then
the instances become independent processes. The only way
to know their whereabouts is through the pidfiles
There were certain practical inconveniences with the
original design, namely:
* Cumbersome to start/stop/monitor free-standing
vBMC instances processes
* No two-way communication between the parent process
and the VirtualBMC instances what makes child state check
or modification unnecessary difficult
This commit turns server part of the tool into a single
process spawning multiple children processes and herding
them via ZMQ client/server.
The parent process runs server part of the control
interface, maintains persistent VirtualBMC instances
configuration and ensures all its children are alive
and kicking. Each VirtualBMC instance is still a separate
If child dies, parent respawns it right away. If parent
is about to die, it tries its best to kill all the
This new implementation tries to stay compatible with
the original one in part of `vbmc` tool CLI interface
and behaviour. Whenever it can't connect to the `vbmcd`
it tries to fork and spawn the daemon behind the scenes.
While the threading design for this tool might look better,
the underlying pyghmi library is apparently rather
complicated to use its concurrency capabilities reliably.
The other minor consideration is that running multiple
processes leverages CPU-based concurrency.
* The `start` command now accepts more than one domains
to be started
With pyghmi API, some methods return generic IPMI error
codes, while some return payload values. This patch fixes
the `get_power_state()` method to raise exception instead
of returning IPMI error code because the latter goes against
This reverts commit 9f7bfb9f6b.
It seems that the SOL feature introduced by patch  led to
the VirtualBMC daemons leaking two file descriptors (ends of
UNIX pipe, perhaps) per each IPMI query it processes. Given the
default ulimit of 1024 open files per process, in circa 500 IPMI
queries vbmc renders itself not quite functional.
The quick research of the problem reveals that the leak comes
to life once the virEventRegisterDefaultImpl() call is made
which prepares libvirt for asynchronous operations over a dedicated
connection to libvirtd. Even though once SOL session is gone and
libvirt is cleaned up (well, dedicated connection is closed),
the libvirt connection, which is open every time when IPMI query
comes in, leaks 2 FDs per query.
This problem has been reported about some other libvirt application
in the past  so the problem might go away if we turn the IPMI
part of vbmc to the asynchronous operation mode as well.
Another observation is that libvirt API may not  offer a full
clean up upon exiting from the asynchronous operation mode.
To summarize: the real cause of this behaviour is not yet properly
It seems that at times of high concurrency, libvirt
occassionally fails on supposedly some race condition
what leads to client failure (e.g. Ironic). This change
is to tell Ironic that it should try some more times rather
than bailing out right away.
This patch adds some methods to support Serial-over-LAN capability.
We'll be able to connect serial console of a domain with
"ipmitool sol activate" command.
SOL capability requires a persistent libvirt connection, so this
patchset adds libvirt_open.get_conn() method and use it.
This patch replaces the use of argparse module
by the cliff package. The rationale is that
cliff infrastructure is easier to use and more
functional. Some other OpenStack projects seem
to migrate to cliff already.
"boot" entries under "devices/*" are mutually exclusive with those
under "os". If such entries are present, vbmc fails when adding "boot"
entry under "os".