qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] Block Migration and xbzrle
@ 2012-09-16 10:39 Peter Lieven
  2012-09-17 18:03 ` Orit Wasserman
  2012-10-02  9:38 ` Paolo Bonzini
  0 siblings, 2 replies; 10+ messages in thread
From: Peter Lieven @ 2012-09-16 10:39 UTC (permalink / raw)
  To: qemu-devel@nongnu.org, kvm@vger.kernel.org

Hi,

I remember that this was broken some time ago and currently with 
qemu-kvm 1.2.0 I am still not able to use
block migration plus xbzrle. The migration fails if both are used 
together. XBZRLE without block migration works.

Can someone please advise what is the current expected behaviour?

Thanks,
Peter

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] Block Migration and xbzrle
  2012-09-16 10:39 [Qemu-devel] Block Migration and xbzrle Peter Lieven
@ 2012-09-17 18:03 ` Orit Wasserman
  2012-10-02  8:33   ` lieven-lists
  2012-10-02  9:38 ` Paolo Bonzini
  1 sibling, 1 reply; 10+ messages in thread
From: Orit Wasserman @ 2012-09-17 18:03 UTC (permalink / raw)
  To: Peter Lieven; +Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org

On 09/16/2012 01:39 PM, Peter Lieven wrote:
> Hi,
> 
> I remember that this was broken some time ago and currently with qemu-kvm 1.2.0 I am still not able to use
> block migration plus xbzrle. The migration fails if both are used together. XBZRLE without block migration works.
> 
> Can someone please advise what is the current expected behaviour?
XBZRLE only work on guest memory so it shouldn't be effected by block migration.
What is the error you are getting?
What command line ?

Regards,
Orit
> 
> Thanks,
> Peter
> 
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] Block Migration and xbzrle
  2012-09-17 18:03 ` Orit Wasserman
@ 2012-10-02  8:33   ` lieven-lists
  2012-10-02  9:28     ` Orit Wasserman
  0 siblings, 1 reply; 10+ messages in thread
From: lieven-lists @ 2012-10-02  8:33 UTC (permalink / raw)
  To: Orit Wasserman; +Cc: Peter Lieven, qemu-devel@nongnu.org, kvm@vger.kernel.org

Orit Wasserman wrote:
> On 09/16/2012 01:39 PM, Peter Lieven wrote:
>> Hi,
>>
>> I remember that this was broken some time ago and currently with
>> qemu-kvm 1.2.0 I am still not able to use
>> block migration plus xbzrle. The migration fails if both are used
>> together. XBZRLE without block migration works.
>>
>> Can someone please advise what is the current expected behaviour?
> XBZRLE only work on guest memory so it shouldn't be effected by block
> migration.
> What is the error you are getting?
> What command line ?

Meanwhile I can confirm that it happens with and without block migration.
I I observe 2 errors:
a)
 qemu: warning: error while loading state section id 2
 load of migration failed
b)
 the vm does not enter running state after migration.

The command-line:
/usr/bin/qemu-kvm-1.2.0  -net
tap,vlan=798,script=no,downscript=no,ifname=tap1  -net
nic,vlan=798,model=e1000,macaddr=52:54:00:ff:01:15   -drive
format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-d85f4e007-3f30017ce11505df-ubuntu-tools-hd0,if=virtio,cache=none,aio=native
 -m 4096 -smp 2,sockets=1,cores=2,threads=1  -monitor
tcp:0:4002,server,nowait -vnc :2 -qmp tcp:0:3002,server,nowait  -name
'Ubuntu-Tools'  -boot order=dc,menu=off  -k de  -incoming
tcp:172.21.55.34:5002  -pidfile /var/run/qemu/vm-250.pid  -mem-path
/hugepages  -mem-prealloc  -rtc base=utc -usb -usbdevice tablet -no-hpet
-vga cirrus  -cpu host,+x2apic,model_id='Intel(R) Xeon(R) CPU          
L5640  @ 2.27GHz',-tsc

Thanks,
Peter

>
> Regards,
> Orit
>>
>> Thanks,
>> Peter
>>
>>
>
>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] Block Migration and xbzrle
  2012-10-02  8:33   ` lieven-lists
@ 2012-10-02  9:28     ` Orit Wasserman
  2012-10-02  9:30       ` Peter Lieven
  0 siblings, 1 reply; 10+ messages in thread
From: Orit Wasserman @ 2012-10-02  9:28 UTC (permalink / raw)
  To: lieven-lists; +Cc: Peter Lieven, qemu-devel@nongnu.org, kvm@vger.kernel.org

On 10/02/2012 10:33 AM, lieven-lists@dlh.net wrote:
> Orit Wasserman wrote:
>> On 09/16/2012 01:39 PM, Peter Lieven wrote:
>>> Hi,
>>>
>>> I remember that this was broken some time ago and currently with
>>> qemu-kvm 1.2.0 I am still not able to use
>>> block migration plus xbzrle. The migration fails if both are used
>>> together. XBZRLE without block migration works.
>>>
>>> Can someone please advise what is the current expected behaviour?
>> XBZRLE only work on guest memory so it shouldn't be effected by block
>> migration.
>> What is the error you are getting?
>> What command line ?
> 
> Meanwhile I can confirm that it happens with and without block migration.
> I I observe 2 errors:
> a)
>  qemu: warning: error while loading state section id 2
>  load of migration failed
> b)
>  the vm does not enter running state after migration.
> 
> The command-line:
> /usr/bin/qemu-kvm-1.2.0  -net
> tap,vlan=798,script=no,downscript=no,ifname=tap1  -net
> nic,vlan=798,model=e1000,macaddr=52:54:00:ff:01:15   -drive
> format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-d85f4e007-3f30017ce11505df-ubuntu-tools-hd0,if=virtio,cache=none,aio=native
>  -m 4096 -smp 2,sockets=1,cores=2,threads=1  -monitor
> tcp:0:4002,server,nowait -vnc :2 -qmp tcp:0:3002,server,nowait  -name
> 'Ubuntu-Tools'  -boot order=dc,menu=off  -k de  -incoming
> tcp:172.21.55.34:5002  -pidfile /var/run/qemu/vm-250.pid  -mem-path
> /hugepages  -mem-prealloc  -rtc base=utc -usb -usbdevice tablet -no-hpet
> -vga cirrus  -cpu host,+x2apic,model_id='Intel(R) Xeon(R) CPU 
Migration with -cpu host is very problemtic, because the source and destination can 
have different cpu resulting in different cpu features.
Does regular migration works with this setup?
Can you try with a different cpu type?
What are the source and destination /proc/cpuinfo output ?

Cheers,
Orit
         
> L5640  @ 2.27GHz',-tsc
> 
> Thanks,
> Peter
> 
>>
>> Regards,
>> Orit
>>>
>>> Thanks,
>>> Peter
>>>
>>>
>>
>>
>>
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] Block Migration and xbzrle
  2012-10-02  9:28     ` Orit Wasserman
@ 2012-10-02  9:30       ` Peter Lieven
  2012-10-02 10:40         ` Orit Wasserman
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Lieven @ 2012-10-02  9:30 UTC (permalink / raw)
  To: Orit Wasserman; +Cc: qemu-devel@nongnu.org, lieven-lists, kvm@vger.kernel.org


Am 02.10.2012 um 11:28 schrieb Orit Wasserman:

> On 10/02/2012 10:33 AM, lieven-lists@dlh.net wrote:
>> Orit Wasserman wrote:
>>> On 09/16/2012 01:39 PM, Peter Lieven wrote:
>>>> Hi,
>>>> 
>>>> I remember that this was broken some time ago and currently with
>>>> qemu-kvm 1.2.0 I am still not able to use
>>>> block migration plus xbzrle. The migration fails if both are used
>>>> together. XBZRLE without block migration works.
>>>> 
>>>> Can someone please advise what is the current expected behaviour?
>>> XBZRLE only work on guest memory so it shouldn't be effected by block
>>> migration.
>>> What is the error you are getting?
>>> What command line ?
>> 
>> Meanwhile I can confirm that it happens with and without block migration.
>> I I observe 2 errors:
>> a)
>> qemu: warning: error while loading state section id 2
>> load of migration failed
>> b)
>> the vm does not enter running state after migration.
>> 
>> The command-line:
>> /usr/bin/qemu-kvm-1.2.0  -net
>> tap,vlan=798,script=no,downscript=no,ifname=tap1  -net
>> nic,vlan=798,model=e1000,macaddr=52:54:00:ff:01:15   -drive
>> format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-d85f4e007-3f30017ce11505df-ubuntu-tools-hd0,if=virtio,cache=none,aio=native
>> -m 4096 -smp 2,sockets=1,cores=2,threads=1  -monitor
>> tcp:0:4002,server,nowait -vnc :2 -qmp tcp:0:3002,server,nowait  -name
>> 'Ubuntu-Tools'  -boot order=dc,menu=off  -k de  -incoming
>> tcp:172.21.55.34:5002  -pidfile /var/run/qemu/vm-250.pid  -mem-path
>> /hugepages  -mem-prealloc  -rtc base=utc -usb -usbdevice tablet -no-hpet
>> -vga cirrus  -cpu host,+x2apic,model_id='Intel(R) Xeon(R) CPU 
> Migration with -cpu host is very problemtic, because the source and destination can 
> have different cpu resulting in different cpu features.
> Does regular migration works with this setup?
> Can you try with a different cpu type?
> What are the source and destination /proc/cpuinfo output ?

The CPUs are identical, we also check if flags and cpu types match if cpu type is set to host.
Regular migration does work.

BR,
Peter

> 
> Cheers,
> Orit
> 
>> L5640  @ 2.27GHz',-tsc
>> 
>> Thanks,
>> Peter
>> 
>>> 
>>> Regards,
>>> Orit
>>>> 
>>>> Thanks,
>>>> Peter
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] Block Migration and xbzrle
  2012-09-16 10:39 [Qemu-devel] Block Migration and xbzrle Peter Lieven
  2012-09-17 18:03 ` Orit Wasserman
@ 2012-10-02  9:38 ` Paolo Bonzini
  2012-10-02  9:44   ` Peter Lieven
  1 sibling, 1 reply; 10+ messages in thread
From: Paolo Bonzini @ 2012-10-02  9:38 UTC (permalink / raw)
  To: Peter Lieven; +Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org

Il 16/09/2012 12:39, Peter Lieven ha scritto:
> 
> I remember that this was broken some time ago and currently with
> qemu-kvm 1.2.0 I am still not able to use
> block migration plus xbzrle. The migration fails if both are used
> together. XBZRLE without block migration works.
> 
> Can someone please advise what is the current expected behaviour?

Block migration is broken by design.  It will converge really slowly as
soon as you have real load in the VMs, and it will hamper the
convergence of RAM as well.

Hopefully a real alternative will be in 1.3 (based on drive-mirror on
the source + an embedded NBD server running on the destination), then in
1.4 we can reimplement the block migration monitor commands using the
alternative.

Paolo

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] Block Migration and xbzrle
  2012-10-02  9:38 ` Paolo Bonzini
@ 2012-10-02  9:44   ` Peter Lieven
  2012-10-02 10:09     ` Paolo Bonzini
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Lieven @ 2012-10-02  9:44 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org


Am 02.10.2012 um 11:38 schrieb Paolo Bonzini:

> Il 16/09/2012 12:39, Peter Lieven ha scritto:
>> 
>> I remember that this was broken some time ago and currently with
>> qemu-kvm 1.2.0 I am still not able to use
>> block migration plus xbzrle. The migration fails if both are used
>> together. XBZRLE without block migration works.
>> 
>> Can someone please advise what is the current expected behaviour?
> 
> Block migration is broken by design.  It will converge really slowly as
> soon as you have real load in the VMs, and it will hamper the
> convergence of RAM as well.
> 
> Hopefully a real alternative will be in 1.3 (based on drive-mirror on
> the source + an embedded NBD server running on the destination), then in
> 1.4 we can reimplement the block migration monitor commands using the
> alternative.

Hi Paolo, i know that block migration is not that good, but it seems that
there is a bug in XBZRLE that is independent of block migration.

Peter

> 
> Paolo

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] Block Migration and xbzrle
  2012-10-02  9:44   ` Peter Lieven
@ 2012-10-02 10:09     ` Paolo Bonzini
  0 siblings, 0 replies; 10+ messages in thread
From: Paolo Bonzini @ 2012-10-02 10:09 UTC (permalink / raw)
  To: Peter Lieven; +Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org

Il 02/10/2012 11:44, Peter Lieven ha scritto:
> 
> Am 02.10.2012 um 11:38 schrieb Paolo Bonzini:
> 
>> Il 16/09/2012 12:39, Peter Lieven ha scritto:
>>>
>>> I remember that this was broken some time ago and currently with
>>> qemu-kvm 1.2.0 I am still not able to use
>>> block migration plus xbzrle. The migration fails if both are used
>>> together. XBZRLE without block migration works.
>>>
>>> Can someone please advise what is the current expected behaviour?
>>
>> Block migration is broken by design.  It will converge really slowly as
>> soon as you have real load in the VMs, and it will hamper the
>> convergence of RAM as well.
>>
>> Hopefully a real alternative will be in 1.3 (based on drive-mirror on
>> the source + an embedded NBD server running on the destination), then in
>> 1.4 we can reimplement the block migration monitor commands using the
>> alternative.
> 
> Hi Paolo, i know that block migration is not that good, but it seems that
> there is a bug in XBZRLE that is independent of block migration.

Understood---but hopefully you can stop using it with 1.3, which would
also work around the bug. :)

Paolo

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] Block Migration and xbzrle
  2012-10-02  9:30       ` Peter Lieven
@ 2012-10-02 10:40         ` Orit Wasserman
  2012-10-04  6:31           ` Peter Lieven
  0 siblings, 1 reply; 10+ messages in thread
From: Orit Wasserman @ 2012-10-02 10:40 UTC (permalink / raw)
  To: Peter Lieven; +Cc: qemu-devel@nongnu.org, lieven-lists, kvm@vger.kernel.org

On 10/02/2012 11:30 AM, Peter Lieven wrote:
> 
> Am 02.10.2012 um 11:28 schrieb Orit Wasserman:
> 
>> On 10/02/2012 10:33 AM, lieven-lists@dlh.net wrote:
>>> Orit Wasserman wrote:
>>>> On 09/16/2012 01:39 PM, Peter Lieven wrote:
>>>>> Hi,
>>>>>
>>>>> I remember that this was broken some time ago and currently with
>>>>> qemu-kvm 1.2.0 I am still not able to use
>>>>> block migration plus xbzrle. The migration fails if both are used
>>>>> together. XBZRLE without block migration works.
>>>>>
>>>>> Can someone please advise what is the current expected behaviour?
>>>> XBZRLE only work on guest memory so it shouldn't be effected by block
>>>> migration.
>>>> What is the error you are getting?
>>>> What command line ?
>>>
>>> Meanwhile I can confirm that it happens with and without block migration.
>>> I I observe 2 errors:
>>> a)
>>> qemu: warning: error while loading state section id 2
>>> load of migration failed
Did you enabled XBZRLE on the destination also?
(migrate_set_capability xbzrle on)

Orit
>>> b)
>>> the vm does not enter running state after migration.
>>>
>>> The command-line:
>>> /usr/bin/qemu-kvm-1.2.0  -net
>>> tap,vlan=798,script=no,downscript=no,ifname=tap1  -net
>>> nic,vlan=798,model=e1000,macaddr=52:54:00:ff:01:15   -drive
>>> format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-d85f4e007-3f30017ce11505df-ubuntu-tools-hd0,if=virtio,cache=none,aio=native
>>> -m 4096 -smp 2,sockets=1,cores=2,threads=1  -monitor
>>> tcp:0:4002,server,nowait -vnc :2 -qmp tcp:0:3002,server,nowait  -name
>>> 'Ubuntu-Tools'  -boot order=dc,menu=off  -k de  -incoming
>>> tcp:172.21.55.34:5002  -pidfile /var/run/qemu/vm-250.pid  -mem-path
>>> /hugepages  -mem-prealloc  -rtc base=utc -usb -usbdevice tablet -no-hpet
>>> -vga cirrus  -cpu host,+x2apic,model_id='Intel(R) Xeon(R) CPU 
>> Migration with -cpu host is very problemtic, because the source and destination can 
>> have different cpu resulting in different cpu features.
>> Does regular migration works with this setup?
>> Can you try with a different cpu type?
>> What are the source and destination /proc/cpuinfo output ?

> 
> The CPUs are identical, we also check if flags and cpu types match if cpu type is set to host.
> Regular migration does work.



> 
> BR,
> Peter
> 
>>
>> Cheers,
>> Orit
>>
>>> L5640  @ 2.27GHz',-tsc
>>>
>>> Thanks,
>>> Peter
>>>
>>>>
>>>> Regards,
>>>> Orit
>>>>>
>>>>> Thanks,
>>>>> Peter
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] Block Migration and xbzrle
  2012-10-02 10:40         ` Orit Wasserman
@ 2012-10-04  6:31           ` Peter Lieven
  0 siblings, 0 replies; 10+ messages in thread
From: Peter Lieven @ 2012-10-04  6:31 UTC (permalink / raw)
  To: Orit Wasserman; +Cc: qemu-devel@nongnu.org, lieven-lists, kvm@vger.kernel.org


Am 02.10.2012 um 12:40 schrieb Orit Wasserman:

> On 10/02/2012 11:30 AM, Peter Lieven wrote:
>> 
>> Am 02.10.2012 um 11:28 schrieb Orit Wasserman:
>> 
>>> On 10/02/2012 10:33 AM, lieven-lists@dlh.net wrote:
>>>> Orit Wasserman wrote:
>>>>> On 09/16/2012 01:39 PM, Peter Lieven wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> I remember that this was broken some time ago and currently with
>>>>>> qemu-kvm 1.2.0 I am still not able to use
>>>>>> block migration plus xbzrle. The migration fails if both are used
>>>>>> together. XBZRLE without block migration works.
>>>>>> 
>>>>>> Can someone please advise what is the current expected behaviour?
>>>>> XBZRLE only work on guest memory so it shouldn't be effected by block
>>>>> migration.
>>>>> What is the error you are getting?
>>>>> What command line ?
>>>> 
>>>> Meanwhile I can confirm that it happens with and without block migration.
>>>> I I observe 2 errors:
>>>> a)
>>>> qemu: warning: error while loading state section id 2
>>>> load of migration failed
> Did you enabled XBZRLE on the destination also?
> (migrate_set_capability xbzrle on)

I was not aware that I have to enable it on both sides. I thought it had to be enabled only on the source side.
However, it seems that it is enabled by default in 1.2.0?!
I will retry with enabling it with the above command
 on both sides.

Peter

> 
> Orit
>>>> b)
>>>> the vm does not enter running state after migration.
>>>> 
>>>> The command-line:
>>>> /usr/bin/qemu-kvm-1.2.0  -net
>>>> tap,vlan=798,script=no,downscript=no,ifname=tap1  -net
>>>> nic,vlan=798,model=e1000,macaddr=52:54:00:ff:01:15   -drive
>>>> format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-d85f4e007-3f30017ce11505df-ubuntu-tools-hd0,if=virtio,cache=none,aio=native
>>>> -m 4096 -smp 2,sockets=1,cores=2,threads=1  -monitor
>>>> tcp:0:4002,server,nowait -vnc :2 -qmp tcp:0:3002,server,nowait  -name
>>>> 'Ubuntu-Tools'  -boot order=dc,menu=off  -k de  -incoming
>>>> tcp:172.21.55.34:5002  -pidfile /var/run/qemu/vm-250.pid  -mem-path
>>>> /hugepages  -mem-prealloc  -rtc base=utc -usb -usbdevice tablet -no-hpet
>>>> -vga cirrus  -cpu host,+x2apic,model_id='Intel(R) Xeon(R) CPU 
>>> Migration with -cpu host is very problemtic, because the source and destination can 
>>> have different cpu resulting in different cpu features.
>>> Does regular migration works with this setup?
>>> Can you try with a different cpu type?
>>> What are the source and destination /proc/cpuinfo output ?
> 
>> 
>> The CPUs are identical, we also check if flags and cpu types match if cpu type is set to host.
>> Regular migration does work.
> 
> 
> 
>> 
>> BR,
>> Peter
>> 
>>> 
>>> Cheers,
>>> Orit
>>> 
>>>> L5640  @ 2.27GHz',-tsc
>>>> 
>>>> Thanks,
>>>> Peter
>>>> 
>>>>> 
>>>>> Regards,
>>>>> Orit
>>>>>> 
>>>>>> Thanks,
>>>>>> Peter
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> 
>>> 
>> 
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2012-10-04  6:31 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-16 10:39 [Qemu-devel] Block Migration and xbzrle Peter Lieven
2012-09-17 18:03 ` Orit Wasserman
2012-10-02  8:33   ` lieven-lists
2012-10-02  9:28     ` Orit Wasserman
2012-10-02  9:30       ` Peter Lieven
2012-10-02 10:40         ` Orit Wasserman
2012-10-04  6:31           ` Peter Lieven
2012-10-02  9:38 ` Paolo Bonzini
2012-10-02  9:44   ` Peter Lieven
2012-10-02 10:09     ` Paolo Bonzini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).