similar to: libvirt live migration, qcow2 image, nbd server

On 02/13/2015 03:15 AM, Kashyap Chamarthy wrote: > On Thu, Feb 12, 2015 at 08:41:31PM -0600, Edward Young wrote: >> Hi all, >> >> >> When I live migrate a vm using >> >> "migrate --live --copy-storage-all mig-vm qemu+ssh://192.168.1.3/system >> tcp://192.168.1.3" >> >> >> I got the following error >> >> >>

On 02/12/2015 07:41 PM, Edward Young wrote: > Hi all, > > > When I live migrate a vm using > > "migrate --live --copy-storage-all mig-vm qemu+ssh://192.168.1.3/system > tcp://192.168.1.3" > > > I got the following error > > > WARNING: Image format was not specified for > 'nbd://node2:49155/drive-virtio-disk0' and

On Thu, Feb 12, 2015 at 08:41:31PM -0600, Edward Young wrote: > Hi all, > > > When I live migrate a vm using > > "migrate --live --copy-storage-all mig-vm qemu+ssh://192.168.1.3/system > tcp://192.168.1.3" > > > I got the following error > > > WARNING: Image format was not specified for >

Hi, List, I''m trying xl create a pv guest with qcow/qcow2 image, it always fails at libxl_device_disk_local_attach. #xl create pv_config_file libxl: error: libxl.c:1119:libxl_device_disk_local_attach: cannot locally attach a qdisk image if the format is not raw libxl: error: libxl_create.c:467:do_domain_create: failed to run bootloader: -3 disk configuration is: disk=[

Hi all, As I am doing some tests with qemu, I realized that the way it does 'migrate -i tcp:DEST:444' is not the same as 'libvirt migrate --copy-storage-inc'. Basically qemu uses the same stream as RAM migration and libvirt takes advantage of NBD transfer. With virsh migrate-setspeed I observed that one can only control the transfer throughput of RAM, but not disk

On Wed, Nov 21, 2018 at 09:25:05AM +0000, Richard W.M. Jones wrote: > nbdkit: file.2: error: invalid request: offset and count are out of range: offset=196608 count=512 Actually what happens even more precisely is that the underlying file is not a multiple of 512 bytes (196624 ≡ 16 mod 512). qemu-img (the client) issues a request for the final "sector" of the file which goes beyond

Hello list, upon upgrading from libvirt v5.9.0 -> v5.10.0, libvirt started calling qemu differently causing the VM operating system to not be found. I'm wondering whether I'm chasing a bug, or have to otherwise fix my domain config (created by virt-manager). To start with, I have a Windows 7 domain based on the following images: windows7-base.qcow2: QEMU QCOW2 Image (v3),

2017-07-27 20:18 GMT+08:00 Richard W.M. Jones <rjones@redhat.com>: > On Thu, Jul 27, 2017 at 06:34:13PM +0800, lampahome wrote: > > I can mount qcow2 img to nbd devices through guestfish or qemu-nbd > > > > I'm curious about which performance is better? > > They do quite different things, they're not comparable. > > Can you specifically give the

Now that we have implemented systemd socket activation, we can use this to run qemu-nbd in tests. The first patch leaves some dead code around (the -DSERVE_OVER_TCP=1 path). It's possible we might want to use this to test against a putative future NBD server that only supports TCP, but on the other hand maybe we should just remove it. Tests & valgrind still pass for me. Rich.

Hello, I face a problem on the nbdkit server: Version-Release number of selected component (if applicable): nbdkit-v1.9.1 qemu-utils-2.12+dfsg-3+b1 How reproducible: 100% Steps: 1. Create a qcow2 file # qemu-img create disk 1G -f qcow2 2. Export the qcow2 file then try to read it via nbd url # nbdkit file file=disk -e raw -v nbdkit: debug: TLS disabled: could not load TLS certificates nbdkit:

2017-07-28 0:31 GMT+08:00 Richard W.M. Jones <rjones@redhat.com>: > On Fri, Jul 28, 2017 at 12:23:04AM +0800, lampahome wrote: > > 2017-07-27 20:18 GMT+08:00 Richard W.M. Jones <rjones@redhat.com>: > > > > > On Thu, Jul 27, 2017 at 06:34:13PM +0800, lampahome wrote: > > > > I can mount qcow2 img to nbd devices through guestfish or qemu-nbd > >

Hi All, I am unable to figure out the issue here, when I try to create a filesystem (ext4) on a virtual disk using qemu-nbd. This happens intermittently. Following is the sequence of commands:- $> qemu-img create -f qcow2 test.qcow2 30G $> qemu-nbd --connect=/dev/nbd0 test.qcow2 $> *mkfs.ext4 /dev/nbd0* * mkfs.ext4: Device size reported to be zero. Invalid partition specified, or*

The docs are a lot more useful with a graphic showing how to wire together nbdkit as a bridge from old-to-new. The converse, bridging new-to-old, is best deferred until I add support for the nbd plugin connecting to a TCP socket. It is also worth mentioning use of nbdkit filters (after all, qemu-nbd 4.0 was able to deprecate its --partition option by pointing to 'nbdkit --filter=partition nbd

I can mount qcow2 img to nbd devices through guestfish or qemu-nbd I'm curious about which performance is better?

On Wed, Nov 21, 2018 at 10:33 PM Eric Blake <eblake@redhat.com> wrote: > On 11/21/18 4:39 AM, Richard W.M. Jones wrote: > > On Wed, Nov 21, 2018 at 09:25:05AM +0000, Richard W.M. Jones wrote: > >> nbdkit: file.2: error: invalid request: offset and count are out of > range: offset=196608 count=512 > > > > Actually what happens even more precisely is that the

[Adding libguestfs mailing list] On Sun, Oct 14, 2018 at 11:53:17AM -0400, Raghuram Devarakonda wrote: > Hi, > > My name is Raghuram Devarakonda and I am a big fan of "nbdkit". I have > successfully used it to prototype (using Python plugin) a complex > project in our company and since then, I have also been trying to > understand and learn "guestfs-tools"

Add support for qcow2 disk format, enabled by imageio NBD backend in RHV 4.3. To use this feature manually, you can run virt-v2v with "-of qcow2". Here is example run: Source disk: $ qemu-img info /var/tmp/fedora-30.img image: /var/tmp/fedora-30.img file format: raw virtual size: 6 GiB (6442450944 bytes) disk size: 1.15 GiB virt-v2v: $ ./run virt-v2v \ -v \ -i disk

The first four patches are fairly routine clean up and can be reviewed/applied on their own. The fifth patch is problematic as described below. At the moment if you want to proxy through to qemu-nbd (eg. for handling qcow2 files) it's rather complicated and you end up having to manage the sockets and clean up yourself. However the library we use for the proxying supports a perfectly good

I got annoyed by qemu-nbd's default of only allowing a single connection; combine that with nbdkit's nbd plugin, and even 'qemu-nbd --list' of nbdkit counts as the single connection and immediately hangs up. If we introduce a shared mode, then 'qemu-nbd --list' can connect as many times as it wants without killing the original qemu-nbd wrapped by nbdkit. But this in turn