similar to: live migration taking forever

On Thu, Jan 22, 2015 at 9:11 PM, Xu (Simon) Chen <xchenum@gmail.com> wrote: > Hey folks, > > I am running libvirt 1.2.4 and qemu 2.1 on a 3.14.27 kernel. I've found that > live migrating a relatively large VM (16 cores and 64G ram) is taking > forever - close to 15 hours now, and still not done... > > With "lsof -i", I can see a connection is established

I'm curious that why librbd sets this limitation? The rule first appeared in librbd.git commit d57485f73ab. Theoretically, a write-through cache is also safe for VM migration, if the cache implementation guarantees that cache invalidation and disk write are synchronous operations. For example, I'm using Ceph RBD images as VM storage backend. The Ceph librbd supports synchronous

Hello, I would like to use RBD Format 2 images so I can take advantage of layering. However, when I use "qemu-img create -f rbd rbd:data/foo 10G", I get format 1 RBD images. (Actually, when I use the "-f rbd" flag, qemu-img core dumps, but it looks like that feature may have been deprecated [1]) Is there any way to have qemu-img create RBD Format 2 images or am I better off

On 7/29/19 3:51 AM, Ming-Hung Tsai wrote: > I'm curious that why librbd sets this limitation? The rule first > appeared in librbd.git commit d57485f73ab. Theoretically, a > write-through cache is also safe for VM migration, if the cache > implementation guarantees that cache invalidation and disk write are > synchronous operations. > > For example, I'm using Ceph RBD

Hello everyone, To increase my odds of finding an answer I also wanted to ask here. This is my post from serverfault[1] in verbatim: While trying to get a cloned disk running from my OS snapshot I run into the problem that Libvirt cannot see existing images cloned from a snapshot. Created via: # rbd -p vmdisks clone vmdisks/coreos_2023@base vmdisks/coreos00.disk The base image has the one

Hi, I''ve been working on getting a working blktap driver allowing to access ceph RBD block devices without relying on the RBD kernel driver and it finally got to a point where, it works and is testable. Some of the advantages are: - Easier to update to newer RBD version - Allows functionality only available in the userspace RBD library (write cache, layering, ...) - Less issue when

Hello, Current version adding 'auth_supported=none' at the end of disk path and failing to do an authentication with specified cephx key: <source protocol='rbd' name='rbd/vmxxxxxxxxx:id=qemukvm:key=[cut]==:auth_supported=cephx'> <host name='10.0.0.13' port='6789'/> <host name='10.0.0.10' port='6789'/>

I recently got an EEEbox. This is an Atom based nettop. It came with a wireless keyboard/mouse which talk to a 2.4Ghz USB adapter (a Chicony device as it turns out). Now if I plug this adapter into a Centos 4.8 machine both the keyboard and mouse are detected... but mouse clicks aren't. I can move the mouse, the scroll wheel works, but buttons 1/2/3 aren't detected. Neither in X nor

Hey Hilko, >> I'm guessing that you're using Ubuntu, am I right? Pretty good guess. :) For the time being I'm using 13.10. I know I've said it previously, but your right, I should include that info so I don't make people have to go digging. How do you normally deal with that warning? I typically rename the kvm binary, then link qemu-system-x86_64 but my concern is

Hi, When trying to attach a created volume to an instance using the virsh utility I am running into this error :- [] $ sudo virsh attach-device instance-00000015 disk.xml error: Failed to attach device from disk.xml error: internal error unable to execute QEMU command '__com.redhat_drive_add': Device 'drive-virtio-disk21' could not be initialized For experimental purpose I

Another NUC alternative: https://www.gigabyte.com/uk/Mini-PcBarebone On 2019-07-10 12:14, Mike wrote: > https://www.asrock.com/nettop/index.asp > > Asrock has a series of Intel and/or AMD based mini-pc's called the > DeskMini. > Competes in the Intel NUC space. > Plenty of power and up-to-date components, multiple ports for dual > monitor and at least two ssd's,

On 10/17/2013 05:28 AM, Jon wrote: > Hello, > > I would like to use RBD Format 2 images so I can take advantage of layering. > > However, when I use "qemu-img create -f rbd rbd:data/foo 10G", I get > format 1 RBD images. (Actually, when I use the "-f rbd" flag, qemu-img > core dumps, but it looks like that feature may have been deprecated [1]) > > Is

This series improves ceph rbd support in libguestfs. It uses the servers list, adds support for a custom username, and starts to add support for custom secret.

Hi, Since this message(https://www.redhat.com/archives/libvirt-users/2012-October/msg00054.html) qemu folks have released one minor version in the 1.2 branch and shiny new 1.3 some days ago and the problem still persists. At first I has blamed libvirt, but I was not correct at all - since I have released package ``slices'' for myself including both newer libvirth and qemu, I wasn`t able

Miscellaneous fixes to: - Handling of Ceph drives now works end-to-end (RHBZ#1026688). - In particular, you can now use rbd:/// URIs in guestfish (and they work). - Parse Ceph & NBD network drives from libvirt XML correctly, so that existing domains with Ceph/NBD drives can be added (eg. using guestfish -d option). - Add more testing of the above.

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103

On Thu, Feb 26, 2015 at 5:36 PM, Daniel P. Berrange <berrange@redhat.com> wrote: > On Thu, Feb 26, 2015 at 06:29:49PM +0400, Andrey Korolyov wrote: >> Hello, >> >> I think it would be useful if libvirt will be able to prefix all >> messages from emulator pipes with the date stamping, for example I am >> trying to catch very rare and non-fatal race with

2014-08-26 19:11 GMT+04:00 Andrey Korolyov <andrey@xdel.ru>: > not, right now it is not possible. Why don`t you want to just assign > unique paths for socket name, derived, say, from VM` UUID? > In case of unix domain sockets paths not problem, but i want to connect to each qemu-ga address from central point. I don't want to use socat , as i see qemu have ability to specify

Hi, There is a quite annoying thing, don`t sure if I can call it a bug. How to reproduce: - start a bunch of VMs, - stop libvirt, - start libvirt and immediately issue any call, say, 'virsh version', - delay until call completion may be fitted nearly as quadratic function from number of running VMs, qemu-kvm in my case (see link below). After this delay passed, any calls executed

On Mon, Nov 3, 2014 at 4:24 PM, Michal Privoznik <mprivozn@redhat.com> wrote: > On 01.11.2014 05:30, Dennis Jacobfeuerborn wrote: >> >> Hi, >> I'm trying to find out how to enable fstrim support for libvirt/qemu >> guests. Specifically I'm trying to enable this on a CentOS 7 host (qemu >> 1.5). I searched the web but only found very vague information