On 10/07/19 11:03, Daniel P. Berrangé wrote:
>> Would it be possible to make QEMU the broker? That is, how hard would it
>> be to embed a minimal DBus broker (which only takes care of connecting
>> servers
>> and clients---stuff like launching servers would be completely out of scope)?
> What wou
On Tue, Jul 09, 2019 at 02:47:32PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Tue, Jul 9, 2019 at 1:02 PM Daniel P. Berrangé wrote:
> >
> > On Tue, Jul 09, 2019 at 12:26:38PM +0400, Marc-André Lureau wrote:
> > > Hi
> > >
> > > On Mon, Jul 8, 2019 at 8:04 PM Daniel P. Berrangé
> > > wrote:
> >
On Wed, Jul 10, 2019 at 10:53:10AM +0200, Paolo Bonzini wrote:
> On 08/07/19 18:04, Daniel P. Berrangé wrote:
> > The downside of using the bus daemon is that we have to spawn a new
> > instance of dbus-daemon for every QEMU VM that's running on the host,
> > which is yet more memory overhead for e
On 08/07/19 18:04, Daniel P. Berrangé wrote:
> The downside of using the bus daemon is that we have to spawn a new
> instance of dbus-daemon for every QEMU VM that's running on the host,
> which is yet more memory overhead for each VM & another process to
> manage, and yet another thing to go wrong
Hi
On Tue, Jul 9, 2019 at 1:02 PM Daniel P. Berrangé wrote:
>
> On Tue, Jul 09, 2019 at 12:26:38PM +0400, Marc-André Lureau wrote:
> > Hi
> >
> > On Mon, Jul 8, 2019 at 8:04 PM Daniel P. Berrangé
> > wrote:
> > > > The D-Bus protocol can be made to work peer-to-peer, but the most
> > > > common
On Tue, Jul 09, 2019 at 12:26:38PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Mon, Jul 8, 2019 at 8:04 PM Daniel P. Berrangé wrote:
> > > The D-Bus protocol can be made to work peer-to-peer, but the most
> > > common and practical way is through a bus daemon. This also has the
> > > advantage of
Hi
On Mon, Jul 8, 2019 at 8:04 PM Daniel P. Berrangé wrote:
> > The D-Bus protocol can be made to work peer-to-peer, but the most
> > common and practical way is through a bus daemon. This also has the
> > advantage of increased debuggability (you can eavesdrop on the bus and
> > introspect it).
On Mon, Jul 08, 2019 at 04:44:06PM +0100, Dr. David Alan Gilbert wrote:
> * Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
> > Hi,
> >
> > With external processes or helpers participating to the VM support, it
> > becomes necessary to handle their migration. Various options exist to
> > tr
On Mon, Jul 08, 2019 at 11:24:34AM +0400, Marc-André Lureau wrote:
> Hi,
>
> With external processes or helpers participating to the VM support, it
> becomes necessary to handle their migration. Various options exist to
> transfer their state:
> 1) as the VM memory, RAM or devices (we could say th
* Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
> Hi,
>
> With external processes or helpers participating to the VM support, it
> becomes necessary to handle their migration. Various options exist to
> transfer their state:
> 1) as the VM memory, RAM or devices (we could say that's how
>
Patchew URL:
https://patchew.org/QEMU/20190708072437.3339-1-marcandre.lur...@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/b
Patchew URL:
https://patchew.org/QEMU/20190708072437.3339-1-marcandre.lur...@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/b
Hi,
With external processes or helpers participating to the VM support, it
becomes necessary to handle their migration. Various options exist to
transfer their state:
1) as the VM memory, RAM or devices (we could say that's how
vhost-user devices can be handled today, they are expected to
re
13 matches
Mail list logo
