similar to: Plan to fix virt-v2v Windows static IPs bug (RHBZ#1626503)

For Linux the guest itself remembers the IP address associated with each MAC address. Thus it doesn't matter if the interface type changes (ie. to virtio-net), because as long as we preserve the MAC address the guest will use the same IP address or the same DHCP configuration. However on Windows this association is not maintained by MAC address. In fact the MAC address isn't saved

For Linux the guest itself remembers the IP address associated with each MAC address. Thus it doesn't matter if the interface type changes (ie. to virtio-net), because as long as we preserve the MAC address the guest will use the same IP address or the same DHCP configuration. However on Windows this association is not maintained by MAC address. In fact the MAC address isn't saved

On Wed, Dec 05, 2018 at 12:52:21PM +0000, Roman Kagan wrote: > On Wed, Dec 05, 2018 at 11:01:43AM +0000, Richard W.M. Jones wrote: > > On Wed, Dec 05, 2018 at 09:01:16AM +0000, Roman Kagan wrote: > > > On Tue, Dec 04, 2018 at 05:29:31PM +0000, Richard W.M. Jones wrote: > > > > This patch is just for discussion. There are still a couple of issues > > > >

This patch is just for discussion. There are still a couple of issues that I'm trying to fix. One is that all of the test guests I have, even ones with static IPs, have multiple interfaces, some using DHCP, so the conditions for adding the Powershell script don't kick in. This makes testing very awkward. However a bigger issue is that I think the premise is wrong. In some registries

v1 was here with much discussion: https://www.redhat.com/archives/libguestfs/2018-December/msg00048.html v2: - Fix the case where there are multiple interfaces. Note this does not preserve order correctly (see patch for comment on why that is a hard problem). - Preserve name servers. This patch is still for discussion only. I'd like to see what might be done to get this upstream

On Wed, Dec 5, 2018 at 12:01 PM Richard W.M. Jones <rjones@redhat.com> wrote: > On Wed, Dec 05, 2018 at 09:01:16AM +0000, Roman Kagan wrote: > > On Tue, Dec 04, 2018 at 05:29:31PM +0000, Richard W.M. Jones wrote: > > > This patch is just for discussion. There are still a couple of issues > > > that I'm trying to fix. > > > > Sorry if I missed the

...adding a few thoughts around this proposal. There are times when we need to preserve the IP/MAC address(s) for VM migration for things such as: 1. Licensing tied to the IP/MAC address 2. Complex configurations such as HA clustering 3. Anytime network preservation is needed to run post configuration playbooks in some migration solutions 4. Using in OS agents to manipulate networking may not

On Wed, Dec 05, 2018 at 01:18:49PM +0100, Fabien Dupont wrote: > On Wed, Dec 5, 2018 at 12:01 PM Richard W.M. Jones <rjones@redhat.com> > wrote: > > > On Wed, Dec 05, 2018 at 09:01:16AM +0000, Roman Kagan wrote: > > > On Tue, Dec 04, 2018 at 05:29:31PM +0000, Richard W.M. Jones wrote: > > > > This patch is just for discussion. There are still a couple of

On Wed, Dec 05, 2018 at 09:01:16AM +0000, Roman Kagan wrote: > On Tue, Dec 04, 2018 at 05:29:31PM +0000, Richard W.M. Jones wrote: > > This patch is just for discussion. There are still a couple of issues > > that I'm trying to fix. > > Sorry if I missed the original discussion on that, but why is copying > the static IP configuraition even considered to be a good

On Tuesday, 16 April 2019 10:55:39 CEST Richard W.M. Jones wrote: > +(* Unfortunately Powershell scripts cannot be directly executed > + * (unless some system config changes are made which for other > + * reasons we don't want to do) and so we have to run this via > + * a regular batch file. > + *) > +let install_firstboot_powershell g { Types.i_windows_systemroot; i_root }

On Thu, Apr 13, 2017 at 11:37:31AM +0300, Roman Kagan wrote: > Appears reasonable; however, I'm afraid it's only the experiment that > can tell if it can work or not, and I don't have a setup to test this > right now. Thanks. I managed to test it now, and it does appear to fix the problem, so I pushed this commit upstream. Rich. -- Richard Jones, Virtualization Group, Red

There were two related bugs in the virt-v2v error messages when source inspection failed. Firstly it would print the message about running 'virt-v2v -v -x' twice: virt-v2v: error: inspection could not detect the source guest (or physical machine). Assuming that you are running virt-v2v/virt-p2v on a source which is supported (and not, for example, a blank disk), then this should

The new ‘-o rhv-upload’ output mode contains a '-' character in the name, but the regular expression which matched the output of the virt-v2v command did not recognize '-' as a valid character. It ended up mapping this to just "rhv" meaning two "rhv" entries would appear in the list of output drivers. Thanks: Ming Xie. --- p2v/ssh.c | 7 +++++--

On Wed, Mar 22, 2017 at 11:39:58AM +0100, Pino Toscano wrote: > On Wednesday, 22 March 2017 11:30:59 CET Richard W.M. Jones wrote: > > Thanks: Ming Xie > > --- > > It does not wrong to me, although couldn't an existing completion be > used for virt-v2v-copy-to-local as well? We might have used the 'virt-alignment-scan' one (used by all the other virt-* tools

v1 was here: https://www.redhat.com/archives/libguestfs/2018-June/msg00047.html v1 -> v2: - Add a regular expression in the virt-v2v modules code too. - - - I was planning a much more ambitious second version of this patch (half written too) which had: virt-v2v --describe-modules that listed a big chunk of XML which virt-p2v would parse. These would include the names of the

Ensure the control connection exits with the same status code as virt-v2v, and return an error from start_conversion if virt-v2v failed. --- p2v/conversion.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/p2v/conversion.c b/p2v/conversion.c index 9f5a3ad..4ff7ecc 100644 --- a/p2v/conversion.c +++ b/p2v/conversion.c @@ -100,6 +100,7 @@ start_conversion

On Wednesday, September 04, 2013 07:57:25 PM Richard W.M. Jones wrote: > I'll give you a bit of background to this (mis-)feature. The "iface" > optional argument was added so that you could use qemu's IDE interface > instead of whatever the default is (virtio-scsi, falling back to > virtio-blk). Thanks for the background. That does help fill in some holes. >

Thanks: Ming Xie --- bash/Makefile.am | 3 ++- bash/virt-v2v-copy-to-local | 42 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 44 insertions(+), 1 deletion(-) create mode 100644 bash/virt-v2v-copy-to-local diff --git a/bash/Makefile.am b/bash/Makefile.am index 94a2d48..86fd816 100644 --- a/bash/Makefile.am +++ b/bash/Makefile.am @@ -22,7 +22,8 @@ scripts = \

On Wednesday, 22 March 2017 11:30:59 CET Richard W.M. Jones wrote: > Thanks: Ming Xie > --- It does not wrong to me, although couldn't an existing completion be used for virt-v2v-copy-to-local as well? Thanks, -- Pino Toscano

On Tuesday, 12 June 2018 11:27:56 CEST Richard W.M. Jones wrote: > The new ‘-o rhv-upload’ output mode contains a '-' character in the > name, but the regular expression which matched the output of the > virt-v2v command did not recognize '-' as a valid character. It ended > up mapping this to just "rhv" meaning two "rhv" entries would appear >