Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-11 Thread William Dauchy
On Dec10 18:21, Dr. David Alan Gilbert wrote:
 Can you try stripping your config down to the bare minimum and see if
 it goes away?   e.g. balloon, rng-pci, network I guess you can probably
 test without easily enough.  If you can also try with a normal boot off
 disk rather than kernel that would be good.

harder to reproduce now (I have less and less VM running on 2.1 and cant
reproduce on my dev platform wiath fresh VM on 2.1-2.2 scenario)
anyway I was wondering if the option `-cpu host` could be the cause of
the issues since the HW is not always the same accross the
infrastructure.

Thanks,
-- 
William


signature.asc
Description: Digital signature


Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-11 Thread Paolo Bonzini


On 11/12/2014 14:44, William Dauchy wrote:
 harder to reproduce now (I have less and less VM running on 2.1 and
 cant reproduce on my dev platform wiath fresh VM on 2.1-2.2
 scenario) anyway I was wondering if the option `-cpu host` could be
 the cause of the issues since the HW is not always the same accross
 the infrastructure.

Yes, that's possible.

Paolo




Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-11 Thread Dr. David Alan Gilbert
* William Dauchy (will...@gandi.net) wrote:
 On Dec10 18:21, Dr. David Alan Gilbert wrote:
  Can you try stripping your config down to the bare minimum and see if
  it goes away?   e.g. balloon, rng-pci, network I guess you can probably
  test without easily enough.  If you can also try with a normal boot off
  disk rather than kernel that would be good.
 
 harder to reproduce now (I have less and less VM running on 2.1 and cant
 reproduce on my dev platform wiath fresh VM on 2.1-2.2 scenario)
 anyway I was wondering if the option `-cpu host` could be the cause of
 the issues since the HW is not always the same accross the
 infrastructure.

Oh yes, -cpu host on two different hosts would definitely do that.
Hmm, it might even do it on the same hardware between different qemus;
certainly it's a bad idea to use -cpu host  if you want to bounce
around a mixed bag of systems.

Dave

--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-11 Thread William Dauchy
On Dec11 14:05, Dr. David Alan Gilbert wrote:
 Hmm, it might even do it on the same hardware between different qemus;

I dont get your last statement;
my common use case is to live migrate an old userland to a new one
(so 2.1 to 2.2 here); so if I guarantee same HW, it should work, right?
-- 
William


signature.asc
Description: Digital signature


Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-11 Thread Dr. David Alan Gilbert
* William Dauchy (will...@gandi.net) wrote:
 On Dec11 14:05, Dr. David Alan Gilbert wrote:
  Hmm, it might even do it on the same hardware between different qemus;
 
 I dont get your last statement;
 my common use case is to live migrate an old userland to a new one
 (so 2.1 to 2.2 here); so if I guarantee same HW, it should work, right?

I wouldn't trust -host cpu  to be the same on the same HW between
different QEMUs, especially on newer hardware than your older QEMU new
about.

Dave


--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-11 Thread William Dauchy
On Dec11 14:34, Dr. David Alan Gilbert wrote:
  I dont get your last statement;
  my common use case is to live migrate an old userland to a new one
  (so 2.1 to 2.2 here); so if I guarantee same HW, it should work, right?
 
 I wouldn't trust -host cpu  to be the same on the same HW between
 different QEMUs, especially on newer hardware than your older QEMU new
 about.

understood.
What are your recommendations then? Using kvm64 proc?

Thanks for your feedback,
-- 
William


signature.asc
Description: Digital signature


Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-11 Thread Dr. David Alan Gilbert
* William Dauchy (will...@gandi.net) wrote:
 On Dec11 14:34, Dr. David Alan Gilbert wrote:
   I dont get your last statement;
   my common use case is to live migrate an old userland to a new one
   (so 2.1 to 2.2 here); so if I guarantee same HW, it should work, right?
  
  I wouldn't trust -host cpu  to be the same on the same HW between
  different QEMUs, especially on newer hardware than your older QEMU new
  about.
 
 understood.
 What are your recommendations then? Using kvm64 proc?

I'd recommend doing -cpu help on your oldest qemu  and pick the CPU that's
as new as possible but not newer than your oldest hardware.

Dave

 
 Thanks for your feedback,
 -- 
 William


--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-10 Thread Dr. David Alan Gilbert
* William Dauchy (will...@gandi.net) wrote:
 Hi David,
 
 Thank you for the quick answer.
 
 On Dec09 18:55, Dr. David Alan Gilbert wrote:
  You don't tell us what that command line is!
  If you're using -M pc or -M q35  that's expected; if you're not
  it's probably a bug - please show us the command line.
 
 sorry it's indeed with `-M pc`. So I misunderstood the usage of
 supported machines option since I was looking for a way to upgrade the
 version and avoiding being stuck on a specific release.
 I now understand I am supposed to keep the same version between live
 migration and wait for a complete stop/start to upgrade. Or if there is
 a trick, please advice.

Yes, you've got to keep the same machine type to do a live migration;
think of it like keeping the same motherboard/cpu combination in a real
machine - we can't squash the state from one shape machine into
a different shape machine without the guest getting very confused.

Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-10 Thread William Dauchy
On Dec10 08:58, Dr. David Alan Gilbert wrote:
 Yes, you've got to keep the same machine type to do a live migration;
 think of it like keeping the same motherboard/cpu combination in a real
 machine - we can't squash the state from one shape machine into
 a different shape machine without the guest getting very confused.

I now have done some other tests:

with source -M pc-i440fx-2.1
and target -M pc-i440fx-2.1

still getting:

Unknown combination of migration flags: 0
warning: error while loading state section id 2

-- 
William


signature.asc
Description: Digital signature


Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-10 Thread Dr. David Alan Gilbert
* William Dauchy (will...@gandi.net) wrote:
 On Dec10 08:58, Dr. David Alan Gilbert wrote:
  Yes, you've got to keep the same machine type to do a live migration;
  think of it like keeping the same motherboard/cpu combination in a real
  machine - we can't squash the state from one shape machine into
  a different shape machine without the guest getting very confused.
 
 I now have done some other tests:
 
 with source -M pc-i440fx-2.1
 and target -M pc-i440fx-2.1
 
 still getting:
 
 Unknown combination of migration flags: 0
 warning: error while loading state section id 2

As previously requested, please show your full command line.

Dave

--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-10 Thread William Dauchy
On Dec10 17:10, Dr. David Alan Gilbert wrote:
 As previously requested, please show your full command line.

qemu-system-x86_64 -m 2048 -cpu host -nodefconfig -nodefaults -nographic 
-readconfig /var/lib/qemu/X/config -pidfile /var/lib/qemu/X/pid -M 
pc-i440fx-2.1 -serial pty -d unimp,guest_errors -daemonize

config file:

[name]
  guest = X
  process = X

[chardev compat_monitor0]
  backend = socket
  path = /var/lib/qemu/X/sock
  server = on
  wait = off

[device]
  driver = virtio-balloon

[rtc]
  base = utc

[mon compat_monitor0]
  mode = control
  chardev = compat_monitor0
  default = on

[device]
  driver = virtio-rng-pci

[device scsi0]
  driver = virtio-scsi-pci
  hotplug = on

[machine]
  kernel = /boot-vm/bzImage-3.12-x86_64
  append = root=/dev/sda console=ttyS0 ro
  accel = kvm

[netdev vif15196.1]
  type = tap
  br = p43
  vhost = on
  vhostforce = on
  ifname = vif15196.1
  downscript = no
  script = no
  queues = 1

[device vif15196.1]
  driver = virtio-net-pci
  netdev = vif15196.1
  mac = 00:16:3e:2e:ea:7c
  mq = on
  vectors = 3

[drive disk0]
  if = none
  id = disk0
  cache = none
  aio = native
  format = raw
  file = /dev/sda

[device disk0]
  driver = scsi-hd
  drive = disk0
  scsi-id = 0
  removable = on
  dpofua = off

[drive swap0]
  if = none
  id = swap0
  cache = none
  aio = native
  format = raw
  file = /dev/sdb

[device swap0]
  driver = scsi-hd
  drive = swap0
  scsi-id = 1
  removable = on
  dpofua = off

[smp-opts]
  cpus = 1
  sockets = 1
  cores = 1
  threads = 1
  maxcpus = 16

-- 
William


signature.asc
Description: Digital signature


Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-10 Thread William Dauchy
+ maybe the last patch from Paulo kvm/apic: fix 2.2-2.1 migration is
related?
-- 
William


signature.asc
Description: Digital signature


Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-10 Thread Dr. David Alan Gilbert
* William Dauchy (will...@gandi.net) wrote:
 On Dec10 17:10, Dr. David Alan Gilbert wrote:
  As previously requested, please show your full command line.
 
 qemu-system-x86_64 -m 2048 -cpu host -nodefconfig -nodefaults -nographic 
 -readconfig /var/lib/qemu/X/config -pidfile /var/lib/qemu/X/pid -M 
 pc-i440fx-2.1 -serial pty -d unimp,guest_errors -daemonize

OK, and just checking, 2.2-2.2 and 2.1-2.1 works for you?
It's just 2.1-2.2 that's breaking?

 config file:
 
 [name]
   guest = X
   process = X
 
 [chardev compat_monitor0]
   backend = socket
   path = /var/lib/qemu/X/sock
   server = on
   wait = off
 
 [device]
   driver = virtio-balloon
 
 [rtc]
   base = utc
 
 [mon compat_monitor0]
   mode = control
   chardev = compat_monitor0
   default = on
 
 [device]
   driver = virtio-rng-pci
 
 [device scsi0]
   driver = virtio-scsi-pci
   hotplug = on
 
 [machine]
   kernel = /boot-vm/bzImage-3.12-x86_64
   append = root=/dev/sda console=ttyS0 ro
   accel = kvm

Hmm, I've never tried using the kernel stuff with migration, but I believe it's
supposed to work; I always just pass a normal device.

 [netdev vif15196.1]
   type = tap
   br = p43
   vhost = on
   vhostforce = on
   ifname = vif15196.1
   downscript = no
   script = no
   queues = 1
 
 [device vif15196.1]
   driver = virtio-net-pci
   netdev = vif15196.1
   mac = 00:16:3e:2e:ea:7c
   mq = on
   vectors = 3
 
 [drive disk0]
   if = none
   id = disk0
   cache = none
   aio = native
   format = raw
   file = /dev/sda
 
 [device disk0]
   driver = scsi-hd
   drive = disk0
   scsi-id = 0
   removable = on
   dpofua = off
 
 [drive swap0]
   if = none
   id = swap0
   cache = none
   aio = native
   format = raw
   file = /dev/sdb
 
 [device swap0]
   driver = scsi-hd
   drive = swap0
   scsi-id = 1
   removable = on
   dpofua = off
 
 [smp-opts]
   cpus = 1
   sockets = 1
   cores = 1
   threads = 1
   maxcpus = 16
 
 -- 
 William


--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-10 Thread Dr. David Alan Gilbert
* William Dauchy (will...@gandi.net) wrote:
 + maybe the last patch from Paulo kvm/apic: fix 2.2-2.1 migration is
 related?

It's worth a go - but I did want to check which direction you were
having the problem with.

Dave
 -- 
 William


--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-10 Thread Paolo Bonzini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 10/12/2014 18:28, William Dauchy wrote:
 + maybe the last patch from Paulo kvm/apic: fix 2.2-2.1 migration is
 related?

No, it's only for 2.2-2.1.

The error it fixes was reported by Igor Mammedov:

source:
 qemu-system-x86_64-2.2 -enable-kvm -smp 2 -m 512  -monitor stdio   -M 
pc-i440fx-2.1
 (qemu) stop
 (qemu) migrate exec:gzip -c  STATEFILE.gz

target:
 qemu-system-x86_64-2.1 -enable-kvm -smp 2 -m 512 -monitor stdio -M 
pc-i440fx-2.1 -incoming exec: gzip -c -d STATEFILE.gz
 qemu: warning: error while loading state for instance 0x1 of device 'apic'
 qemu-system-x86_64-2.1: load of migration failed: No such file or directory

Paolo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUiIZHAAoJEL/70l94x66D6m0H/jRPN6pPNdnGp+lHaOdS0OFj
0YS1Lu6GSeDy1xgEDeGMvAndeN2C6txTGZNuRkgP5urr/LKokBlIFMDarZouQFP/
IDMInfZamR4pKulhQWSnh9ktm1xGvXOMQJ3imqQN7rDV2fEGxsrNAWm1DAf2drGy
ipkF/idgeM7UQwAwuo1fcH8yHLnEsxzRV2BYDWewwAsXYlm3ugMyVR8zskJdcIWm
qHMuDsF+pebRmXr4le2pM79g1yA8g7etnbvdgbLx6fXJafjkN0MAqIzMCmFH1mfk
E9/BoK+FLn930XAAlv5Sqlh7Kl7RmoA/h14tR33nqaERS3NBWf6ebymPBvMdV7Q=
=T52j
-END PGP SIGNATURE-



Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-10 Thread William Dauchy
On Dec10 17:31, Dr. David Alan Gilbert wrote:
 OK, and just checking, 2.2-2.2 and 2.1-2.1 works for you?
 It's just 2.1-2.2 that's breaking?

yes
-- 
William


signature.asc
Description: Digital signature


Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-10 Thread Dr. David Alan Gilbert
* William Dauchy (will...@gandi.net) wrote:
 On Dec10 17:31, Dr. David Alan Gilbert wrote:
  OK, and just checking, 2.2-2.2 and 2.1-2.1 works for you?
  It's just 2.1-2.2 that's breaking?
 
 yes

OK - that shouldn't happen.

Can you try stripping your config down to the bare minimum and see if
it goes away?   e.g. balloon, rng-pci, network I guess you can probably
test without easily enough.  If you can also try with a normal boot off
disk rather than kernel that would be good.

Hopefully one of those will turn out to be the culprit.

Thanks,

Dave

 -- 
 William


--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-09 Thread Dr. David Alan Gilbert
* William Dauchy (will...@gandi.net) wrote:
 Hello,
 
 I have been testing live migration from qemu2.1.2 to qemu2.2.0 under
 kvm - with same config and same command line.
 
 the process crashes with:
 
 Unknown combination of migration flags: 0
 qemu: warning: error while loading state section id 2
 
 Don't know if it's supposed to be supported or not.

You don't tell us what that command line is!
If you're using -M pc or -M q35  that's expected; if you're not
it's probably a bug - please show us the command line.

Dave
 
 Thanks,
 -- 
 William


--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

2014-12-09 Thread William Dauchy
Hi David,

Thank you for the quick answer.

On Dec09 18:55, Dr. David Alan Gilbert wrote:
 You don't tell us what that command line is!
 If you're using -M pc or -M q35  that's expected; if you're not
 it's probably a bug - please show us the command line.

sorry it's indeed with `-M pc`. So I misunderstood the usage of
supported machines option since I was looking for a way to upgrade the
version and avoiding being stuck on a specific release.
I now understand I am supposed to keep the same version between live
migration and wait for a complete stop/start to upgrade. Or if there is
a trick, please advice.

Thanks,
-- 
William


signature.asc
Description: Digital signature