FYI I'm some way through splitting virt-v2v out, although as is always
the case this turned out to be a lot more complicated than I thought
it was going to be. Turns out that our common/ subdirectory has quite
a lot of circular dependencies ...
Rich.
--
Richard Jones, Virtualization Group, Re
On Tue, Oct 15, 2019 at 06:26:23PM +0100, Richard W.M. Jones wrote:
On Tue, Oct 15, 2019 at 04:53:03PM +, Roman Kagan wrote:
On Fri, Oct 11, 2019 at 01:29:53PM +0100, Richard W.M. Jones wrote:
> Stepping back I think the problem is we're shoehorning features into a
> tool (virt-v2v) which wa
On Tue, Oct 15, 2019 at 04:53:03PM +, Roman Kagan wrote:
> On Fri, Oct 11, 2019 at 01:29:53PM +0100, Richard W.M. Jones wrote:
> > Stepping back I think the problem is we're shoehorning features into a
> > tool (virt-v2v) which was designed to do cold conversions, and was
> > never meant to do
On Fri, Oct 11, 2019 at 01:29:53PM +0100, Richard W.M. Jones wrote:
> Stepping back I think the problem is we're shoehorning features into a
> tool (virt-v2v) which was designed to do cold conversions, and was
> never meant to do either warm or in-place conversions. The tool was
> hacked a while b
On Fri, Oct 11, 2019 at 01:29:53PM +0100, Richard W.M. Jones wrote:
> However there are some action items:
>
> (1) do_convert does not need the source parameter. I think it could
> just be passed the .s_name field instead.
>
> (2) output#prepare_targets doesn't really need the source struct, but
On Fri, Oct 11, 2019 at 03:48:43PM +0100, Richard W.M. Jones wrote:
On Fri, Oct 11, 2019 at 04:17:44PM +0200, Martin Kletzander wrote:
On Fri, Oct 11, 2019 at 01:29:53PM +0100, Richard W.M. Jones wrote:
>What would a tool which reused virt-v2v code and did what we really
>want look like? The ba
On Fri, Oct 11, 2019 at 04:17:44PM +0200, Martin Kletzander wrote:
> On Fri, Oct 11, 2019 at 01:29:53PM +0100, Richard W.M. Jones wrote:
> >What would a tool which reused virt-v2v code and did what we really
> >want look like? The basic flow of objects in existing v2v/v2v.ml is:
>
> Ideally there
On Fri, Oct 11, 2019 at 01:29:53PM +0100, Richard W.M. Jones wrote:
Thanks for explaining how this was going to work on IRC.
Stepping back I think the problem is we're shoehorning features into a
tool (virt-v2v) which was designed to do cold conversions, and was
never meant to do either warm or
Thanks for explaining how this was going to work on IRC.
Stepping back I think the problem is we're shoehorning features into a
tool (virt-v2v) which was designed to do cold conversions, and was
never meant to do either warm or in-place conversions. The tool was
hacked a while back for in-place b
On Fri, Oct 11, 2019 at 09:37:18AM +0200, Martin Kletzander wrote:
On Thu, Oct 10, 2019 at 03:33:25PM +0100, Richard W.M. Jones wrote:
On Wed, Oct 09, 2019 at 02:19:46PM +0200, Martin Kletzander wrote:
Even though this option is not to be used according to the manual, it:
a) still might be us
On Thu, Oct 10, 2019 at 03:33:25PM +0100, Richard W.M. Jones wrote:
On Wed, Oct 09, 2019 at 02:19:46PM +0200, Martin Kletzander wrote:
Even though this option is not to be used according to the manual, it:
a) still might be useful even for machine-readable logs
b) should not break the machin
On Wed, Oct 09, 2019 at 02:19:46PM +0200, Martin Kletzander wrote:
> Even though this option is not to be used according to the manual, it:
>
> a) still might be useful even for machine-readable logs
>
> b) should not break the machine-readable output
I'm a bit confused what you're trying to d
On Wed, Oct 09, 2019 at 02:19:46PM +0200, Martin Kletzander wrote:
Even though this option is not to be used according to the manual, it:
a) still might be useful even for machine-readable logs
b) should not break the machine-readable output
I should've mentioned "which it currently does if
13 matches
Mail list logo
