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
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 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/20
On 07/09/2012 01:48 PM, Luiz Capitulino wrote:
On Mon, 09 Jul 2012 13:35:19 -0400
Corey Bryant 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 thr
On 07/09/2012 12:18 PM, Luiz Capitulino wrote:
On Mon, 09 Jul 2012 17:46:00 +0200
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
On Mon, 09 Jul 2012 13:35:19 -0400
Corey Bryant 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 I'll paste the cu
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 17:46:00 +0200
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 m
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:
> -
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 (increme
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 o
On 07/09/2012 10:05 AM, Luiz Capitulino wrote:
On Thu, 05 Jul 2012 11:06:56 -0400
Corey Bryant 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 thin
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
On Thu, 05 Jul 2012 11:06:56 -0400
Corey Bryant 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
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. cl
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 th
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 wi
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 th
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
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()
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() increm
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. c
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: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 t
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 w
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 d
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 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
>>>
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
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 ref
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 con
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 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 aga
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 design.
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 comm
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_ad
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 via
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 se
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.
> >
> >
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
> shou
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:
cl
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 that
On Wed, 27 Jun 2012 10:58:01 +0200
Kevin Wolf 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 to m
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 wrote:
Am 26.06.2012 11:10, schrieb Daniel P. Berrange:
I was thinking about some of the sources complexity w
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 monito
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 cl
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 QE
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 pa
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 wrote:
>>
>>> Am 26.06.2012 11:10, schrieb Daniel P. Berrange:
I was thinking about some of the sources complexity when using
FD passing f
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:
close_fd "/dev/fd/N"
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 2
On 06/26/2012 04:50 PM, Luiz Capitulino wrote:
On Tue, 26 Jun 2012 13:45:52 +0200
Kevin Wolf 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 c
On Tue, 26 Jun 2012 13:45:52 +0200
Kevin Wolf 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 proposed se
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
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
* drive_add
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 drive_
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
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 exactl
On 06/26/2012 05:10 AM, Daniel P. Berrange wrote:
On Fri, Jun 22, 2012 at 02:36:07PM -0400, Corey Bryant wrote:
libvirt's sVirt security driver provides SELinux MAC isolation for
Qemu guest processes and their corresponding image files. In other
words, sVirt uses SELinux to prevent a QEMU pro
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
59 matches
Mail list logo
