directory /var/lib alway is Persistence directory, but in redhat system,
/var/run is memory directory.
our running domain xml is saved at /var/run/libvirt/qemu. so if we cold reset
system,
the /var/run/libvirt/qemu directory is clear, but
/var/lib/libvirt/qemu/domain-*** is saved. so there
have
Ah, top-posting... So OK, we can change this. But if it is used only for
master.aes and monitor.sock, then there should not be that many places to be
changed. It is also super-easy to find mistakes by just building libvirt.
Still, the point about qemuSetPrivatePathsOld() stands, that must not
On 10/11/2017 10:52 AM, Erik Skultety wrote:
> We need to perform a sanity check on the udev monitor before every
> use so that we know nothing has changed in the meantime. The reason for
> moving the code to a separate helper is to enhance readability and shift
> the focus on the important stuff
On 10/11/2017 10:52 AM, Erik Skultety wrote:
> Adjust udevEventHandleThread to be a proper thread routine running in an
> infinite loop handling devices. The handler thread pulls all available
> data from the udev monitor and only then waits until a wakeup signal for
> new incoming data has been
On 10/11/2017 10:52 AM, Erik Skultety wrote:
> If we find ourselves in the situation that the 'add' uevent has been
> fired earlier than the sysfs tree for a device was created, we should
> use the best-effort approach and give kernel some predetermined amount
> of time, thus waiting for the attr
On 10/11/2017 10:52 AM, Erik Skultety wrote:
> This patch splits udevEventHandleCallback in two (introduces
> udevEventHandleThread) in order to be later able to refactor the latter
> to actually become a normal thread which will wait some time for the
> kernel to create the whole sysfs tree for
On 10/11/2017 10:52 AM, Erik Skultety wrote:
> Since we have a number of places where we workaround timing issues with
> devices, attributes (files in general) not being available at the time
> of processing them by calling usleep in a loop for a fixed number of
> tries, we could as well have a u
On 10/11/2017 10:52 AM, Erik Skultety wrote:
> Since there's going to be a worker thread which needs to have some data
> protected by a lock, the whole code would just simply get unnecessary
> complex, since two sets of locks would be necessary, driver lock (for
> udev monitor and event handle) a
ping?
Tks -
John
On 10/05/2017 09:22 AM, John Ferlan wrote:
> v4: https://www.redhat.com/archives/libvir-list/2017-September/msg00944.html
>
> Changes since v4 are minor - mostly to change from 3.8.0 to 3.9.0... Update
> the news.xml once is allowed for . Add a news.xml to describe
> the bug
