Libguestfs - Apr 2018 - Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk

On 04/12/2018 05:24 AM, Richard W.M. Jones wrote:
> I don't think we have nbd-server in RHEL, and in any case wouldn't
it
> be better to use qemu-nbd?
> 
> You just start a new qemu-nbd process instead of faffing around with
> configuration files, kill the qemu-nbd process when you're done, and
> qemu-nbd supports qcow2 already.
That, and qemu-nbd supports extensions such as NBD_CMD_BLOCK_STATUS and
NBD_OPT_STRUCTURED_REPLY that nbd-server has not implemented yet; a qemu
NBD client talking to a qemu-nbd server is thus going to be able to take
advantage of those extensions for better performance that would not be
possible with a qemu NBD client talking to an nbd-server instance (at
least, not without someone implementing the new features there).  And
this is no different from the situation where nbdkit as the server lacks
several features; the current rhv-upload patches use a python plugin to
nbdkit, which is implemented as serializing all requests; while using
qemu-nbd as the server would allow parallel requests to be in flight
simultaneously.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

On Thu, Apr 12, 2018 at 5:42 PM Eric Blake <eblake@redhat.com> wrote:
> On 04/12/2018 05:24 AM, Richard W.M. Jones wrote:
>
> > I don't think we have nbd-server in RHEL, and in any case
wouldn't it
> > be better to use qemu-nbd?
> >
> > You just start a new qemu-nbd process instead of faffing around with
> > configuration files, kill the qemu-nbd process when you're done,
and
> qemu-nbd supports qcow2 already.
> That, and qemu-nbd supports extensions such as NBD_CMD_BLOCK_STATUS and
> NBD_OPT_STRUCTURED_REPLY that nbd-server has not implemented yet; a qemu
> NBD client talking to a qemu-nbd server is thus going to be able to take
> advantage of those extensions for better performance that would not be
> possible with a qemu NBD client talking to an nbd-server instance (at
> least, not without someone implementing the new features there).  And
> this is no different from the situation where nbdkit as the server lacks
> several features; the current rhv-upload patches use a python plugin to
> nbdkit, which is implemented as serializing all requests; while using
> qemu-nbd as the server would allow parallel requests to be in flight
> simultaneously.
>
Right, qemu-nbd will be better.

The manual is not very useful - do we have examples somewhere?

We will consider this for 4.3.

Nir

On Thu, Apr 12, 2018 at 03:44:26PM +0000, Nir Soffer
wrote:
> On Thu, Apr 12, 2018 at 5:42 PM Eric Blake <eblake@redhat.com> wrote:
> 
> > On 04/12/2018 05:24 AM, Richard W.M. Jones wrote:
> >
> > > I don't think we have nbd-server in RHEL, and in any case
wouldn't it
> > > be better to use qemu-nbd?
> > >
> > > You just start a new qemu-nbd process instead of faffing around
with
> > > configuration files, kill the qemu-nbd process when you're
done, and
> 
> > qemu-nbd supports qcow2 already.
> 
> 
> > That, and qemu-nbd supports extensions such as NBD_CMD_BLOCK_STATUS
and
> > NBD_OPT_STRUCTURED_REPLY that nbd-server has not implemented yet; a
qemu
> > NBD client talking to a qemu-nbd server is thus going to be able to
take
> > advantage of those extensions for better performance that would not be
> > possible with a qemu NBD client talking to an nbd-server instance (at
> > least, not without someone implementing the new features there).  And
> > this is no different from the situation where nbdkit as the server
lacks
> > several features; the current rhv-upload patches use a python plugin
to
> > nbdkit, which is implemented as serializing all requests; while using
> > qemu-nbd as the server would allow parallel requests to be in flight
> > simultaneously.
> >
> 
> Right, qemu-nbd will be better.
> 
> The manual is not very useful - do we have examples somewhere?
For another project I'm currently running qemu-nbd like this to serve
out the NBD root disk of a small development board that lacks SATA:

  qemu-nbd -t -f raw -x / /dev/VG/root &

That will open a TCP connection on port 10809 which is the standard
NBD port (but you can change the port with the -p option).

For testing you can connect to the server using qemu-io (low level
reads and writes of blocks) or using libguestfs, eg:

  guestfish --format=raw -a nbd://server:10809/
  ><fs> run
  ><fs> list-filesystems
  ><fs> mount /dev/sda1 /
  ><fs> ll /

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v