search for: vda

On 11/20/2017 08:42 PM, Jens Axboe wrote: > On 11/20/2017 12:29 PM, Christian Borntraeger wrote: >> >> >> On 11/20/2017 08:20 PM, Bart Van Assche wrote: >>> On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote: >>>> This is >>>> >>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1141) * are mapped to

On 11/20/2017 08:42 PM, Jens Axboe wrote: > On 11/20/2017 12:29 PM, Christian Borntraeger wrote: >> >> >> On 11/20/2017 08:20 PM, Bart Van Assche wrote: >>> On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote: >>>> This is >>>> >>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1141) * are mapped to

...this info both > before and after the hotplug event. It happens in all variants (1 cpu to 2 or 16 to 17 and independent of the number of disks). What I can see is that the block layer does not yet sees the new CPU: [root at zhyp137 ~]# find /sys/kernel/debug/block/vd* /sys/kernel/debug/block/vda /sys/kernel/debug/block/vda/hctx0 /sys/kernel/debug/block/vda/hctx0/cpu0 /sys/kernel/debug/block/vda/hctx0/cpu0/completed /sys/kernel/debug/block/vda/hctx0/cpu0/merged /sys/kernel/debug/block/vda/hctx0/cpu0/dispatched /sys/kernel/debug/block/vda/hctx0/cpu0/rq_list /sys/kernel/debug/block/vda/hctx0/...

...this info both > before and after the hotplug event. It happens in all variants (1 cpu to 2 or 16 to 17 and independent of the number of disks). What I can see is that the block layer does not yet sees the new CPU: [root at zhyp137 ~]# find /sys/kernel/debug/block/vd* /sys/kernel/debug/block/vda /sys/kernel/debug/block/vda/hctx0 /sys/kernel/debug/block/vda/hctx0/cpu0 /sys/kernel/debug/block/vda/hctx0/cpu0/completed /sys/kernel/debug/block/vda/hctx0/cpu0/merged /sys/kernel/debug/block/vda/hctx0/cpu0/dispatched /sys/kernel/debug/block/vda/hctx0/cpu0/rq_list /sys/kernel/debug/block/vda/hctx0/...

...t;> Can you try the below? >>>> >>>> >>>> It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: >>>> >>>> >>>> output with 2 cpus: >>>> /sys/kernel/debug/block/vda >>>> /sys/kernel/debug/block/vda/hctx0 >>>> /sys/kernel/debug/block/vda/hctx0/cpu0 >>>> /sys/kernel/debug/block/vda/hctx0/cpu0/completed >>>> /sys/kernel/debug/block/vda/hctx0/cpu0/merged >>>> /sys/kernel/debug/block/vda/hctx0/cpu0/dispatc...

...t;> Can you try the below? >>>> >>>> >>>> It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: >>>> >>>> >>>> output with 2 cpus: >>>> /sys/kernel/debug/block/vda >>>> /sys/kernel/debug/block/vda/hctx0 >>>> /sys/kernel/debug/block/vda/hctx0/cpu0 >>>> /sys/kernel/debug/block/vda/hctx0/cpu0/completed >>>> /sys/kernel/debug/block/vda/hctx0/cpu0/merged >>>> /sys/kernel/debug/block/vda/hctx0/cpu0/dispatc...

...can come up with an appropriate fix. >>> >>> Can you try the below? >> >> >> It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: >> >> >> output with 2 cpus: >> /sys/kernel/debug/block/vda >> /sys/kernel/debug/block/vda/hctx0 >> /sys/kernel/debug/block/vda/hctx0/cpu0 >> /sys/kernel/debug/block/vda/hctx0/cpu0/completed >> /sys/kernel/debug/block/vda/hctx0/cpu0/merged >> /sys/kernel/debug/block/vda/hctx0/cpu0/dispatched >> /sys/kernel/debug/block/vda...

...can come up with an appropriate fix. >>> >>> Can you try the below? >> >> >> It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: >> >> >> output with 2 cpus: >> /sys/kernel/debug/block/vda >> /sys/kernel/debug/block/vda/hctx0 >> /sys/kernel/debug/block/vda/hctx0/cpu0 >> /sys/kernel/debug/block/vda/hctx0/cpu0/completed >> /sys/kernel/debug/block/vda/hctx0/cpu0/merged >> /sys/kernel/debug/block/vda/hctx0/cpu0/dispatched >> /sys/kernel/debug/block/vda...

...gt;>>>>> >>>>>> It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: >>>>>> >>>>>> >>>>>> output with 2 cpus: >>>>>> /sys/kernel/debug/block/vda >>>>>> /sys/kernel/debug/block/vda/hctx0 >>>>>> /sys/kernel/debug/block/vda/hctx0/cpu0 >>>>>> /sys/kernel/debug/block/vda/hctx0/cpu0/completed >>>>>> /sys/kernel/debug/block/vda/hctx0/cpu0/merged >>>>>> /sys/k...

...gt;>>>>> >>>>>> It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: >>>>>> >>>>>> >>>>>> output with 2 cpus: >>>>>> /sys/kernel/debug/block/vda >>>>>> /sys/kernel/debug/block/vda/hctx0 >>>>>> /sys/kernel/debug/block/vda/hctx0/cpu0 >>>>>> /sys/kernel/debug/block/vda/hctx0/cpu0/completed >>>>>> /sys/kernel/debug/block/vda/hctx0/cpu0/merged >>>>>> /sys/k...

...this just fine, your patch broke it. >> >> I'll see if I can come up with an appropriate fix. > > Can you try the below? It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: output with 2 cpus: /sys/kernel/debug/block/vda /sys/kernel/debug/block/vda/hctx0 /sys/kernel/debug/block/vda/hctx0/cpu0 /sys/kernel/debug/block/vda/hctx0/cpu0/completed /sys/kernel/debug/block/vda/hctx0/cpu0/merged /sys/kernel/debug/block/vda/hctx0/cpu0/dispatched /sys/kernel/debug/block/vda/hctx0/cpu0/rq_list /sys/kernel/debug/block/vda/hctx0/...

...this just fine, your patch broke it. >> >> I'll see if I can come up with an appropriate fix. > > Can you try the below? It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: output with 2 cpus: /sys/kernel/debug/block/vda /sys/kernel/debug/block/vda/hctx0 /sys/kernel/debug/block/vda/hctx0/cpu0 /sys/kernel/debug/block/vda/hctx0/cpu0/completed /sys/kernel/debug/block/vda/hctx0/cpu0/merged /sys/kernel/debug/block/vda/hctx0/cpu0/dispatched /sys/kernel/debug/block/vda/hctx0/cpu0/rq_list /sys/kernel/debug/block/vda/hctx0/...

...>>>> >>>> Can you try the below? >>> >>> >>> It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: >>> >>> >>> output with 2 cpus: >>> /sys/kernel/debug/block/vda >>> /sys/kernel/debug/block/vda/hctx0 >>> /sys/kernel/debug/block/vda/hctx0/cpu0 >>> /sys/kernel/debug/block/vda/hctx0/cpu0/completed >>> /sys/kernel/debug/block/vda/hctx0/cpu0/merged >>> /sys/kernel/debug/block/vda/hctx0/cpu0/dispatched >>> /sy...

...? >>>>> >>>>> >>>>> It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: >>>>> >>>>> >>>>> output with 2 cpus: >>>>> /sys/kernel/debug/block/vda >>>>> /sys/kernel/debug/block/vda/hctx0 >>>>> /sys/kernel/debug/block/vda/hctx0/cpu0 >>>>> /sys/kernel/debug/block/vda/hctx0/cpu0/completed >>>>> /sys/kernel/debug/block/vda/hctx0/cpu0/merged >>>>> /sys/kernel/debug/block/vd...

...gt; >>>>>>> It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: >>>>>>> >>>>>>> >>>>>>> output with 2 cpus: >>>>>>> /sys/kernel/debug/block/vda >>>>>>> /sys/kernel/debug/block/vda/hctx0 >>>>>>> /sys/kernel/debug/block/vda/hctx0/cpu0 >>>>>>> /sys/kernel/debug/block/vda/hctx0/cpu0/completed >>>>>>> /sys/kernel/debug/block/vda/hctx0/cpu0/merged >>>&gt...

...hot for VM , to obtain VM incremental data，and use virsh blockcommit，qemu-img commit，qemu-img rebase to shorten snapshot chain. Details are as follows（when VM running state， we perform the following operations）: (1) the host machine control VM test virsh snapshot-create-as mix snap1 --diskspec vda,file=/tmp/mul/loop-mix-commit-rebase/snap1-mix.img --disk-only --atomic --quiesce virsh snapshot-create-as mix snap2 --diskspec vda,file=/tmp/mul/loop-mix-commit-rebase/snap2-mix.img --disk-only --atomic --quiesce virsh snapshot-create-as mix snap3 --diskspec vda,file=/tmp/mul/loop-mix-commit-rebas...

Hello, it happened with another VM: # virsh snapshot-create-as --domain rasa sn1 --diskspec vda,file=/var/lib/libvirt/images/rasa-sn1.qcow2 --disk-only --atomic --no-metadata # virsh blockcommit rasa vda --active --verbose --pivot Block commit: [100 %]error: failed to pivot job for disk vda error: block copy still active: disk 'vda' not ready for pivot yet # virsh domblklist rasa T...

...>>> I'll see if I can come up with an appropriate fix. >> >> Can you try the below? > > > It does prevent the crash but it seems that the new CPU is not "used " after the hotplug for mq: > > > output with 2 cpus: > /sys/kernel/debug/block/vda > /sys/kernel/debug/block/vda/hctx0 > /sys/kernel/debug/block/vda/hctx0/cpu0 > /sys/kernel/debug/block/vda/hctx0/cpu0/completed > /sys/kernel/debug/block/vda/hctx0/cpu0/merged > /sys/kernel/debug/block/vda/hctx0/cpu0/dispatched > /sys/kernel/debug/block/vda/hctx0/cpu0/rq_list >...

...nt bitmap, and > takes the snapshot at the point in time where it is started, not where > it is ended); I'm also trying to figure out what API additions are > needed to libvirt to expose that capability as an alternative. Okay, understood. >> >>> virsh blockcopy dom vda /path/to/backup-vda >>> polling loop - check periodically until 'virsh blockjob dom vda' >>> shows 100% completion >>> virsh suspend dom >>> virsh save dom /path/to/memory-backup --running >> >> This does not work for me. >> &g...

Hi everyone! I use the libvirt(version: 1.2.2) and QEMU(version: 2.2.1) to test qemu snapshot features: I tried virsh blockcommit when VM offline, the virsh blockcommit failed: the error messase as below: error: Requested operation is not valid: domain is not running when I start the VM, the virsh blockcommit work fine! my question is：we need