On Mon, 15 Oct 2018, Nir Soffer wrote:
> On Sat, Oct 13, 2018 at 9:45 PM Eric Wheeler wrote:
> Hello all,
>
> It might be neat to attach ISOs to KVM guests via websockets. Basically
> the browser would be the NBD "server" and an NBD client would run on
> the
>
On Thu, May 28, 2020 at 12:24:22AM +, Eric Wheeler wrote:
> On Mon, 15 Oct 2018, Nir Soffer wrote:
> > On Sat, Oct 13, 2018 at 9:45 PM Eric Wheeler
> > wrote:
> > Hello all,
> >
> > It might be neat to attach ISOs to KVM guests via websockets.
> > Basically
> > the
This filter deliberately tries to coalesce reads into larger requests.
Unfortunately VMware has low limits on the size of requests it can
serve to a VDDK client and the larger requests would break with errors
like this:
nbdkit: vddk[3]: error: [NFC ERROR] NfcFssrvrProcessErrorMsg: received NFC
This is the simplest solution to this problem. There are two other
possible fixes I considered:
Increase the documented limit (see
http://libguestfs.org/virt-v2v-input-vmware.1.html#vddk:-esxi-nfc-service-memory-limits).
However at the moment we know the current limit works through
extensive
Commit c3a54d6aed6dfc65f9ffa59976bb8d20044c03a8 ("v2v: Add standalone
nbdkit module.") was supposed to be a simple refactoring but it broke
the --bandwidth and --bandwidth-file options (amongst other things).
Because of an extra '=' character which was accidentally left over, it
would add an
Trivial fix.
We really need a regression test for all v2v inpus related to nbdkit.
There is actually nothing at all at the moment. Of course if it was
easy to test inputs over the network from a ‘make check’ rule then
we'd be doing it already.
I thought about adding something like a ‘-it file’
On Thursday, 28 May 2020 12:51:16 CEST Richard W.M. Jones wrote:
> Commit c3a54d6aed6dfc65f9ffa59976bb8d20044c03a8 ("v2v: Add standalone
> nbdkit module.") was supposed to be a simple refactoring but it broke
> the --bandwidth and --bandwidth-file options (amongst other things).
>
> Because of an
On Thursday, 28 May 2020 13:22:53 CEST Richard W.M. Jones wrote:
> This filter deliberately tries to coalesce reads into larger requests.
> Unfortunately VMware has low limits on the size of requests it can
> serve to a VDDK client and the larger requests would break with errors
> like this:
>
>
