Am 06.04.2017 um 10:48 hat Kevin Wolf geschrieben:
> Am 05.04.2017 um 23:13 hat Paolo Bonzini geschrieben:
> > On 05/04/2017 13:01, Kevin Wolf wrote:
> > > Am 04.04.2017 um 17:09 hat Paolo Bonzini geschrieben:
> > >> On 04/04/2017 16:53, Kevin Wolf wrote:
> > The big question is how this fits
Am 05.04.2017 um 23:13 hat Paolo Bonzini geschrieben:
> On 05/04/2017 13:01, Kevin Wolf wrote:
> > Am 04.04.2017 um 17:09 hat Paolo Bonzini geschrieben:
> >> On 04/04/2017 16:53, Kevin Wolf wrote:
> The big question is how this fits into release management. We have
> another important re
On 05/04/2017 13:01, Kevin Wolf wrote:
> Am 04.04.2017 um 17:09 hat Paolo Bonzini geschrieben:
>> On 04/04/2017 16:53, Kevin Wolf wrote:
The big question is how this fits into release management. We have
another important regression from the op blocker work and only a week
to go b
Am 04.04.2017 um 17:09 hat Paolo Bonzini geschrieben:
> On 04/04/2017 16:53, Kevin Wolf wrote:
> >> The big question is how this fits into release management. We have
> >> another important regression from the op blocker work and only a week
> >> to go before the last rc. Are we going to delay 2.
On 04/04/2017 16:53, Kevin Wolf wrote:
>> The big question is how this fits into release management. We have
>> another important regression from the op blocker work and only a week
>> to go before the last rc. Are we going to delay 2.9 arbitrarily? Are
>> we going to shorten the 2.10 developm
Am 04.04.2017 um 16:04 hat Paolo Bonzini geschrieben:
> On 04/04/2017 14:16, Kevin Wolf wrote:
> > Just not requesting the
> > write permission initially if runstate_check(RUN_STATE_INMIGRATE) is
> > easy. But we need to find a place to actually request it later, after
> > the mirror has completed,
On 04/04/2017 14:16, Kevin Wolf wrote:
> Just not requesting the
> write permission initially if runstate_check(RUN_STATE_INMIGRATE) is
> easy. But we need to find a place to actually request it later, after
> the mirror has completed, and before the VM is running.
Isn't there already a bdrv_inv
Am 04.04.2017 um 15:27 hat Peter Krempa geschrieben:
> On Tue, Apr 04, 2017 at 15:19:02 +0200, Kevin Wolf wrote:
> > Am 03.04.2017 um 14:51 hat Peter Krempa geschrieben:
> > > On Mon, Apr 03, 2017 at 10:15:42 +0200, Kevin Wolf wrote:
> > > > Am 31.03.2017 um 19:43 hat Max Reitz geschrieben:
> > > >
On 04/04/2017 07:16 AM, Kevin Wolf wrote:
>
> Now the big question is how to implement this. Just not requesting the
> write permission initially if runstate_check(RUN_STATE_INMIGRATE) is
> easy. But we need to find a place to actually request it later, after
> the mirror has completed, and befor
On Tue, Apr 04, 2017 at 15:19:02 +0200, Kevin Wolf wrote:
> Am 03.04.2017 um 14:51 hat Peter Krempa geschrieben:
> > On Mon, Apr 03, 2017 at 10:15:42 +0200, Kevin Wolf wrote:
> > > Am 31.03.2017 um 19:43 hat Max Reitz geschrieben:
> > > > On 31.03.2017 18:03, Ciprian Barbu wrote:
[...]
> > > Pete
Am 03.04.2017 um 14:51 hat Peter Krempa geschrieben:
> On Mon, Apr 03, 2017 at 10:15:42 +0200, Kevin Wolf wrote:
> > Am 31.03.2017 um 19:43 hat Max Reitz geschrieben:
> > > On 31.03.2017 18:03, Ciprian Barbu wrote:
>
> [...]
>
> > > So this doesn't work:
> > >
> > > $ x86_64-softmmu/qemu-system-
Am 03.04.2017 um 15:50 hat Peter Krempa geschrieben:
> On Mon, Apr 03, 2017 at 15:00:41 +0200, Kevin Wolf wrote:
> > If I understand correctly, this is a case of incoming live migration,
> > i.e. the virtio-blk device which is blocking the writes to the image
> > doesn't really belong to a running
On Tue, Apr 04, 2017 at 01:00:08PM +0200, Paolo Bonzini wrote:
>
>
> On 04/04/2017 10:17, ciprian.barbu wrote:
> >>
> >> but we do NOT make any guarantees of supporting
> >>
> >> new qemu, old libvirt
> >
> > Sounds reasonable enough, I guess we didn't look at it this way.
>
> Yes, but usually
On 04/04/2017 10:17, ciprian.barbu wrote:
>>
>> but we do NOT make any guarantees of supporting
>>
>> new qemu, old libvirt
>
> Sounds reasonable enough, I guess we didn't look at it this way.
Yes, but usually it's "new qemu, very old libvirt", like several years
old. I think this should be tr
Hi,
On 03.04.2017 22:44, Eric Blake wrote:
On 04/03/2017 07:39 AM, Max Reitz wrote:
As for just allowing the NBD server write access to the device... To me
that appears pretty difficult from an implementation perspective. We
assert that nobody can write without having requested write access and
Hi,
On 03.04.2017 21:52, Kashyap Chamarthy wrote:
On Fri, Mar 31, 2017 at 05:49:52PM +, Ciprian Barbu wrote:
Hi,
[...]
We also use libvirt v1.3.4, which might be a problem, but at least we
want to understand if the commit in question introduced an obvious
problem or if it's all in the d
On 04/03/2017 08:00 AM, Kevin Wolf wrote:
>> The question remains whether it is practical not to make an exception.
>> As far as I know, libvirt is only guaranteed to support older qemu
>> versions, not necessarily future ones. So we should be allowed to break
>> existing use cases here until libvi
On 04/03/2017 07:39 AM, Max Reitz wrote:
>>> As for just allowing the NBD server write access to the device... To me
>>> that appears pretty difficult from an implementation perspective. We
>>> assert that nobody can write without having requested write access and
>>> we make sure that nobody can r
On Fri, Mar 31, 2017 at 05:49:52PM +, Ciprian Barbu wrote:
> Hi,
[...]
> We also use libvirt v1.3.4, which might be a problem, but at least we
> want to understand if the commit in question introduced an obvious
> problem or if it's all in the details.
A tangential question -- Just curious,
On Mon, Apr 03, 2017 at 15:00:41 +0200, Kevin Wolf wrote:
> Am 03.04.2017 um 14:39 hat Max Reitz geschrieben:
> > On 03.04.2017 10:15, Kevin Wolf wrote:
> > > Am 31.03.2017 um 19:43 hat Max Reitz geschrieben:
> >
> > [...]
> >
> > >> So in theory all that's necessary is to set share-rw=on for the
Am 03.04.2017 um 14:39 hat Max Reitz geschrieben:
> On 03.04.2017 10:15, Kevin Wolf wrote:
> > Am 31.03.2017 um 19:43 hat Max Reitz geschrieben:
>
> [...]
>
> >> So in theory all that's necessary is to set share-rw=on for the device
> >> in the management layer. But I'm not sure whether that's pr
On Mon, Apr 03, 2017 at 10:15:42 +0200, Kevin Wolf wrote:
> Am 31.03.2017 um 19:43 hat Max Reitz geschrieben:
> > On 31.03.2017 18:03, Ciprian Barbu wrote:
[...]
> > So this doesn't work:
> >
> > $ x86_64-softmmu/qemu-system-x86_64 \
> > -blockdev node-name=image,driver=qcow2,\
> > file.driv
On 03.04.2017 10:15, Kevin Wolf wrote:
> Am 31.03.2017 um 19:43 hat Max Reitz geschrieben:
[...]
>> So in theory all that's necessary is to set share-rw=on for the device
>> in the management layer. But I'm not sure whether that's practical.
>
> Yes, libvirt needs to provide this option if the g
Am 31.03.2017 um 19:43 hat Max Reitz geschrieben:
> On 31.03.2017 18:03, Ciprian Barbu wrote:
> > Hello,
> >
> > Similar to the other thread about possible regression with rbd, there might
> > be a regression with nbd.
> > This time we are launching an instance from an image (not volume) and try
Hi,
> -Original Message-
> From: Max Reitz [mailto:mre...@redhat.com]
> Sent: Friday, March 31, 2017 8:57 PM
> To: Ciprian Barbu; qemu-devel@nongnu.org; Eric Blake; Alexandru Avadanii
> Cc: Jeff Cody; Markus Armbruster; svc-armband; Kevin Wolf
> Subject: Re: [Qemu-de
On 31.03.2017 19:49, Ciprian Barbu wrote:
> Hi,
>
> Thank you for getting back!
>
> I'm trying to follow you, but I don't understand all the details. I would
> like to ask this question though:
>
> What is the difference between v2.8.0 and this commit? With v2.8.0 the same
> qemu command worke
Ciprian
-Original Message-
From: Max Reitz [mailto:mre...@redhat.com]
Sent: Friday, March 31, 2017 8:43 PM
To: Ciprian Barbu ; qemu-devel@nongnu.org; Eric Blake
; Alexandru Avadanii
Cc: Jeff Cody ; Markus Armbruster ;
svc-armband ; Kevin Wolf
Subject: Re: [Qemu-devel] nbd: Possible regres
On 31.03.2017 18:03, Ciprian Barbu wrote:
> Hello,
>
> Similar to the other thread about possible regression with rbd, there might
> be a regression with nbd.
> This time we are launching an instance from an image (not volume) and try to
> live migrate it:
>
> nova live-migration
>
> The nova
Cody ; Markus Armbruster ;
svc-armband
Subject: RE: [Qemu-devel] nbd: Possible regression in 2.9 RCs
I suspect the culprit here is [1]. I've started a git bisect between this
commit and v2.8.0 and during this time I found similar erros
"/root/qemu/nbd/server.c:nbd_receive_reque
f Cody ; Markus Armbruster ;
svc-armband
Subject: [Cosnos] [Qemu-devel] nbd: Possible regression in 2.9 RCs
Hello,
Similar to the other thread about possible regression with rbd, there might be
a regression with nbd.
This time we are launching an instance from an image (not volume) and try to
Hello,
Similar to the other thread about possible regression with rbd, there might be
a regression with nbd.
This time we are launching an instance from an image (not volume) and try to
live migrate it:
nova live-migration
The nova-compute service complains with:
2017-03-31 15:32:56.179 7806
31 matches
Mail list logo
