Kevin Wolf writes:
> Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben:
>> On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote:
>> > Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
>> > > From: Olga Krishtal
>> > >
>> > > While
On Mon, Jan 11, 2016 at 07:35:57PM +0100, Kevin Wolf wrote:
> Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben:
> > On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote:
> > > Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
> > > > From: Olga Krishtal
On Wed, Jan 13, 2016 at 12:12:10PM +0300, Denis V. Lunev wrote:
> On 01/13/2016 11:52 AM, Markus Armbruster wrote:
> >Kevin Wolf writes:
> >
> >>Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben:
> >>>On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote:
> Am
On 01/13/2016 11:52 AM, Markus Armbruster wrote:
Kevin Wolf writes:
Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben:
On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote:
Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
From: Olga Krishtal
On 01/13/2016 07:44 PM, Eric Blake wrote:
On 01/12/2016 05:10 PM, Fam Zheng wrote:
If we will switch default in my patch from 'nolock' to 'lock' then
pour guys which are calling qemu-img etc stuff will see the lock
as necessary while 'proper management software' aka libvirt
will be able to
On 01/12/2016 05:10 PM, Fam Zheng wrote:
>> If we will switch default in my patch from 'nolock' to 'lock' then
>> pour guys which are calling qemu-img etc stuff will see the lock
>> as necessary while 'proper management software' aka libvirt
>> will be able to call qemu/qemu-img etc with proper
Am 12.01.2016 um 06:38 hat Denis V. Lunev geschrieben:
> On 01/11/2016 08:31 PM, Kevin Wolf wrote:
> >Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
> >>From: Olga Krishtal
> >>
> >>While opening the image we want to be sure that we are the
> >>one who works with
Am 12.01.2016 um 12:33 hat Fam Zheng geschrieben:
> On Tue, 01/12 11:10, Kevin Wolf wrote:
> >
> > The problem is that libvirt already takes a lock, as Dan mentioned in
> > another reply in this thread, so we can't enable locking in qemu by
> > default. It would always fail when run under
On Tue, Jan 12, 2016 at 09:17:51PM +0800, Fam Zheng wrote:
> On Tue, 01/12 13:28, Kevin Wolf wrote:
> > Am 12.01.2016 um 12:33 hat Fam Zheng geschrieben:
> > > On Tue, 01/12 11:10, Kevin Wolf wrote:
> > > >
> > > > The problem is that libvirt already takes a lock, as Dan mentioned in
> > > >
On Tue, 01/12 13:28, Kevin Wolf wrote:
> Am 12.01.2016 um 12:33 hat Fam Zheng geschrieben:
> > On Tue, 01/12 11:10, Kevin Wolf wrote:
> > >
> > > The problem is that libvirt already takes a lock, as Dan mentioned in
> > > another reply in this thread, so we can't enable locking in qemu by
> > >
On Tue, 01/12 11:10, Kevin Wolf wrote:
>
> The problem is that libvirt already takes a lock, as Dan mentioned in
> another reply in this thread, so we can't enable locking in qemu by
> default. It would always fail when run under libvirt.
>
> Unless I'm seriously mistaken, this means that
On 01/12/2016 02:33 PM, Fam Zheng wrote:
On Tue, 01/12 11:10, Kevin Wolf wrote:
The problem is that libvirt already takes a lock, as Dan mentioned in
another reply in this thread, so we can't enable locking in qemu by
default. It would always fail when run under libvirt.
Unless I'm seriously
On 01/12/2016 02:33 PM, Fam Zheng wrote:
On Tue, 01/12 11:10, Kevin Wolf wrote:
The problem is that libvirt already takes a lock, as Dan mentioned in
another reply in this thread, so we can't enable locking in qemu by
default. It would always fail when run under libvirt.
Unless I'm seriously
On Tue, 01/12 13:24, Daniel P. Berrange wrote:
> On Tue, Jan 12, 2016 at 09:17:51PM +0800, Fam Zheng wrote:
> > On Tue, 01/12 13:28, Kevin Wolf wrote:
> > > Am 12.01.2016 um 12:33 hat Fam Zheng geschrieben:
> > > > On Tue, 01/12 11:10, Kevin Wolf wrote:
> > > > >
> > > > > The problem is that
On Tue, 01/12 18:59, Denis V. Lunev wrote:
> On 01/12/2016 02:33 PM, Fam Zheng wrote:
> >On Tue, 01/12 11:10, Kevin Wolf wrote:
> >>The problem is that libvirt already takes a lock, as Dan mentioned in
> >>another reply in this thread, so we can't enable locking in qemu by
> >>default. It would
On 01/11/2016 08:31 PM, Kevin Wolf wrote:
Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
From: Olga Krishtal
While opening the image we want to be sure that we are the
one who works with image, anf if it is not true -
opening the image for writing should fail.
Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
> From: Olga Krishtal
>
> While opening the image we want to be sure that we are the
> one who works with image, anf if it is not true -
> opening the image for writing should fail.
>
> There are 2 ways at the
Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben:
> On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote:
> > Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
> > > From: Olga Krishtal
> > >
> > > While opening the image we want to be sure that we
On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote:
> Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
> > From: Olga Krishtal
> >
> > While opening the image we want to be sure that we are the
> > one who works with image, anf if it is not true -
> >
On 12/23/2015 12:46 AM, Denis V. Lunev wrote:
> From: Olga Krishtal
>
> While opening the image we want to be sure that we are the
> one who works with image, anf if it is not true -
s/anf/and/
> opening the image for writing should fail.
>
> There are 2 ways at the
From: Olga Krishtal
While opening the image we want to be sure that we are the
one who works with image, anf if it is not true -
opening the image for writing should fail.
There are 2 ways at the moment: no lock at all and lock the file
image.
Signed-off-by: Olga
21 matches
Mail list logo