similar to: Status of virt-v2v?

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 Tue, Sep 03, 2013 at 09:29:49AM -0600, Mike Latimer wrote: > Hi, I'll make some advisory comments, but you really need to talk to Matt Booth (CC'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?

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. > guestconv will only

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

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

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

Hi Pino, On 2/26/19 5:52 PM, Mike Latimer wrote: > On 2/21/19 3:07 AM, Pino Toscano wrote: >> My question is: is using cirrus still the best choice for SUSE guests? >> If not, what about using qxl as well, as done for any non-SUSE guest? >> (We can also do that depending on the version of the guest, in case >> only newer SUSE versions work fine with qxl). > At the

The iface:ide parameter (used in the libguestfs add_drive call) does not work with a libvirt backend. The error usually seen is: 'iface' parameter is not supported by the libvirt attach-method at /usr/share/perl5/vendor_perl/Sys/VirtConvert/GuestfsHandle.pm line 96. This issue was previously mentioned in this thread:

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

Hi Mike, in 2013 you added the support for SUSE guests in the old virt-v2v (the one written in Perl); the commit doing it is attached, since the old virt-v2v was hosted on fedorahosted.org, which is no more. As part of that change, the default graphics driver was changed to be cirrus for SUSE guests, and qxl (as before) for any other. When Rich Jones rewrote virt-v2v in 2014 in OCaml, he kept

--- v2v/virt-v2v.pod | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index 4c7204b..ba91851 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -227,6 +227,10 @@ And hence L<virsh(1)>, L<virt-manager(1)>, and similar tools. =item OpenSUSE 10 and up +=item Debian 6 and up + +=item Ubuntu 10.04, 12.04, 14.04, 16.04,

In some cases (specifically, SUSE grub2 environments) it is possible to fail to update the block entries in device.map. In turn, this causes an invalid path to be returned in perl-Bootloader code, which causes the conversion to fail with the following message: is_file_opts: is_file: is_file_stub: path must start with a / character This patch prevents the problem by adding device.map (for

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

The following series of patches adds support for converting SUSE guests through virt-v2v. These changes should not impact non-SUSE guest conversions. Mike Latimer (4): Add perl-Bootloader support to grub packages Add conversion support for SUSE guests Add SUSE to capabilities db and conf Add SUSE support documentation lib/Sys/VirtConvert/Converter/Linux.pm | 480

--- lib/Sys/VirtConvert/Converter/Windows.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Sys/VirtConvert/Converter/Windows.pm b/lib/Sys/VirtConvert/Converter/Windows.pm index 765ed9f..59d273f 100644 --- a/lib/Sys/VirtConvert/Converter/Windows.pm +++ b/lib/Sys/VirtConvert/Converter/Windows.pm @@ -338,7 +338,7 @@ sub _prepare_virtio_drivers

Although not fatal, _unconfigure_xenpv should report a warning and return if firstboot is not available (during Windows conversions). --- lib/Sys/VirtConvert/Converter/Windows.pm | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/lib/Sys/VirtConvert/Converter/Windows.pm b/lib/Sys/VirtConvert/Converter/Windows.pm index 59d273f..ce8b474 100644 --- a/lib/Sys/VirtConvert/Converter/Windows.pm

In preparation for an upcoming patch which adds support for SUSE guest conversions, it makes sense to have an intermediate steps that changes the RedHat.pm converter into a more generic Linux converter. The SUSE changes will then be limited in scope to only what is required for SUSE support. This series of patches accomplishes the following: - Renames RedHat.pm to Linux.pm - Modifies Linux.pm

Hi All, As the in-place help said, --in-place Do not create an output virtual machine in the target hypervisor. Instead, adjust the guest OS in the source VM to run in the input hypervisor. This mode is meant for integration with other toolsets, which take the responsibility of converting the VM configuration, providing for rollback in case of errors, transforming the storage, etc. I want

As a followup to the discussion on verbose logging for virt-v2v, this patch adds basic verbose messages in the main virt-v2v code. As Matt pointed out, the usefulness of these messages is limited as the time spent outside of data copying is trivial. However, when converting smaller guests, these messages can act as progress markers and show where time is being spent. (As I already added this code

I need to p2v migrate a Windows server and I am soooo confused! By now, I've done a few virt-v2v migrations, so I get how that works. I attended Richard and Matthew's Red Hat Summit talk about virt-p2v and just now downloaded the handouts. If I understand what's going on, virt-p2v is pretty much the same as virt-v2v, except that the physical system to migrate from needs to boot