Re: [Qemu-block] [Qemu-devel] Migration sometimes fails with IDE and Qemu 2.2.1
Am 11.04.2015 um 17:00 schrieb Peter Lieven: Am 11.04.2015 um 15:11 schrieb Peter Lieven: Am 09.04.2015 um 17:17 schrieb Paolo Bonzini: On 09/04/2015 16:54, Peter Lieven wrote: #define BM_MIGRATION_COMPAT_STATUS_BITS \ (IDE_RETRY_DMA | IDE_RETRY_PIO | \ IDE_RETRY_READ | IDE_RETRY_FLUSH) Why is there no IDE_RETRY_WRITE ? Because that's represented by none of read and flush being set. :) Honestly, I have not yet understood that that BM_MIGRATION_COMPAT_STATUS_BITS is for. It's just for migrations while the VM is stopped due to I/O errors (rerror=stop/werror=stop). My migration problem seems to be a regression or incompatiblity in kvm-kmod. I started debugging with an old kvm module accidently. It seems to work with the old module shipped with the kernel (3.13) and fails with (3.19). 3.17 (kvm-kmod master) also seems to work. I had to move to 3.19 some time ago to mititage another bug that triggered a new check in Qemu. kvm-kmod next currently does not compile under my 3.13 host kernel. And according to the buildbot output for kvm-kmod it seems to fail for almost all kernels = 3.18. I meanwhile managed to compile the kvm-kmod next. The bug is still in there. I will now try kvm-kmod master with KVM: x86: update masterclock values on TSC writes on top. Help appreciated. Thanks, Peter
Re: [Qemu-block] [Qemu-devel] Migration sometimes fails with IDE and Qemu 2.2.1
On 09/04/2015 16:54, Peter Lieven wrote: #define BM_MIGRATION_COMPAT_STATUS_BITS \ (IDE_RETRY_DMA | IDE_RETRY_PIO | \ IDE_RETRY_READ | IDE_RETRY_FLUSH) Why is there no IDE_RETRY_WRITE ? Because that's represented by none of read and flush being set. :) Honestly, I have not yet understood that that BM_MIGRATION_COMPAT_STATUS_BITS is for. It's just for migrations while the VM is stopped due to I/O errors (rerror=stop/werror=stop). Paolo
Re: [Qemu-block] [Qemu-devel] Migration sometimes fails with IDE and Qemu 2.2.1
Am 07.04.2015 um 21:13 schrieb John Snow: On 04/07/2015 03:02 PM, Peter Lieven wrote: Am 07.04.2015 um 20:56 schrieb John Snow: On 04/07/2015 02:44 PM, Peter Lieven wrote: Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert: * Peter Lieven (p...@kamp.de) wrote: Hi David, Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert: Any particular workload or reproducer? Workload is almost zero. I try to figure out if there is a way to trigger it. Maybe playing a role: Machine type is -M pc1.2 and we set -kvmclock as CPU flag since kvmclock seemed to be quite buggy in 2.6.16... Exact cmdline is: /usr/bin/qemu-2.2.1 -enable-kvm -M pc-1.2 -nodefaults -netdev type=tap,id=guest2,script=no,downscript=no,ifname=tap2 -device e1000,netdev=guest2,mac=52:54:00:ff:00:65 -drive format=raw,file=iscsi://172.21.200.53/iqn.2001-05.com.equallogic:4-52aed6-88a7e99a4-d9e00040fdc509a3-XXX-hd0/0,if=ide,cache=writeback,aio=native -serial null -parallel null -m 1024 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4003,server,nowait -vnc :3 -qmp tcp:0:3003,server,nowait -name 'XXX' -boot order=c,once=dc,menu=off -drive index=2,media=cdrom,if=ide,cache=unsafe,aio=native,readonly=on -k de -incoming tcp:0:5003 -pidfile /var/run/qemu/vm-146.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu qemu64,-kvmclock Exact kernel is: 2.6.16.46-0.12-smp (i think this is SLES10 or sth.) The machine does not hang. It seems just I/O is hanging. So you can type at the console or ping the system, but no longer login. Thank you, Peter Interesting observation: Migrating the vServer again seems to fix to problem (at least in one case I could test just now). 2.6.8-24-smp is also affected. How often does it fail - you say 'sometimes' - is it a 1/10 or a 1/1000 ? Its more often than 1/10 I would say. OK, that's not too bad - it's the 1/1000 that are really nasty to find. In your setup, how easy would it be for you to try : with either 2.1 or current head? with a newer machine-type? without the cdrom? Its all possible. I can clone the system and try everything on my test systems. I hope it reproduces there. Has the cdrom the power of taking down the bus? Peter I don't know if CDROM could stall the entire bus, but I suspect the reason for asking is this: dgilbert and I had tracked down a problem previously where during migration, outstanding requests being handled by the ATAPI code can get lost during migration if, for instance, the user has only prepared the command (via bmdma) but has not yet written to the register to activate the command yet. That sounds like it could be related. So if something like this happens: - User writes to the ATA registers to program a command - Migration occurs - User writes to the BMDMA register to initiate the command We can lose some of the state and data of the request. David had checked in a workaround for at least ATAPI that simply coaxes the guest OS into trying the command again to unstick it. Do you have the commit for me? http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg01109.html I think we determined last time that we couldn't fix this problem without changing the migration format, so we opted not to do it for 2.3. We had also only noticed it with ATAPI drives, not HDDs, so a proper fix got kicked down the road since we thought the workaround was sufficient. Maybe normally we use virtio nowadays and maybe the new kernel implementation (libata /dev/sdX) can't get locked? What I do not understand is how a second migration can unlock from this state? IIRC our success rate with reproducing it was something on the order of 1/50, too. If you can reproduce it without a CDROM but using the BMDMA interface, that's a good data point. If you can't reproduce it using the ISA interface, that's a phenomenal data point and implicates BMDMA pretty heavily. To be 100% sure we are talking about the same? How would I use the ISA and how would I use the BMDMA interface? Thanks, Peter BMDMA is the PCI HBA for IDE, I think it's the default for most machines that aren't using the AHCI HBA. To get ISA, try launching with the machine isapc which will force it, or add the device manually, it's named isa-ide. The BMDMA PCI device is just named ide. Unfortunately, the BIOS can't boot if I specify device isa-ide. Peter
Re: [Qemu-block] [Qemu-devel] Migration sometimes fails with IDE and Qemu 2.2.1
On 09/04/2015 14:46, Peter Lieven wrote: BMDMA is the PCI HBA for IDE, I think it's the default for most machines that aren't using the AHCI HBA. To get ISA, try launching with the machine isapc which will force it, or add the device manually, it's named isa-ide. The BMDMA PCI device is just named ide. Unfortunately, the BIOS can't boot if I specify device isa-ide. Booting with ide-core.nodma=1 should have the same effect. Paolo
Re: [Qemu-block] [Qemu-devel] Migration sometimes fails with IDE and Qemu 2.2.1
Am 07.04.2015 um 21:13 schrieb John Snow: On 04/07/2015 03:02 PM, Peter Lieven wrote: Am 07.04.2015 um 20:56 schrieb John Snow: On 04/07/2015 02:44 PM, Peter Lieven wrote: Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert: * Peter Lieven (p...@kamp.de) wrote: Hi David, Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert: Any particular workload or reproducer? Workload is almost zero. I try to figure out if there is a way to trigger it. Maybe playing a role: Machine type is -M pc1.2 and we set -kvmclock as CPU flag since kvmclock seemed to be quite buggy in 2.6.16... Exact cmdline is: /usr/bin/qemu-2.2.1 -enable-kvm -M pc-1.2 -nodefaults -netdev type=tap,id=guest2,script=no,downscript=no,ifname=tap2 -device e1000,netdev=guest2,mac=52:54:00:ff:00:65 -drive format=raw,file=iscsi://172.21.200.53/iqn.2001-05.com.equallogic:4-52aed6-88a7e99a4-d9e00040fdc509a3-XXX-hd0/0,if=ide,cache=writeback,aio=native -serial null -parallel null -m 1024 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4003,server,nowait -vnc :3 -qmp tcp:0:3003,server,nowait -name 'XXX' -boot order=c,once=dc,menu=off -drive index=2,media=cdrom,if=ide,cache=unsafe,aio=native,readonly=on -k de -incoming tcp:0:5003 -pidfile /var/run/qemu/vm-146.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu qemu64,-kvmclock Exact kernel is: 2.6.16.46-0.12-smp (i think this is SLES10 or sth.) The machine does not hang. It seems just I/O is hanging. So you can type at the console or ping the system, but no longer login. Thank you, Peter Interesting observation: Migrating the vServer again seems to fix to problem (at least in one case I could test just now). 2.6.8-24-smp is also affected. How often does it fail - you say 'sometimes' - is it a 1/10 or a 1/1000 ? Its more often than 1/10 I would say. OK, that's not too bad - it's the 1/1000 that are really nasty to find. In your setup, how easy would it be for you to try : with either 2.1 or current head? with a newer machine-type? without the cdrom? Its all possible. I can clone the system and try everything on my test systems. I hope it reproduces there. Has the cdrom the power of taking down the bus? Peter I don't know if CDROM could stall the entire bus, but I suspect the reason for asking is this: dgilbert and I had tracked down a problem previously where during migration, outstanding requests being handled by the ATAPI code can get lost during migration if, for instance, the user has only prepared the command (via bmdma) but has not yet written to the register to activate the command yet. That sounds like it could be related. So if something like this happens: - User writes to the ATA registers to program a command - Migration occurs - User writes to the BMDMA register to initiate the command We can lose some of the state and data of the request. David had checked in a workaround for at least ATAPI that simply coaxes the guest OS into trying the command again to unstick it. Do you have the commit for me? http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg01109.html I think we determined last time that we couldn't fix this problem without changing the migration format, so we opted not to do it for 2.3. We had also only noticed it with ATAPI drives, not HDDs, so a proper fix got kicked down the road since we thought the workaround was sufficient. Maybe normally we use virtio nowadays and maybe the new kernel implementation (libata /dev/sdX) can't get locked? What I do not understand is how a second migration can unlock from this state? IIRC our success rate with reproducing it was something on the order of 1/50, too. If you can reproduce it without a CDROM but using the BMDMA interface, that's a good data point. If you can't reproduce it using the ISA interface, that's a phenomenal data point and implicates BMDMA pretty heavily. To be 100% sure we are talking about the same? How would I use the ISA and how would I use the BMDMA interface? Thanks, Peter BMDMA is the PCI HBA for IDE, I think it's the default for most machines that aren't using the AHCI HBA. To get ISA, try launching with the machine isapc which will force it, or add the device manually, it's named isa-ide. The BMDMA PCI device is just named ide. I will start more debugging today I found that other SuSE servers which use the newer interface (presenting as /dev/sdX) do not suffer from the problem. Peter
Re: [Qemu-block] [Qemu-devel] Migration sometimes fails with IDE and Qemu 2.2.1
* Peter Lieven (p...@kamp.de) wrote: Hi David, Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert: Any particular workload or reproducer? Workload is almost zero. I try to figure out if there is a way to trigger it. Maybe playing a role: Machine type is -M pc1.2 and we set -kvmclock as CPU flag since kvmclock seemed to be quite buggy in 2.6.16... Exact cmdline is: /usr/bin/qemu-2.2.1 -enable-kvm -M pc-1.2 -nodefaults -netdev type=tap,id=guest2,script=no,downscript=no,ifname=tap2 -device e1000,netdev=guest2,mac=52:54:00:ff:00:65 -drive format=raw,file=iscsi://172.21.200.53/iqn.2001-05.com.equallogic:4-52aed6-88a7e99a4-d9e00040fdc509a3-XXX-hd0/0,if=ide,cache=writeback,aio=native -serial null -parallel null -m 1024 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4003,server,nowait -vnc :3 -qmp tcp:0:3003,server,nowait -name 'XXX' -boot order=c,once=dc,menu=off -drive index=2,media=cdrom,if=ide,cache=unsafe,aio=native,readonly=on -k de -incoming tcp:0:5003 -pidfile /var/run/qemu/vm-146.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu qemu64,-kvmclock Exact kernel is: 2.6.16.46-0.12-smp (i think this is SLES10 or sth.) The machine does not hang. It seems just I/O is hanging. So you can type at the console or ping the system, but no longer login. Thank you, Peter Interesting observation: Migrating the vServer again seems to fix to problem (at least in one case I could test just now). 2.6.8-24-smp is also affected. How often does it fail - you say 'sometimes' - is it a 1/10 or a 1/1000 ? Its more often than 1/10 I would say. OK, that's not too bad - it's the 1/1000 that are really nasty to find. In your setup, how easy would it be for you to try : with either 2.1 or current head? with a newer machine-type? without the cdrom? Dave I'm not sure at what kernel version the switch is, but newer kernels use some code shared with the newer SATA world (libata?) where as older kernels had separate IDE code, so the behaviour of the two can be quite different. Thats a good point. I will check what the kernels have. I remember that there was sth like a problem with error handling in the old drivers? Paolo, you worked a lot on IDE lately. Do you remember? Thanks, Peter -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-block] [Qemu-devel] Migration sometimes fails with IDE and Qemu 2.2.1
Am 07.04.2015 um 21:01 schrieb Dr. David Alan Gilbert: * Peter Lieven (p...@kamp.de) wrote: Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert: * Peter Lieven (p...@kamp.de) wrote: Hi David, Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert: Any particular workload or reproducer? Workload is almost zero. I try to figure out if there is a way to trigger it. Maybe playing a role: Machine type is -M pc1.2 and we set -kvmclock as CPU flag since kvmclock seemed to be quite buggy in 2.6.16... Exact cmdline is: /usr/bin/qemu-2.2.1 -enable-kvm -M pc-1.2 -nodefaults -netdev type=tap,id=guest2,script=no,downscript=no,ifname=tap2 -device e1000,netdev=guest2,mac=52:54:00:ff:00:65 -drive format=raw,file=iscsi://172.21.200.53/iqn.2001-05.com.equallogic:4-52aed6-88a7e99a4-d9e00040fdc509a3-XXX-hd0/0,if=ide,cache=writeback,aio=native -serial null -parallel null -m 1024 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4003,server,nowait -vnc :3 -qmp tcp:0:3003,server,nowait -name 'XXX' -boot order=c,once=dc,menu=off -drive index=2,media=cdrom,if=ide,cache=unsafe,aio=native,readonly=on -k de -incoming tcp:0:5003 -pidfile /var/run/qemu/vm-146.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu qemu64,-kvmclock Exact kernel is: 2.6.16.46-0.12-smp (i think this is SLES10 or sth.) The machine does not hang. It seems just I/O is hanging. So you can type at the console or ping the system, but no longer login. Thank you, Peter Interesting observation: Migrating the vServer again seems to fix to problem (at least in one case I could test just now). 2.6.8-24-smp is also affected. How often does it fail - you say 'sometimes' - is it a 1/10 or a 1/1000 ? Its more often than 1/10 I would say. OK, that's not too bad - it's the 1/1000 that are really nasty to find. In your setup, how easy would it be for you to try : with either 2.1 or current head? with a newer machine-type? without the cdrom? Its all possible. I can clone the system and try everything on my test systems. I hope it reproduces there. Great. I think the order I would go would be: Try head - if it works we know we've already got the fix somewhere Try 2.1 - if it works we know it's something we introduced between 2.1 and 2.2.1 Try a newer machine type - because pc-1.2 probably isn't tested much I don't mind chaning the machine time. The reason it is pc-1.2 is we set the machine type the vServer was created with. CDROM at the end. Has the cdrom the power of taking down the bus? I just know the cdrom migration is a bit lacking and the simpler the test case the better. Just for the record there was no CD inserted during migration. Peter
Re: [Qemu-block] [Qemu-devel] Migration sometimes fails with IDE and Qemu 2.2.1
* Peter Lieven (p...@kamp.de) wrote: Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert: * Peter Lieven (p...@kamp.de) wrote: Hi David, Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert: Any particular workload or reproducer? Workload is almost zero. I try to figure out if there is a way to trigger it. Maybe playing a role: Machine type is -M pc1.2 and we set -kvmclock as CPU flag since kvmclock seemed to be quite buggy in 2.6.16... Exact cmdline is: /usr/bin/qemu-2.2.1 -enable-kvm -M pc-1.2 -nodefaults -netdev type=tap,id=guest2,script=no,downscript=no,ifname=tap2 -device e1000,netdev=guest2,mac=52:54:00:ff:00:65 -drive format=raw,file=iscsi://172.21.200.53/iqn.2001-05.com.equallogic:4-52aed6-88a7e99a4-d9e00040fdc509a3-XXX-hd0/0,if=ide,cache=writeback,aio=native -serial null -parallel null -m 1024 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4003,server,nowait -vnc :3 -qmp tcp:0:3003,server,nowait -name 'XXX' -boot order=c,once=dc,menu=off -drive index=2,media=cdrom,if=ide,cache=unsafe,aio=native,readonly=on -k de -incoming tcp:0:5003 -pidfile /var/run/qemu/vm-146.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu qemu64,-kvmclock Exact kernel is: 2.6.16.46-0.12-smp (i think this is SLES10 or sth.) The machine does not hang. It seems just I/O is hanging. So you can type at the console or ping the system, but no longer login. Thank you, Peter Interesting observation: Migrating the vServer again seems to fix to problem (at least in one case I could test just now). 2.6.8-24-smp is also affected. How often does it fail - you say 'sometimes' - is it a 1/10 or a 1/1000 ? Its more often than 1/10 I would say. OK, that's not too bad - it's the 1/1000 that are really nasty to find. In your setup, how easy would it be for you to try : with either 2.1 or current head? with a newer machine-type? without the cdrom? Its all possible. I can clone the system and try everything on my test systems. I hope it reproduces there. Great. I think the order I would go would be: Try head - if it works we know we've already got the fix somewhere Try 2.1 - if it works we know it's something we introduced between 2.1 and 2.2.1 Try a newer machine type - because pc-1.2 probably isn't tested much CDROM at the end. Has the cdrom the power of taking down the bus? I just know the cdrom migration is a bit lacking and the simpler the test case the better. Dave Peter -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-block] [Qemu-devel] Migration sometimes fails with IDE and Qemu 2.2.1
On 04/07/2015 02:44 PM, Peter Lieven wrote: Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert: * Peter Lieven (p...@kamp.de) wrote: Hi David, Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert: Any particular workload or reproducer? Workload is almost zero. I try to figure out if there is a way to trigger it. Maybe playing a role: Machine type is -M pc1.2 and we set -kvmclock as CPU flag since kvmclock seemed to be quite buggy in 2.6.16... Exact cmdline is: /usr/bin/qemu-2.2.1 -enable-kvm -M pc-1.2 -nodefaults -netdev type=tap,id=guest2,script=no,downscript=no,ifname=tap2 -device e1000,netdev=guest2,mac=52:54:00:ff:00:65 -drive format=raw,file=iscsi://172.21.200.53/iqn.2001-05.com.equallogic:4-52aed6-88a7e99a4-d9e00040fdc509a3-XXX-hd0/0,if=ide,cache=writeback,aio=native -serial null -parallel null -m 1024 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4003,server,nowait -vnc :3 -qmp tcp:0:3003,server,nowait -name 'XXX' -boot order=c,once=dc,menu=off -drive index=2,media=cdrom,if=ide,cache=unsafe,aio=native,readonly=on -k de -incoming tcp:0:5003 -pidfile /var/run/qemu/vm-146.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu qemu64,-kvmclock Exact kernel is: 2.6.16.46-0.12-smp (i think this is SLES10 or sth.) The machine does not hang. It seems just I/O is hanging. So you can type at the console or ping the system, but no longer login. Thank you, Peter Interesting observation: Migrating the vServer again seems to fix to problem (at least in one case I could test just now). 2.6.8-24-smp is also affected. How often does it fail - you say 'sometimes' - is it a 1/10 or a 1/1000 ? Its more often than 1/10 I would say. OK, that's not too bad - it's the 1/1000 that are really nasty to find. In your setup, how easy would it be for you to try : with either 2.1 or current head? with a newer machine-type? without the cdrom? Its all possible. I can clone the system and try everything on my test systems. I hope it reproduces there. Has the cdrom the power of taking down the bus? Peter I don't know if CDROM could stall the entire bus, but I suspect the reason for asking is this: dgilbert and I had tracked down a problem previously where during migration, outstanding requests being handled by the ATAPI code can get lost during migration if, for instance, the user has only prepared the command (via bmdma) but has not yet written to the register to activate the command yet. So if something like this happens: - User writes to the ATA registers to program a command - Migration occurs - User writes to the BMDMA register to initiate the command We can lose some of the state and data of the request. David had checked in a workaround for at least ATAPI that simply coaxes the guest OS into trying the command again to unstick it. I think we determined last time that we couldn't fix this problem without changing the migration format, so we opted not to do it for 2.3. We had also only noticed it with ATAPI drives, not HDDs, so a proper fix got kicked down the road since we thought the workaround was sufficient. IIRC our success rate with reproducing it was something on the order of 1/50, too. If you can reproduce it without a CDROM but using the BMDMA interface, that's a good data point. If you can't reproduce it using the ISA interface, that's a phenomenal data point and implicates BMDMA pretty heavily. --js
Re: [Qemu-block] [Qemu-devel] Migration sometimes fails with IDE and Qemu 2.2.1
Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert: * Peter Lieven (p...@kamp.de) wrote: Hi David, Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert: Any particular workload or reproducer? Workload is almost zero. I try to figure out if there is a way to trigger it. Maybe playing a role: Machine type is -M pc1.2 and we set -kvmclock as CPU flag since kvmclock seemed to be quite buggy in 2.6.16... Exact cmdline is: /usr/bin/qemu-2.2.1 -enable-kvm -M pc-1.2 -nodefaults -netdev type=tap,id=guest2,script=no,downscript=no,ifname=tap2 -device e1000,netdev=guest2,mac=52:54:00:ff:00:65 -drive format=raw,file=iscsi://172.21.200.53/iqn.2001-05.com.equallogic:4-52aed6-88a7e99a4-d9e00040fdc509a3-XXX-hd0/0,if=ide,cache=writeback,aio=native -serial null -parallel null -m 1024 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4003,server,nowait -vnc :3 -qmp tcp:0:3003,server,nowait -name 'XXX' -boot order=c,once=dc,menu=off -drive index=2,media=cdrom,if=ide,cache=unsafe,aio=native,readonly=on -k de -incoming tcp:0:5003 -pidfile /var/run/qemu/vm-146.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu qemu64,-kvmclock Exact kernel is: 2.6.16.46-0.12-smp (i think this is SLES10 or sth.) The machine does not hang. It seems just I/O is hanging. So you can type at the console or ping the system, but no longer login. Thank you, Peter Interesting observation: Migrating the vServer again seems to fix to problem (at least in one case I could test just now). 2.6.8-24-smp is also affected. How often does it fail - you say 'sometimes' - is it a 1/10 or a 1/1000 ? Its more often than 1/10 I would say. OK, that's not too bad - it's the 1/1000 that are really nasty to find. In your setup, how easy would it be for you to try : with either 2.1 or current head? with a newer machine-type? without the cdrom? Its all possible. I can clone the system and try everything on my test systems. I hope it reproduces there. Has the cdrom the power of taking down the bus? Peter
Re: [Qemu-block] [Qemu-devel] Migration sometimes fails with IDE and Qemu 2.2.1
On 07/04/2015 20:44, Peter Lieven wrote: Has the cdrom the power of taking down the bus? IDE can only issue one command per bus, so hda/hdb can take down each other, and hdc/hdd can take down each other. However, hda cannot take down hdc and vice versa---so likely the CDROM cannot take down the hard disk. Paolo
