Please see Fam's patch series "[PATCH for-2.10 0/4] block: Fix non-
shared storage migration" that fixes this issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711602
Title:
--copy-storage-all f
After further investigation on IRC the following points were raised:
1. Non-vcpu threads in QEMU weren't being isolated. Libvirt can do this
using the domain XML element. The guest can create a high
load if some QEMU threads are unconstrained.
2. The wait% CPU stat was causing confusion.
I'm unable to reproduce this issue. The host stays responsive and the
dd command completes in a reasonable amount of time. QEMU does not
exceed the 64-thread pool size.
Please post steps to reproduce the issue using a minimal command-line
without libvirt.
Here is information on my attempt to re
> "migrate -b tcp ::1234"
There should be no space between tcp and the rest of the connection
details:
migrate -b tcp::1234
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1192499
Title:
virsh migra
The destination VM's log says:
qemu: warning: error while loading state section id 1
This indicates that either there was an error on the destination while
loading state or the migration stream got out of sync.
Please check that QEMU on source and destination are identical. If you
are running
On Tue, Dec 18, 2012 at 10:18:20AM -, Andy Menzel wrote:
> Any solution right now? I have a similar problem like Todor Andreev;
> Our daily backup of some virtual machines (qcow2) looks like that:
>
> 1. shutdown the VM
> 2. create a snapshot via: "qemu-img snapshot -c nameofsnapshot..."
> 3.
On Mon, Nov 26, 2012 at 1:43 PM, Andreas Färber wrote:
> Am 26.11.2012 13:10, schrieb Stefan Hajnoczi:
>> visit_type_size() requires either visitor->type_size() or
>> visitor_uint64() to be implemented, otherwise a NULL function pointer is
>> invoked.
>>
>> It
Please use cache=none for disks. The default cache setting is
"writethrough" which means the image file is opened with O_DSYNC. Every
single write is flushed to disk.
Modern guests run much faster using cache=none and data is safe as long
as the guest issues cache flushes when appropriate (which
Can you please add steps to reproduce this bug? It's not clear to me
when this happens.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/658610
Title:
Check whether images have write permissions
--
