ACK series, thanks.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk
Remove (almost) all the remaining bits related to virt-p2v.
---
.gitignore | 4 -
Makefile.am | 4 +-
bash/Makefile.am | 4 -
bash/virt-alignment-scan | 18 --
common/miniexpect/Makefile.am| 51
Now that virt-p2v has its own repository [1] and releases [2], it is
time to remove it from libguestfs.
[1] https://github.com/libguestfs/virt-p2v
[2] http://download.libguestfs.org/virt-p2v/
Pino Toscano (2):
Remove virt-p2v
Remove remaining virt-p2v bits
.gitignore
On Tue, Sep 10, 2019 at 08:11:10AM -0500, Eric Blake wrote:
> > +=head1 EXPORT NAME
> > +
> > +If the client negotiated an NBD export name with nbdkit then plugins
> > +may read this from any connected callbacks. Nbdkit's normal behaviour
> > +is to accept any export name passed by the client,
On Tue, Sep 10, 2019 at 07:58:49AM -0500, Eric Blake wrote:
> On 9/10/19 5:01 AM, Richard W.M. Jones wrote:
> > Of course at the moment nbdkit parses the NBD export name option but
> > doesn't really do anything with it (except logging it).
> >
> > I wonder if we should make this available to
On 9/10/19 6:20 AM, Richard W.M. Jones wrote:
> This allows plugins (or filters) to read the export name which was
> passed to the server from the client.
>
> UNFINISHED:
>
> - Needs tests
> ---
> TODO | 8 ++
> docs/nbdkit-plugin.pod | 39
On 9/10/19 5:01 AM, Richard W.M. Jones wrote:
> Of course at the moment nbdkit parses the NBD export name option but
> doesn't really do anything with it (except logging it).
>
> I wonder if we should make this available to plugins, in case they
> wish to serve different content to different
This allows plugins (or filters) to read the export name which was
passed to the server from the client.
UNFINISHED:
- Needs tests
---
TODO | 8 ++
docs/nbdkit-plugin.pod | 39
server/connections.c
This is the sort of thing I had in mind for option (1) here:
https://www.redhat.com/archives/libguestfs/2019-September/msg00047.html
It does reveal that the way we currently list exports is naive to say
the least ...
Rich.
___
Libguestfs mailing
On Tue, Sep 10, 2019 at 11:01:10AM +0100, Richard W.M. Jones wrote:
> The implementation of this is straightforward. It simply reads the
> exportname global from the server and returns it. It also doesn't
> change the existing API at all.
Sorry - of course I don't mean returning the global
Of course at the moment nbdkit parses the NBD export name option but
doesn't really do anything with it (except logging it).
I wonder if we should make this available to plugins, in case they
wish to serve different content to different clients based on the
export name. Note I'm not suggesting
On Monday, 9 September 2019 18:00:35 CEST Richard W.M. Jones wrote:
> From: Daniel Erez
>
> After invoking transfer_service.finalize, check operation status by
> examining DiskStatus. This is done instead of failing after a
> predefined timeout regardless the status.
>
> Bug-Url:
12 matches
Mail list logo