Am 09.07.2012 19:35, schrieb Corey Bryant:
On 07/09/2012 11:46 AM, Kevin Wolf wrote:
Am 09.07.2012 17:05, schrieb Corey Bryant:
I'm not sure this is an issue with current design. I know things have
changed a bit as the email threads evolved, so I'll paste the current
design that I am
On Thu, 05 Jul 2012 11:06:56 -0400
Corey Bryant cor...@linux.vnet.ibm.com wrote:
On 07/04/2012 04:09 AM, Kevin Wolf wrote:
Am 03.07.2012 20:21, schrieb Corey Bryant:
On 07/03/2012 02:00 PM, Eric Blake wrote:
On 07/03/2012 11:46 AM, Corey Bryant wrote:
Yes, I think adding a +1 to
Am 06.07.2012 19:40, schrieb Corey Bryant:
On 07/06/2012 05:11 AM, Kevin Wolf wrote:
Am 05.07.2012 19:00, schrieb Eric Blake:
On 07/05/2012 10:35 AM, Corey Bryant wrote:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount of 0; fd=4's in-use flag is turned on
2.
On 07/09/2012 10:05 AM, Luiz Capitulino wrote:
On Thu, 05 Jul 2012 11:06:56 -0400
Corey Bryant cor...@linux.vnet.ibm.com wrote:
On 07/04/2012 04:09 AM, Kevin Wolf wrote:
Am 03.07.2012 20:21, schrieb Corey Bryant:
On 07/03/2012 02:00 PM, Eric Blake wrote:
On 07/03/2012 11:46 AM, Corey
On 07/09/2012 10:04 AM, Kevin Wolf wrote:
Am 06.07.2012 19:40, schrieb Corey Bryant:
On 07/06/2012 05:11 AM, Kevin Wolf wrote:
Am 05.07.2012 19:00, schrieb Eric Blake:
On 07/05/2012 10:35 AM, Corey Bryant wrote:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount
Am 09.07.2012 17:23, schrieb Corey Bryant:
I think it would cause fds to sit on the monitor
until refcount gets to zero (monitor disconnects). Here's an example
without the in-use flag:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount of 1 (incremented because of
Am 09.07.2012 17:05, schrieb Corey Bryant:
I'm not sure this is an issue with current design. I know things have
changed a bit as the email threads evolved, so I'll paste the current
design that I am working from. Please let me know if you still see any
issues.
FD passing:
---
On Mon, 09 Jul 2012 17:46:00 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 09.07.2012 17:05, schrieb Corey Bryant:
I'm not sure this is an issue with current design. I know things have
changed a bit as the email threads evolved, so I'll paste the current
design that I am working from.
On 07/09/2012 11:46 AM, Kevin Wolf wrote:
Am 09.07.2012 17:05, schrieb Corey Bryant:
I'm not sure this is an issue with current design. I know things have
changed a bit as the email threads evolved, so I'll paste the current
design that I am working from. Please let me know if you still see
On Mon, 09 Jul 2012 13:35:19 -0400
Corey Bryant cor...@linux.vnet.ibm.com wrote:
On 07/09/2012 11:46 AM, Kevin Wolf wrote:
Am 09.07.2012 17:05, schrieb Corey Bryant:
I'm not sure this is an issue with current design. I know things have
changed a bit as the email threads evolved, so
On 07/09/2012 12:18 PM, Luiz Capitulino wrote:
On Mon, 09 Jul 2012 17:46:00 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 09.07.2012 17:05, schrieb Corey Bryant:
I'm not sure this is an issue with current design. I know things have
changed a bit as the email threads evolved, so I'll paste
On 07/09/2012 01:48 PM, Luiz Capitulino wrote:
On Mon, 09 Jul 2012 13:35:19 -0400
Corey Bryant cor...@linux.vnet.ibm.com wrote:
On 07/09/2012 11:46 AM, Kevin Wolf wrote:
Am 09.07.2012 17:05, schrieb Corey Bryant:
I'm not sure this is an issue with current design. I know things have
On 07/09/2012 11:05 AM, Corey Bryant wrote:
On 07/09/2012 10:05 AM, Luiz Capitulino wrote:
On Thu, 05 Jul 2012 11:06:56 -0400
Corey Bryant cor...@linux.vnet.ibm.com wrote:
On 07/04/2012 04:09 AM, Kevin Wolf wrote:
Am 03.07.2012 20:21, schrieb Corey Bryant:
On 07/03/2012 02:00 PM, Eric
Am 05.07.2012 19:00, schrieb Eric Blake:
On 07/05/2012 10:35 AM, Corey Bryant wrote:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount of 0; fd=4's in-use flag is turned on
2. client calls 'device-add' with /dev/fdset/1 as the backing filename,
so qemu_open()
Am 05.07.2012 18:37, schrieb Corey Bryant:
There is one case I'm aware of where we need to be careful: Before
opening an image, qemu may probe the format. In this case, the image
gets opened twice, and the first close comes before the second open.
I'm
not entirely sure how hard it would be to
On 07/06/2012 05:11 AM, Kevin Wolf wrote:
Am 05.07.2012 19:00, schrieb Eric Blake:
On 07/05/2012 10:35 AM, Corey Bryant wrote:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount of 0; fd=4's in-use flag is turned on
2. client calls 'device-add' with /dev/fdset/1 as
Ugh... please disregard this. I hit send accidentally.
On 07/06/2012 01:14 PM, Corey Bryant wrote:
On 07/06/2012 05:11 AM, Kevin Wolf wrote:
Am 05.07.2012 19:00, schrieb Eric Blake:
On 07/05/2012 10:35 AM, Corey Bryant wrote:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1
On 07/06/2012 05:11 AM, Kevin Wolf wrote:
Am 05.07.2012 19:00, schrieb Eric Blake:
On 07/05/2012 10:35 AM, Corey Bryant wrote:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount of 0; fd=4's in-use flag is turned on
2. client calls 'device-add' with /dev/fdset/1 as
On 07/06/2012 01:40 PM, Corey Bryant wrote:
On 07/06/2012 05:11 AM, Kevin Wolf wrote:
Am 05.07.2012 19:00, schrieb Eric Blake:
On 07/05/2012 10:35 AM, Corey Bryant wrote:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount of 0; fd=4's in-use flag is turned on
2.
On 07/04/2012 04:00 AM, Kevin Wolf wrote:
Am 03.07.2012 19:03, schrieb Eric Blake:
2. drive_add file=/dev/fdset/1 - qemu_open uses the first fd from the
set that has access flags matching the qemu_open action flags.
qemu_open increments refcount for this fd.
3. add-fd /dev/fdset/1 FDSET={M} -
Am 05.07.2012 16:22, schrieb Corey Bryant:
For some examples:
1. client calls 'add-fd', qemu is now tracking fd=4 with refcount 1, in
use by monitor, as member of fdset1
2. client crashes, so all tracked fds are visited; fd=4 had not yet been
passed to 'remove-fd', so qemu decrements
On 07/04/2012 04:09 AM, Kevin Wolf wrote:
Am 03.07.2012 20:21, schrieb Corey Bryant:
On 07/03/2012 02:00 PM, Eric Blake wrote:
On 07/03/2012 11:46 AM, Corey Bryant wrote:
Yes, I think adding a +1 to the refcount for the monitor makes sense.
I'm a bit unsure how to increment the refcount
On 07/05/2012 10:51 AM, Kevin Wolf wrote:
Am 05.07.2012 16:22, schrieb Corey Bryant:
For some examples:
1. client calls 'add-fd', qemu is now tracking fd=4 with refcount 1, in
use by monitor, as member of fdset1
2. client crashes, so all tracked fds are visited; fd=4 had not yet been
passed
On 07/05/2012 12:35 PM, Corey Bryant wrote:
On 07/05/2012 10:51 AM, Kevin Wolf wrote:
Am 05.07.2012 16:22, schrieb Corey Bryant:
For some examples:
1. client calls 'add-fd', qemu is now tracking fd=4 with refcount
1, in
use by monitor, as member of fdset1
2. client crashes, so all tracked
On 07/05/2012 10:35 AM, Corey Bryant wrote:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount of 0; fd=4's in-use flag is turned on
2. client calls 'device-add' with /dev/fdset/1 as the backing filename,
so qemu_open() increments the refcount of fdset1 to 1
3.
On 07/05/2012 01:00 PM, Eric Blake wrote:
On 07/05/2012 10:35 AM, Corey Bryant wrote:
1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
refcount of 0; fd=4's in-use flag is turned on
2. client calls 'device-add' with /dev/fdset/1 as the backing filename,
so qemu_open()
Am 03.07.2012 19:03, schrieb Eric Blake:
2. drive_add file=/dev/fdset/1 - qemu_open uses the first fd from the
set that has access flags matching the qemu_open action flags.
qemu_open increments refcount for this fd.
3. add-fd /dev/fdset/1 FDSET={M} - qemu adds fd to set named
/dev/fdset/1 -
Am 03.07.2012 20:21, schrieb Corey Bryant:
On 07/03/2012 02:00 PM, Eric Blake wrote:
On 07/03/2012 11:46 AM, Corey Bryant wrote:
Yes, I think adding a +1 to the refcount for the monitor makes sense.
I'm a bit unsure how to increment the refcount when a monitor reconnects
though. Maybe it
On Mon, Jul 02, 2012 at 04:31:09PM -0600, Eric Blake wrote:
On 07/02/2012 04:02 PM, Corey Bryant wrote:
Here's another option that Kevin and I discussed today on IRC. I've
modified a few minor details since the discussion. And Kevin please
correct me if anything is wrong.
Proposal
Am 03.07.2012 00:31, schrieb Eric Blake:
On 07/02/2012 04:02 PM, Corey Bryant wrote:
Here's another option that Kevin and I discussed today on IRC. I've
modified a few minor details since the discussion. And Kevin please
correct me if anything is wrong.
Proposal Four: Pass a set of fds
On 07/02/2012 06:31 PM, Eric Blake wrote:
On 07/02/2012 04:02 PM, Corey Bryant wrote:
Here's another option that Kevin and I discussed today on IRC. I've
modified a few minor details since the discussion. And Kevin please
correct me if anything is wrong.
Proposal Four: Pass a set of fds
On 07/02/2012 06:02 PM, Corey Bryant wrote:
On 06/26/2012 06:54 PM, Eric Blake wrote:
On 06/26/2012 04:28 PM, Corey Bryant wrote:
With this proposed series, we have usage akin to:
1. pass_fd FDSET={M} - returns a string /dev/fd/N showing
QEMU's
view of the FD
2. drive_add
Am 03.07.2012 17:40, schrieb Corey Bryant:
Thanks again for taking time to discuss this at today's QEMU community call.
Here's the proposal we discussed at the call. Please let me know if I
missed anything or if there are any issues with this design.
Proposal Five: New monitor commands
On 07/03/2012 11:59 AM, Kevin Wolf wrote:
Am 03.07.2012 17:40, schrieb Corey Bryant:
Thanks again for taking time to discuss this at today's QEMU community call.
Here's the proposal we discussed at the call. Please let me know if I
missed anything or if there are any issues with this
On 07/03/2012 10:25 AM, Corey Bryant wrote:
I thought qemu would rather return the number of the fdset (which it
also assigns if none it passed, i.e. for fdset creation). Does libvirt
need the number of an individual fd?
If libvirt prefers to assign fdset numbers itself, I'm not against it,
On 07/03/2012 01:03 PM, Eric Blake wrote:
On 07/03/2012 10:25 AM, Corey Bryant wrote:
I thought qemu would rather return the number of the fdset (which it
also assigns if none it passed, i.e. for fdset creation). Does libvirt
need the number of an individual fd?
If libvirt prefers to assign
On 07/03/2012 11:46 AM, Corey Bryant wrote:
Yes, I think adding a +1 to the refcount for the monitor makes sense.
I'm a bit unsure how to increment the refcount when a monitor reconnects
though. Maybe it is as simple as adding a +1 to each fd's refcount when
the next QMP monitor
On 07/03/2012 02:00 PM, Eric Blake wrote:
On 07/03/2012 11:46 AM, Corey Bryant wrote:
Yes, I think adding a +1 to the refcount for the monitor makes sense.
I'm a bit unsure how to increment the refcount when a monitor reconnects
though. Maybe it is as simple as adding a +1 to each fd's
On 06/26/2012 06:54 PM, Eric Blake wrote:
On 06/26/2012 04:28 PM, Corey Bryant wrote:
With this proposed series, we have usage akin to:
1. pass_fd FDSET={M} - returns a string /dev/fd/N showing QEMU's
view of the FD
2. drive_add file=/dev/fd/N
3. if failure:
On 07/02/2012 04:02 PM, Corey Bryant wrote:
Here's another option that Kevin and I discussed today on IRC. I've
modified a few minor details since the discussion. And Kevin please
correct me if anything is wrong.
Proposal Four: Pass a set of fds via 'pass-fds'. The group of fds
should
On Wed, 27 Jun 2012 10:58:01 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 26.06.2012 20:40, schrieb Corey Bryant:
Here is a quick proof of concept (ie untested) patch to demonstrate
what I mean. It relies on Cory's patch which converts everything
to use qemu_open. It is also still valuable
On 06/27/2012 05:51 AM, Kevin Wolf wrote:
Am 27.06.2012 11:20, schrieb Daniel P. Berrange:
On Wed, Jun 27, 2012 at 11:16:32AM +0200, Kevin Wolf wrote:
The really bad case that nobody thought of is that, when block-commit
has finished, we need to switch back to read-only. This is an event
Am 27.06.2012 00:28, schrieb Corey Bryant:
On 06/26/2012 04:50 PM, Luiz Capitulino wrote:
On Tue, 26 Jun 2012 13:45:52 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 26.06.2012 11:10, schrieb Daniel P. Berrange:
I was thinking about some of the sources complexity when using
FD passing from
Am 26.06.2012 20:40, schrieb Corey Bryant:
Here is a quick proof of concept (ie untested) patch to demonstrate
what I mean. It relies on Cory's patch which converts everything
to use qemu_open. It is also still valuable to make the change
to qemu_open() to support /dev/fd/N for passing FDs
Am 27.06.2012 00:54, schrieb Eric Blake:
It seems like libvirt would be in a better position to understand when a
file is no longer in use, and then it can call close_fd. No? Of course
the the only fd that needs to be closed is the originally passed fd. The
dup'd fd's are closed by QEMU.
On Wed, Jun 27, 2012 at 11:16:32AM +0200, Kevin Wolf wrote:
Am 27.06.2012 00:54, schrieb Eric Blake:
It seems like libvirt would be in a better position to understand when a
file is no longer in use, and then it can call close_fd. No? Of course
the the only fd that needs to be closed is
Am 27.06.2012 11:20, schrieb Daniel P. Berrange:
On Wed, Jun 27, 2012 at 11:16:32AM +0200, Kevin Wolf wrote:
The really bad case that nobody thought of is that, when block-commit
has finished, we need to switch back to read-only. This is an event that
is not triggered by a certain monitor
On 06/27/2012 04:43 AM, Kevin Wolf wrote:
Am 27.06.2012 00:28, schrieb Corey Bryant:
On 06/26/2012 04:50 PM, Luiz Capitulino wrote:
On Tue, 26 Jun 2012 13:45:52 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 26.06.2012 11:10, schrieb Daniel P. Berrange:
I was thinking about some of the
Am 26.06.2012 11:10, schrieb Daniel P. Berrange:
I was thinking about some of the sources complexity when using
FD passing from libvirt and wanted to raise one idea for discussion
before we continue.
With this proposed series, we have usage akin to:
1. pass_fd FDSET={M} - returns a
On Tue, Jun 26, 2012 at 09:52:51AM -0400, Corey Bryant wrote:
So now from a client's POV you'd have a flow like
* drive_add file=/dev/fd/N FDSET={N}
IIUC then drive_add would loop and pass each fd in the set via SCM_RIGHTS?
Yes, you'd probably use the JSON to tell QEMU exactly
how
On Tue, Jun 26, 2012 at 03:11:40PM +0100, Daniel P. Berrange wrote:
On Tue, Jun 26, 2012 at 09:52:51AM -0400, Corey Bryant wrote:
So now from a client's POV you'd have a flow like
* drive_add file=/dev/fd/N FDSET={N}
IIUC then drive_add would loop and pass each fd in the set via
On 06/26/2012 11:03 AM, Daniel P. Berrange wrote:
On Tue, Jun 26, 2012 at 03:11:40PM +0100, Daniel P. Berrange wrote:
On Tue, Jun 26, 2012 at 09:52:51AM -0400, Corey Bryant wrote:
So now from a client's POV you'd have a flow like
* drive_add file=/dev/fd/N FDSET={N}
IIUC then
On 06/26/2012 11:37 AM, Corey Bryant wrote:
On 06/26/2012 11:03 AM, Daniel P. Berrange wrote:
On Tue, Jun 26, 2012 at 03:11:40PM +0100, Daniel P. Berrange wrote:
On Tue, Jun 26, 2012 at 09:52:51AM -0400, Corey Bryant wrote:
So now from a client's POV you'd have a flow like
*
On Tue, Jun 26, 2012 at 02:40:03PM -0400, Corey Bryant wrote:
On 06/26/2012 11:37 AM, Corey Bryant wrote:
On 06/26/2012 11:03 AM, Daniel P. Berrange wrote:
On Tue, Jun 26, 2012 at 03:11:40PM +0100, Daniel P. Berrange wrote:
On Tue, Jun 26, 2012 at 09:52:51AM -0400, Corey Bryant wrote:
On Tue, 26 Jun 2012 13:45:52 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 26.06.2012 11:10, schrieb Daniel P. Berrange:
I was thinking about some of the sources complexity when using
FD passing from libvirt and wanted to raise one idea for discussion
before we continue.
With this
On 06/26/2012 04:50 PM, Luiz Capitulino wrote:
On Tue, 26 Jun 2012 13:45:52 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 26.06.2012 11:10, schrieb Daniel P. Berrange:
I was thinking about some of the sources complexity when using
FD passing from libvirt and wanted to raise one idea for
On 06/26/2012 04:42 PM, Daniel P. Berrange wrote:
On Tue, Jun 26, 2012 at 02:40:03PM -0400, Corey Bryant wrote:
On 06/26/2012 11:37 AM, Corey Bryant wrote:
On 06/26/2012 11:03 AM, Daniel P. Berrange wrote:
On Tue, Jun 26, 2012 at 03:11:40PM +0100, Daniel P. Berrange wrote:
On Tue, Jun
57 matches
Mail list logo
