search for: guestconv

guestconv will be a new, re-usable library to perform guest OS conversions when moving between hypervisors. I've attached 3 files to this email which are relevant to the proposed API. guestconv.h is the proposed C binding. example.c is the simplest possible usage of the API. It converts the first dete...

On Tuesday, September 03, 2013 07:52:08 PM Richard W.M. Jones wrote: > Even better, there is a repo: https://github.com/mdbooth/guestconv Excellent. Thanks for the pointer. > Matt - can you push your latest commits, or is there a more canonical > repo that Mike can look at? The last changes in the repo seem to be from back in June. Is guestconv expected to completely replace virt-v2v in RHEL7? > > I've got a coup...

I've added internationalisation to guestconv, and updated HACKING with a new section. Any thoughts/comments? Matt

On Tue, 2013-09-03 at 17:10 -0600, Mike Latimer wrote: > On Tuesday, September 03, 2013 07:52:08 PM Richard W.M. Jones wrote: > > Even better, there is a repo: https://github.com/mdbooth/guestconv > > Excellent. Thanks for the pointer. > > > Matt - can you push your latest commits, or is there a more canonical > > repo that Mike can look at? > > The last changes in the repo seem to be from back in June. Is guestconv > expected to completely replace virt-v2v...

On Thursday, September 05, 2013 12:00:44 PM Matthew Booth wrote: > guestconv is not intended to completely replace virt-v2v. Broadly > speaking, virt-v2v does 2 things: > > 1. Move guests between 2 hypervisors. > 2. Make changes to the guest required for a new hypervisor. > > The second is unique to virt-v2v, the first has other tools out there. > gue...

Per conversation last week with Rich and Matt, while we want to have a Guestconv C API which is relatively easy to bind to across different languages, for the sake of expediency we want to the do the actual work in Python. The idea is that the C API will spawn a python process when guestconv_create is called and ultimately be responsible for terminating the process. Commu...

Hi, I have recently been looking into virt-v2v, and noticed the mention of an upcoming rewrite in a few places. Is there a roadmap or post someplace that describes the future of this project? I've got a couple of patches against the current code base, and am wondering if they will still be considered for inclusion. Thanks, Mike

On Thu, 2013-09-05 at 09:31 -0600, Mike Latimer wrote: > On Thursday, September 05, 2013 12:00:44 PM Matthew Booth wrote: > > guestconv is not intended to completely replace virt-v2v. Broadly > > speaking, virt-v2v does 2 things: > > > > 1. Move guests between 2 hypervisors. > > 2. Make changes to the guest required for a new hypervisor. > > > > The second is unique to virt-v2v, the first has o...

...C'd - or mdbooth on #libguestfs). > I have recently been looking into virt-v2v, and noticed the mention > of an upcoming rewrite in a few places. Is there a roadmap or post > someplace that describes the future of this project? Even better, there is a repo: https://github.com/mdbooth/guestconv Matt - can you push your latest commits, or is there a more canonical repo that Mike can look at? > I've got a couple of patches against the current code base, and am > wondering if they will still be considered for inclusion. Yes, for virt-v2v (or guestconv if you want too). Post patc...

...thew Booth wrote: > Mike, > > This is great. I have a couple of minor comments inline, but this looks > good. > > I do have a major concern, though, which is this is basically a fork of > RedHat.pm. I thought your concern would be that you'd want similar functionality in guestconv. Will this SuSE code need to be rewritten for guestconv? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

Mike, This is great. I have a couple of minor comments inline, but this looks good. I do have a major concern, though, which is this is basically a fork of RedHat.pm. There are well over 1,000 identical lines of code between the 2 modules. Many of the differences are relatively minor, and could be handled with additional cases. I've also fixed a couple of bits in RedHat.pm since you forked

On Tue, Sep 03, 2013 at 11:30:07PM -0600, Mike Latimer wrote: > On Tuesday, September 03, 2013 06:09:26 PM Mike Latimer wrote: > > However, as mentioned in the bug, this parameter is likely no longer > > required. Unless there is a use-case where this setting is required, it > > seems like a good idea to remove it completely (which should work in > > either libvirt or

[Continuing a discussion we had on IRC last week ...] How to create meaningful regression tests for the inspection code? We'd like developers to be able to test that changes to the inspection code don't break inspection of existing guests. We might not be able to run these tests routinely, and we might have to accept that they have to download hundreds of megabytes of test data. Idea

...t; This has no effect (only limitations) for ordinary libguestfs users, > but for virt-v2v it allows us to run the 'mkinitrd' command in the > guest and have it work for very old and buggy mkinitrd / guests that > got confused by virtio. I think it was for RHEL 4 ... Will the new guestconv still support older (i.e. RHEL 4) environments? > What it does do is cause endless problems, mainly because people want > to use virt-v2v with more disks than IDE allows (just 2, once you take > into account the transfer disk and the libguestfs appliance). What about performance differen...

...t ~50-100MB to host + > distribute per test case, and we'd ideally want >20 test cases so > that's still multiple gigabytes of test data. > > I've attached the program to this email in case anyone wants to look > at this further. > > > Any other ideas ...? guestconv builds several RHEL and Fedora based images for automated testing. The build process is separate from the test process, and tests are skipped if their image hasn't been built. It's very flexible, and works for guests we can build automatically. Matt

...> SUSE.pm which is relevant to RedHat.pm. Yes - I inherited this task from another engineer who started down this road. The majority of the code is identical to RedHat, but it seemed to be quicker to go this route than completely change things around (especially since the future seems to be guestconv). > I don't think I could accept this as-is purely from a maintenance POV. > Could you have a look through and see what it would take to re-use code > currently in RedHat.pm? This might be: > > * Renaming it, and handling SUSE as additional cases > * Pulling common code into...