[Qemu-devel] KVM call agenda for Jan 11

[Qemu-devel] KVM call agenda for Jan 11

[Juan Quintela]

Please send any agenda items you are interested in covering.

- KVM Forum 2011 (Jes).

thanks, Juan.

Re: KVM call agenda for Jan 11

[Juan Quintela]

Juan Quintela <quintela@redhat.com> wrote:

Now sent it to the right kvm list.  Sorry for the second sent.

> Please send any agenda items you are interested in covering.
>
> - KVM Forum 2011 (Jes).
>
> thanks, Juan.

[Qemu-devel] Re: KVM call agenda for Jan 11

[Juan Quintela]

Juan Quintela <quintela@redhat.com> wrote:

Now sent it to the right kvm list.  Sorry for the second sent.

> Please send any agenda items you are interested in covering.
>
> - KVM Forum 2011 (Jes).
>
> thanks, Juan.

Re: [Qemu-devel] Re: KVM call agenda for Jan 11

[Jes Sorensen]

On 01/10/11 12:59, Juan Quintela wrote:
> Juan Quintela <quintela@redhat.com> wrote:
> 
> Now sent it to the right kvm list.  Sorry for the second sent.
> 
>> Please send any agenda items you are interested in covering.
>>
>> - KVM Forum 2011 (Jes).

Just to add a bit more background. Last year we discussed the issue of
whether to aim for a KVM Forum in the same style as we had in 2010, or
whether to try to aim for a broader multi-track Virtualization
conference that covers the whole stack.

Linux Foundation is happy to help host such an event, but they are
asking for what our plans are. I posted a mock-proposal for tracks here:
http://www.linux-kvm.org/page/KVM_Forum_2011

Cheers,
Jes

Re: [Qemu-devel] Re: KVM call agenda for Jan 11

[Jes Sorensen]

On 01/10/11 12:59, Juan Quintela wrote:
> Juan Quintela <quintela@redhat.com> wrote:
> 
> Now sent it to the right kvm list.  Sorry for the second sent.
> 
>> Please send any agenda items you are interested in covering.
>>
>> - KVM Forum 2011 (Jes).

Just to add a bit more background. Last year we discussed the issue of
whether to aim for a KVM Forum in the same style as we had in 2010, or
whether to try to aim for a broader multi-track Virtualization
conference that covers the whole stack.

Linux Foundation is happy to help host such an event, but they are
asking for what our plans are. I posted a mock-proposal for tracks here:
http://www.linux-kvm.org/page/KVM_Forum_2011

Cheers,
Jes

Re: [Qemu-devel] Re: KVM call agenda for Jan 11

[Stefan Hajnoczi]

On Mon, Jan 10, 2011 at 1:05 PM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> On 01/10/11 12:59, Juan Quintela wrote:
>> Juan Quintela <quintela@redhat.com> wrote:
>>
>> Now sent it to the right kvm list.  Sorry for the second sent.
>>
>>> Please send any agenda items you are interested in covering.
>>>
>>> - KVM Forum 2011 (Jes).
>
> Just to add a bit more background. Last year we discussed the issue of
> whether to aim for a KVM Forum in the same style as we had in 2010, or
> whether to try to aim for a broader multi-track Virtualization
> conference that covers the whole stack.
>
> Linux Foundation is happy to help host such an event, but they are
> asking for what our plans are. I posted a mock-proposal for tracks here:
> http://www.linux-kvm.org/page/KVM_Forum_2011

I thought having both KVM and Xen people at Linux Plumbers 2010 worked
out well.  Doing that with libvirt, OpenStack, etc has a lot of
potential.

Stefan

Re: [Qemu-devel] Re: KVM call agenda for Jan 11

[Stefan Hajnoczi]

On Mon, Jan 10, 2011 at 1:05 PM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> On 01/10/11 12:59, Juan Quintela wrote:
>> Juan Quintela <quintela@redhat.com> wrote:
>>
>> Now sent it to the right kvm list.  Sorry for the second sent.
>>
>>> Please send any agenda items you are interested in covering.
>>>
>>> - KVM Forum 2011 (Jes).
>
> Just to add a bit more background. Last year we discussed the issue of
> whether to aim for a KVM Forum in the same style as we had in 2010, or
> whether to try to aim for a broader multi-track Virtualization
> conference that covers the whole stack.
>
> Linux Foundation is happy to help host such an event, but they are
> asking for what our plans are. I posted a mock-proposal for tracks here:
> http://www.linux-kvm.org/page/KVM_Forum_2011

I thought having both KVM and Xen people at Linux Plumbers 2010 worked
out well.  Doing that with libvirt, OpenStack, etc has a lot of
potential.

Stefan

Re: [Qemu-devel] Re: KVM call agenda for Jan 11

[Peter Maydell]

On 10 January 2011 07:45, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Mon, Jan 10, 2011 at 1:05 PM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>> Just to add a bit more background. Last year we discussed the issue of
>> whether to aim for a KVM Forum in the same style as we had in 2010, or
>> whether to try to aim for a broader multi-track Virtualization
>> conference that covers the whole stack.
>>
>> Linux Foundation is happy to help host such an event, but they are
>> asking for what our plans are. I posted a mock-proposal for tracks here:
>> http://www.linux-kvm.org/page/KVM_Forum_2011
>
> I thought having both KVM and Xen people at Linux Plumbers 2010 worked
> out well.  Doing that with libvirt, OpenStack, etc has a lot of
> potential.

I'd certainly like an opportunity to meet other people interested in
the TCG side of qemu, so personally I'd prefer the more broadly
focused approach.

-- PMM

Re: [Qemu-devel] Re: KVM call agenda for Jan 11

[Peter Maydell]

On 10 January 2011 07:45, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Mon, Jan 10, 2011 at 1:05 PM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>> Just to add a bit more background. Last year we discussed the issue of
>> whether to aim for a KVM Forum in the same style as we had in 2010, or
>> whether to try to aim for a broader multi-track Virtualization
>> conference that covers the whole stack.
>>
>> Linux Foundation is happy to help host such an event, but they are
>> asking for what our plans are. I posted a mock-proposal for tracks here:
>> http://www.linux-kvm.org/page/KVM_Forum_2011
>
> I thought having both KVM and Xen people at Linux Plumbers 2010 worked
> out well.  Doing that with libvirt, OpenStack, etc has a lot of
> potential.

I'd certainly like an opportunity to meet other people interested in
the TCG side of qemu, so personally I'd prefer the more broadly
focused approach.

-- PMM

Re: KVM call agenda for Jan 11

[Juan Quintela]

Juan Quintela <quintela@redhat.com> wrote:
> Juan Quintela <quintela@redhat.com> wrote:
>
> Now sent it to the right kvm list.  Sorry for the second sent.
>
>> Please send any agenda items you are interested in covering.
>>
>> - KVM Forum 2011 (Jes).
>>
>> thanks, Juan.

- migration and block devices: a mess.
  * patches I sent last week: only work for root (for some definition of
    work)
  * qemu is used as non-root user.
  * forcing to have cache=none solves the issue
  * we use migrate not only for live migration, but also for
    save/resume.

At this point only 4 ideas remaining:

* -incoming-this-is-a-live-migration
  (or the opposite -incoming-this-is-a-restore-operation)
* just forche cache=none if you want to call migration code.
* let management app to do the right thing (it can check for cache=none)
* do nothing and pray?

Later, Juan.

[Qemu-devel] Re: KVM call agenda for Jan 11

[Juan Quintela]

Juan Quintela <quintela@redhat.com> wrote:
> Juan Quintela <quintela@redhat.com> wrote:
>
> Now sent it to the right kvm list.  Sorry for the second sent.
>
>> Please send any agenda items you are interested in covering.
>>
>> - KVM Forum 2011 (Jes).
>>
>> thanks, Juan.

- migration and block devices: a mess.
  * patches I sent last week: only work for root (for some definition of
    work)
  * qemu is used as non-root user.
  * forcing to have cache=none solves the issue
  * we use migrate not only for live migration, but also for
    save/resume.

At this point only 4 ideas remaining:

* -incoming-this-is-a-live-migration
  (or the opposite -incoming-this-is-a-restore-operation)
* just forche cache=none if you want to call migration code.
* let management app to do the right thing (it can check for cache=none)
* do nothing and pray?

Later, Juan.

Re: [Qemu-devel] Re: KVM call agenda for Jan 11

[Kevin Wolf]

Am 10.01.2011 14:32, schrieb Juan Quintela:
> Juan Quintela <quintela@redhat.com> wrote:
>> Juan Quintela <quintela@redhat.com> wrote:
>>
>> Now sent it to the right kvm list.  Sorry for the second sent.
>>
>>> Please send any agenda items you are interested in covering.
>>>
>>> - KVM Forum 2011 (Jes).
>>>
>>> thanks, Juan.
> 
> - migration and block devices: a mess.
>   * patches I sent last week: only work for root (for some definition of
>     work)
>   * qemu is used as non-root user.
>   * forcing to have cache=none solves the issue

I need to have a look at the specific problem, but it's hard to imagine
that cache=none fixes anything reliably.

Kevin

Re: [Qemu-devel] Re: KVM call agenda for Jan 11

[Kevin Wolf]

Am 10.01.2011 14:32, schrieb Juan Quintela:
> Juan Quintela <quintela@redhat.com> wrote:
>> Juan Quintela <quintela@redhat.com> wrote:
>>
>> Now sent it to the right kvm list.  Sorry for the second sent.
>>
>>> Please send any agenda items you are interested in covering.
>>>
>>> - KVM Forum 2011 (Jes).
>>>
>>> thanks, Juan.
> 
> - migration and block devices: a mess.
>   * patches I sent last week: only work for root (for some definition of
>     work)
>   * qemu is used as non-root user.
>   * forcing to have cache=none solves the issue

I need to have a look at the specific problem, but it's hard to imagine
that cache=none fixes anything reliably.

Kevin

Re: KVM call agenda for Jan 11

[Juan Quintela]

Kevin Wolf <kwolf@redhat.com> wrote:
> Am 10.01.2011 14:32, schrieb Juan Quintela:
>> Juan Quintela <quintela@redhat.com> wrote:
>>> Juan Quintela <quintela@redhat.com> wrote:
>>>
>>> Now sent it to the right kvm list.  Sorry for the second sent.
>>>
>>>> Please send any agenda items you are interested in covering.
>>>>
>>>> - KVM Forum 2011 (Jes).
>>>>
>>>> thanks, Juan.
>> 
>> - migration and block devices: a mess.
>>   * patches I sent last week: only work for root (for some definition of
>>     work)
>>   * qemu is used as non-root user.
>>   * forcing to have cache=none solves the issue
>
> I need to have a look at the specific problem, but it's hard to imagine
> that cache=none fixes anything reliably.

It uses O_DIRECT, that means that we don't have buffering problems.
I state the problem again:

machine A read 1st block of device.
<and stays without doing anything else>
machine B reads writes lots of places including 1st block

now guest from machine A migrates to machine B
machine A re-reads the 1st block, and lo and behold, it reads the old
contents, not the new ones.

Solutions:
- invalidate all buffers for that block device on machine A after
  migration.
   * with NFS, just close + reopen the file (and pray that nobody else
   has it also opened)
   * with block devices: use BLKFLBLK ioctl, and pray that nobody else is
     using the device, that device is not a ramdisk, and some more
     things.  To add injury to insult, you need to be root to be able
     to issue that ioctl (technically have CAP_SYS_ADMIN).

O_DIRECT fixes this problem altogether, because there is no buffering,
and if there are not buffers, they can't be invalid O:-)

Notice the "pray" part in the other solutions, we are basically trying
to do a "poor man" DLM, and that is not trivial to do. (althougth our
problem is not the general one, the principles are the same).

Later, Juan.

[Qemu-devel] Re: KVM call agenda for Jan 11

[Juan Quintela]

Kevin Wolf <kwolf@redhat.com> wrote:
> Am 10.01.2011 14:32, schrieb Juan Quintela:
>> Juan Quintela <quintela@redhat.com> wrote:
>>> Juan Quintela <quintela@redhat.com> wrote:
>>>
>>> Now sent it to the right kvm list.  Sorry for the second sent.
>>>
>>>> Please send any agenda items you are interested in covering.
>>>>
>>>> - KVM Forum 2011 (Jes).
>>>>
>>>> thanks, Juan.
>> 
>> - migration and block devices: a mess.
>>   * patches I sent last week: only work for root (for some definition of
>>     work)
>>   * qemu is used as non-root user.
>>   * forcing to have cache=none solves the issue
>
> I need to have a look at the specific problem, but it's hard to imagine
> that cache=none fixes anything reliably.

It uses O_DIRECT, that means that we don't have buffering problems.
I state the problem again:

machine A read 1st block of device.
<and stays without doing anything else>
machine B reads writes lots of places including 1st block

now guest from machine A migrates to machine B
machine A re-reads the 1st block, and lo and behold, it reads the old
contents, not the new ones.

Solutions:
- invalidate all buffers for that block device on machine A after
  migration.
   * with NFS, just close + reopen the file (and pray that nobody else
   has it also opened)
   * with block devices: use BLKFLBLK ioctl, and pray that nobody else is
     using the device, that device is not a ramdisk, and some more
     things.  To add injury to insult, you need to be root to be able
     to issue that ioctl (technically have CAP_SYS_ADMIN).

O_DIRECT fixes this problem altogether, because there is no buffering,
and if there are not buffers, they can't be invalid O:-)

Notice the "pray" part in the other solutions, we are basically trying
to do a "poor man" DLM, and that is not trivial to do. (althougth our
problem is not the general one, the principles are the same).

Later, Juan.

Re: [Qemu-devel] Re: KVM call agenda for Jan 11

[Anthony Liguori]

On 01/11/2011 07:41 AM, Juan Quintela wrote:
> Kevin Wolf<kwolf@redhat.com>  wrote:
>    
>> Am 10.01.2011 14:32, schrieb Juan Quintela:
>>      
>>> Juan Quintela<quintela@redhat.com>  wrote:
>>>        
>>>> Juan Quintela<quintela@redhat.com>  wrote:
>>>>
>>>> Now sent it to the right kvm list.  Sorry for the second sent.
>>>>
>>>>          
>>>>> Please send any agenda items you are interested in covering.
>>>>>
>>>>> - KVM Forum 2011 (Jes).
>>>>>
>>>>> thanks, Juan.
>>>>>            
>>> - migration and block devices: a mess.
>>>    * patches I sent last week: only work for root (for some definition of
>>>      work)
>>>    * qemu is used as non-root user.
>>>    * forcing to have cache=none solves the issue
>>>        
>> I need to have a look at the specific problem, but it's hard to imagine
>> that cache=none fixes anything reliably.
>>      
> It uses O_DIRECT, that means that we don't have buffering problems.
> I state the problem again:
>
> machine A read 1st block of device.
> <and stays without doing anything else>
> machine B reads writes lots of places including 1st block
>
> now guest from machine A migrates to machine B
> machine A re-reads the 1st block, and lo and behold, it reads the old
> contents, not the new ones.
>
> Solutions:
> - invalidate all buffers for that block device on machine A after
>    migration.
>     * with NFS, just close + reopen the file (and pray that nobody else
>     has it also opened)
>     * with block devices: use BLKFLBLK ioctl, and pray that nobody else is
>       using the device, that device is not a ramdisk, and some more
>       things.  To add injury to insult, you need to be root to be able
>       to issue that ioctl (technically have CAP_SYS_ADMIN).
>    

Why isn't fsync() enough for a block device?

Regards,

Anthony Liguori

> O_DIRECT fixes this problem altogether, because there is no buffering,
> and if there are not buffers, they can't be invalid O:-)
>
> Notice the "pray" part in the other solutions, we are basically trying
> to do a "poor man" DLM, and that is not trivial to do. (althougth our
> problem is not the general one, the principles are the same).
>
> Later, Juan.
>
>
>    

Re: [Qemu-devel] Re: KVM call agenda for Jan 11

[Avi Kivity]

On 01/11/2011 04:43 PM, Anthony Liguori wrote:
>> - invalidate all buffers for that block device on machine A after
>>    migration.
>>     * with NFS, just close + reopen the file (and pray that nobody else
>>     has it also opened)
>>     * with block devices: use BLKFLBLK ioctl, and pray that nobody 
>> else is
>>       using the device, that device is not a ramdisk, and some more
>>       things.  To add injury to insult, you need to be root to be able
>>       to issue that ioctl (technically have CAP_SYS_ADMIN).
>
>
> Why isn't fsync() enough for a block device?

fsync() is fine on the outgoing side, but not on the incoming side.

(the imcoming side might have valid buffers if it was the outgoing side 
on the previous migration, for example, or because of automatic probing)

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Re: KVM call agenda for Jan 11

[Avi Kivity]

On 01/11/2011 04:43 PM, Anthony Liguori wrote:
>> - invalidate all buffers for that block device on machine A after
>>    migration.
>>     * with NFS, just close + reopen the file (and pray that nobody else
>>     has it also opened)
>>     * with block devices: use BLKFLBLK ioctl, and pray that nobody 
>> else is
>>       using the device, that device is not a ramdisk, and some more
>>       things.  To add injury to insult, you need to be root to be able
>>       to issue that ioctl (technically have CAP_SYS_ADMIN).
>
>
> Why isn't fsync() enough for a block device?

fsync() is fine on the outgoing side, but not on the incoming side.

(the imcoming side might have valid buffers if it was the outgoing side 
on the previous migration, for example, or because of automatic probing)

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] KVM call agenda for Jan 11

[Anthony Liguori]

On 01/10/2011 04:17 AM, Juan Quintela wrote:
> Please send any agenda items you are interested in covering.
>
> - KVM Forum 2011 (Jes).
>    

- Spice guest agent (Alon)

Regards,

Anthony Liguori

> thanks, Juan.
>
>