5:35 a.m.
Remove ties to MAC address because it is likely to change.
The code is based on operations net-hwaddr and udev-persistent-net of
virt-sysprep.
Signed-off-by: Tomáš Golembiovský <tgolembi(a)redhat.com>
---
v2v/convert_linux.ml | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/v2v/convert_linux.ml b/v2v/convert_linux.ml
index b273785e6..8bba74786 100644
--- a/v2v/convert_linux.ml
+++ b/v2v/convert_linux.ml
@@ -88,6 +88,8 @@ let convert (g : G.guestfs) inspect source output rcaps =
unconfigure_kudzu ();
unconfigure_prltools ();
+ sysprep_networking();
+
let kernel = configure_kernel () in
if output#keep_serial_console then (
@@ -452,6 +454,21 @@ let convert (g : G.guestfs) inspect source output rcaps =
msg
)
+ and sysprep_networking () =
+ if family = `RHEL_family then
+ (* Remove HWADDR=... entries from ifcfg-* files. *)
+ let paths = g#aug_match
+ "/files/etc/sysconfig/network-scripts/*[label() =~
glob('ifcfg-*')]/HWADDR" in
+ let paths = Array.to_list paths in
+ if paths <> [] then (
+ List.iter (fun path -> ignore (g#aug_rm path)) paths;
+ g#aug_save ()
+ );
+ (* Remove persistent udev rules. *)
+ try g#rm "/etc/udev/rules.d/70-persistent-net.rules"
+ with G.Error _ -> ()
+
+
and configure_kernel () =
(* Previously this function would try to install kernels, but we
* don't do that any longer.
--
2.16.1
5:47 a.m.
On Tue, Feb 27, 2018 at 12:35:36PM +0100, Tomáš Golembiovský wrote:
Remove ties to MAC address because it is likely to change.
The code is based on operations net-hwaddr and udev-persistent-net of
virt-sysprep.
Signed-off-by: Tomáš Golembiovský <tgolembi(a)redhat.com>
---
v2v/convert_linux.ml | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/v2v/convert_linux.ml b/v2v/convert_linux.ml
index b273785e6..8bba74786 100644
--- a/v2v/convert_linux.ml
+++ b/v2v/convert_linux.ml
@@ -88,6 +88,8 @@ let convert (g : G.guestfs) inspect source output rcaps =
unconfigure_kudzu ();
unconfigure_prltools ();
+ sysprep_networking();
The function name is a bit obscure. How about this?
remove_network_ifcfg_hwaddr_entries ();
Also needs a space between the function name and the parentheses.
let kernel = configure_kernel () in
if output#keep_serial_console then (
@@ -452,6 +454,21 @@ let convert (g : G.guestfs) inspect source output rcaps =
msg
)
+ and sysprep_networking () =
+ if family = `RHEL_family then
+ (* Remove HWADDR=... entries from ifcfg-* files. *)
+ let paths = g#aug_match
+ "/files/etc/sysconfig/network-scripts/*[label() =~
glob('ifcfg-*')]/HWADDR" in
+ let paths = Array.to_list paths in
+ if paths <> [] then (
+ List.iter (fun path -> ignore (g#aug_rm path)) paths;
It doesn't really matter but I think you could write this as:
List.iter (g#aug_rm |> ignore) paths;
but your version may be clearer.
+ g#aug_save ()
+ );
+ (* Remove persistent udev rules. *)
+ try g#rm "/etc/udev/rules.d/70-persistent-net.rules"
+ with G.Error _ -> ()
Rather than throwing away the error it's better to use 'g#rm_f' and
don't try to catch G.Error at all. I guess the same problem exists in
virt-sysprep.
Is this a fix for any particular bug? If so it needs to have
‘(RHBZ#xxxxxx)’ added to the end of the commit heading.
Patch looks OK otherwise.
Rich.
+
+
and configure_kernel () =
(* Previously this function would try to install kernels, but we
* don't do that any longer.
--
2.16.1
_______________________________________________
Libguestfs mailing list
Libguestfs(a)redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
6:08 a.m.
On Tue, 27 Feb 2018 11:47:38 +0000
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
On Tue, Feb 27, 2018 at 12:35:36PM +0100, Tomáš Golembiovský wrote:
> Remove ties to MAC address because it is likely to change.
>
> The code is based on operations net-hwaddr and udev-persistent-net of
> virt-sysprep.
>
> Signed-off-by: Tomáš Golembiovský <tgolembi(a)redhat.com>
> ---
> v2v/convert_linux.ml | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/v2v/convert_linux.ml b/v2v/convert_linux.ml
> index b273785e6..8bba74786 100644
> --- a/v2v/convert_linux.ml
> +++ b/v2v/convert_linux.ml
> @@ -88,6 +88,8 @@ let convert (g : G.guestfs) inspect source output rcaps =
> unconfigure_kudzu ();
> unconfigure_prltools ();
>
> + sysprep_networking();
The function name is a bit obscure. How about this?
remove_network_ifcfg_hwaddr_entries ();
Maybe too long to my taste, but sure, why not.
Also needs a space between the function name and the parentheses.
> let kernel = configure_kernel () in
>
> if output#keep_serial_console then (
> @@ -452,6 +454,21 @@ let convert (g : G.guestfs) inspect source output rcaps =
> msg
> )
>
> + and sysprep_networking () =
> + if family = `RHEL_family then
> + (* Remove HWADDR=... entries from ifcfg-* files. *)
> + let paths = g#aug_match
> + "/files/etc/sysconfig/network-scripts/*[label() =~
glob('ifcfg-*')]/HWADDR" in
> + let paths = Array.to_list paths in
> + if paths <> [] then (
> + List.iter (fun path -> ignore (g#aug_rm path)) paths;
It doesn't really matter but I think you could write this as:
List.iter (g#aug_rm |> ignore) paths;
Ah, right. The magical |> operator... I keep forgetting about it.
but your version may be clearer.
Agreed. I'll leave it as is then.
> + g#aug_save ()
> + );
> + (* Remove persistent udev rules. *)
> + try g#rm "/etc/udev/rules.d/70-persistent-net.rules"
> + with G.Error _ -> ()
Rather than throwing away the error it's better to use 'g#rm_f' and
don't try to catch G.Error at all. I guess the same problem exists in
virt-sysprep.
Is this a fix for any particular bug? If so it needs to have
‘(RHBZ#xxxxxx)’ added to the end of the commit heading.
Not yet, but thanks for reminding me. I'll create a bug and add it to
the heading.
Patch looks OK otherwise.
Rich.
> +
> +
> and configure_kernel () =
> (* Previously this function would try to install kernels, but we
> * don't do that any longer.
> --
> 2.16.1
>
> _______________________________________________
> Libguestfs mailing list
> Libguestfs(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
Tomáš Golembiovský <tgolembi(a)redhat.com>
6:40 a.m.
On Tue, Feb 27, 2018 at 01:08:40PM +0100, Tomáš Golembiovský wrote:
> List.iter (g#aug_rm |> ignore) paths;
Ah, right. The magical |> operator... I keep forgetting about it.
Best way to think of it is that it's a pipeline that threads the
argument through each function in turn.
(f1 |> f2 |> f3 |> ...) arg
is the same as
f3 (f2 (f1 arg))
F# calls it "pipe forward" and they also have a "pipe backward"
operator (I just found out now).
http://theburningmonk.com/2011/09/fsharp-pipe-forward-and-pipe-backward/
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
5:53 a.m.
On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
Remove ties to MAC address because it is likely to change.
v2v tries to preserve the MAC address of network interfaces; few months
ago we did a fix regarding this:
https://bugzilla.redhat.com/show_bug.cgi?id=1506572
The approach of this patch is IMHO not good, since it removes the MAC
address from the network-scripts, but still the rest of v2v will try
to preserve the MAC addresses.
What's the reason behind this patch?
--
Pino Toscano
6:34 a.m.
On Tue, Feb 27, 2018 at 12:53:08PM +0100, Pino Toscano wrote:
On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
> Remove ties to MAC address because it is likely to change.
v2v tries to preserve the MAC address of network interfaces; few months
ago we did a fix regarding this:
https://bugzilla.redhat.com/show_bug.cgi?id=1506572
The approach of this patch is IMHO not good, since it removes the MAC
address from the network-scripts, but still the rest of v2v will try
to preserve the MAC addresses.
We preserve the MAC address in metadata. On the other hand AIUI this
patch only removes the association in the ifcfg files and the guest
will reassociate it when it boots (albeit it might then mix up the
ethernet interfaces so that's not good).
There's IMHO a bigger problem which is not being addressed:
https://bugzilla.redhat.com/show_bug.cgi?id=1318922
What's the reason behind this patch?
There's a bit of background which is missing. Tomáš and I had some
discussions (privately, unfortunately) with the ManageIQ developers
who are integrating virt-v2v into MIQ/CloudForms. Their existing
software runs a separate virt-sysprep step on guests after they have
been converted by virt-v2v. They disable all sysprep the operations
except for just a couple, including ‘net-hwaddr’, so the effect is
roughly the same as this patch.
The question was raised why they need to do that as a separate step
and why virt-v2v doesn't do it. And indeed there was some discussion
about whether or not converted guests need a new MAC address -- it's
at best unclear -- it is thought that VMware might reuse MAC addresses
which have "left" the hypervisor, although no one knows if that's
really true or not.
I don't have much opinion on this. Maybe it's best for CFME to
continue to run virt-sysprep as a separate step.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
6:43 a.m.
Running sysprep is quite easy today because we use the export domain, which
is frequently NFS. So we simply mount it on the conversion host and run
sysprep against the disks of the converted VM before it is imported.
Soon, we want to skip the export domain, so the disks of the VM will be in
a separate domain. We can still find them and run the sysprep, but I have
the feeling that it would be more logical if virt-v2v did the sysprep when
target is oVirt / RHV.
On 27 February 2018 at 13:34, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Tue, Feb 27, 2018 at 12:53:08PM +0100, Pino Toscano wrote:
> On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
> > Remove ties to MAC address because it is likely to change.
>
> v2v tries to preserve the MAC address of network interfaces; few months
> ago we did a fix regarding this:
> https://bugzilla.redhat.com/show_bug.cgi?id=1506572
>
> The approach of this patch is IMHO not good, since it removes the MAC
> address from the network-scripts, but still the rest of v2v will try
> to preserve the MAC addresses.
We preserve the MAC address in metadata. On the other hand AIUI this
patch only removes the association in the ifcfg files and the guest
will reassociate it when it boots (albeit it might then mix up the
ethernet interfaces so that's not good).
There's IMHO a bigger problem which is not being addressed:
https://bugzilla.redhat.com/show_bug.cgi?id=1318922
> What's the reason behind this patch?
There's a bit of background which is missing. Tomáš and I had some
discussions (privately, unfortunately) with the ManageIQ developers
who are integrating virt-v2v into MIQ/CloudForms. Their existing
software runs a separate virt-sysprep step on guests after they have
been converted by virt-v2v. They disable all sysprep the operations
except for just a couple, including ‘net-hwaddr’, so the effect is
roughly the same as this patch.
The question was raised why they need to do that as a separate step
and why virt-v2v doesn't do it. And indeed there was some discussion
about whether or not converted guests need a new MAC address -- it's
at best unclear -- it is thought that VMware might reuse MAC addresses
which have "left" the hypervisor, although no one knows if that's
really true or not.
I don't have much opinion on this. Maybe it's best for CFME to
continue to run virt-sysprep as a separate step.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~
rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
--
*Fabien Dupont*
PRINCIPAL SOFTWARE ENGINEER
Red Hat - Solutions Engineering
fabien(a)redhat.com M: +33 (0) 662 784 971 <+33662784971>
<http://redhat.com> *TRIED. TESTED. TRUSTED.*
Twitter: @redhatway <https://twitter.com/redhatway> | Instagram: @redhatinc
<https://www.instagram.com/redhatinc/> | Snapchat: @redhatsnaps
6:53 a.m.
On Tue, 27 Feb 2018 13:43:59 +0100
Fabien Dupont <fdupont(a)redhat.com> wrote:
We can still find them and run the sysprep, but I have
the feeling that it would be more logical if virt-v2v did the sysprep when
target is oVirt / RHV.
This is trickier than you think. For LVM volumes somebody (VDSM) has to
lock and prepare the disks for you first and there is no external API to
do that AFAIK.
Tomas
On 27 February 2018 at 13:34, Richard W.M. Jones <rjones(a)redhat.com> wrote:
> On Tue, Feb 27, 2018 at 12:53:08PM +0100, Pino Toscano wrote:
> > On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
> > > Remove ties to MAC address because it is likely to change.
> >
> > v2v tries to preserve the MAC address of network interfaces; few months
> > ago we did a fix regarding this:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1506572
> >
> > The approach of this patch is IMHO not good, since it removes the MAC
> > address from the network-scripts, but still the rest of v2v will try
> > to preserve the MAC addresses.
>
> We preserve the MAC address in metadata. On the other hand AIUI this
> patch only removes the association in the ifcfg files and the guest
> will reassociate it when it boots (albeit it might then mix up the
> ethernet interfaces so that's not good).
>
> There's IMHO a bigger problem which is not being addressed:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1318922
>
> > What's the reason behind this patch?
>
> There's a bit of background which is missing. Tomáš and I had some
> discussions (privately, unfortunately) with the ManageIQ developers
> who are integrating virt-v2v into MIQ/CloudForms. Their existing
> software runs a separate virt-sysprep step on guests after they have
> been converted by virt-v2v. They disable all sysprep the operations
> except for just a couple, including ‘net-hwaddr’, so the effect is
> roughly the same as this patch.
>
> The question was raised why they need to do that as a separate step
> and why virt-v2v doesn't do it. And indeed there was some discussion
> about whether or not converted guests need a new MAC address -- it's
> at best unclear -- it is thought that VMware might reuse MAC addresses
> which have "left" the hypervisor, although no one knows if that's
> really true or not.
>
> I don't have much opinion on this. Maybe it's best for CFME to
> continue to run virt-sysprep as a separate step.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~
> rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> libguestfs lets you edit virtual machines. Supports shell scripting,
> bindings from many languages. http://libguestfs.org
>
--
*Fabien Dupont*
PRINCIPAL SOFTWARE ENGINEER
Red Hat - Solutions Engineering
fabien(a)redhat.com M: +33 (0) 662 784 971 <+33662784971>
<http://redhat.com> *TRIED. TESTED. TRUSTED.*
Twitter: @redhatway <https://twitter.com/redhatway> | Instagram: @redhatinc
<https://www.instagram.com/redhatinc/> | Snapchat: @redhatsnaps
--
Tomáš Golembiovský <tgolembi(a)redhat.com>
6:58 a.m.
In this case, shouldn't that be done by the upload-disk API ? When you
upload a VM, oVirt knows what to do with it and handle the locking and any
operations required to make the VM an oVirt VM.
On 27 February 2018 at 13:53, Tomáš Golembiovský <tgolembi(a)redhat.com>
wrote:
On Tue, 27 Feb 2018 13:43:59 +0100
Fabien Dupont <fdupont(a)redhat.com> wrote:
> We can still find them and run the sysprep, but I have
> the feeling that it would be more logical if virt-v2v did the sysprep
when
> target is oVirt / RHV.
This is trickier than you think. For LVM volumes somebody (VDSM) has to
lock and prepare the disks for you first and there is no external API to
do that AFAIK.
Tomas
>
> On 27 February 2018 at 13:34, Richard W.M. Jones <rjones(a)redhat.com>
wrote:
>
> > On Tue, Feb 27, 2018 at 12:53:08PM +0100, Pino Toscano wrote:
> > > On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
> > > > Remove ties to MAC address because it is likely to change.
> > >
> > > v2v tries to preserve the MAC address of network interfaces; few
months
> > > ago we did a fix regarding this:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1506572
> > >
> > > The approach of this patch is IMHO not good, since it removes the MAC
> > > address from the network-scripts, but still the rest of v2v will try
> > > to preserve the MAC addresses.
> >
> > We preserve the MAC address in metadata. On the other hand AIUI this
> > patch only removes the association in the ifcfg files and the guest
> > will reassociate it when it boots (albeit it might then mix up the
> > ethernet interfaces so that's not good).
> >
> > There's IMHO a bigger problem which is not being addressed:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1318922
> >
> > > What's the reason behind this patch?
> >
> > There's a bit of background which is missing. Tomáš and I had some
> > discussions (privately, unfortunately) with the ManageIQ developers
> > who are integrating virt-v2v into MIQ/CloudForms. Their existing
> > software runs a separate virt-sysprep step on guests after they have
> > been converted by virt-v2v. They disable all sysprep the operations
> > except for just a couple, including ‘net-hwaddr’, so the effect is
> > roughly the same as this patch.
> >
> > The question was raised why they need to do that as a separate step
> > and why virt-v2v doesn't do it. And indeed there was some discussion
> > about whether or not converted guests need a new MAC address -- it's
> > at best unclear -- it is thought that VMware might reuse MAC addresses
> > which have "left" the hypervisor, although no one knows if
that's
> > really true or not.
> >
> > I don't have much opinion on this. Maybe it's best for CFME to
> > continue to run virt-sysprep as a separate step.
> >
> > Rich.
> >
> > --
> > Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~
> > rjones
> > Read my programming and virtualization blog: http://rwmj.wordpress.com
> > libguestfs lets you edit virtual machines. Supports shell scripting,
> > bindings from many languages. http://libguestfs.org
> >
>
>
>
> --
>
> *Fabien Dupont*
>
> PRINCIPAL SOFTWARE ENGINEER
>
> Red Hat - Solutions Engineering
>
> fabien(a)redhat.com M: +33 (0) 662 784 971 <+33662784971>
>
> <http://redhat.com> *TRIED. TESTED. TRUSTED.*
>
> Twitter: @redhatway <https://twitter.com/redhatway> | Instagram:
@redhatinc
> <https://www.instagram.com/redhatinc/> | Snapchat: @redhatsnaps
--
Tomáš Golembiovský <tgolembi(a)redhat.com>
--
*Fabien Dupont*
PRINCIPAL SOFTWARE ENGINEER
Red Hat - Solutions Engineering
fabien(a)redhat.com M: +33 (0) 662 784 971 <+33662784971>
<http://redhat.com> *TRIED. TESTED. TRUSTED.*
Twitter: @redhatway <https://twitter.com/redhatway> | Instagram: @redhatinc
<https://www.instagram.com/redhatinc/> | Snapchat: @redhatsnaps
9:49 a.m.
On 27 Feb 2018, at 13:58, Fabien Dupont <fdupont(a)redhat.com>
wrote:
In this case, shouldn't that be done by the upload-disk API ? When you upload a VM,
oVirt knows what to do with it and handle the locking and any operations required to make
the VM an oVirt VM.
upload API is uploading individual disks, for the duration of the upload they are locked
there is no public API to explicitly lock/unlock them
“uploading VM” is a different API concerning only the VM definition (using the virt-v2v’s
resulting OVF, internally connecting the pre-uploaded disks to taht VM)
it’s would probably good enough to go without locking for starts, but it’s just better to
avoid that completely and have an option for MAC cleanup during virt-v2v. And leave other
post conversion changes to a separate script (further editing the VM using public API)
On 27 February 2018 at 13:53, Tomáš Golembiovský <tgolembi(a)redhat.com
<mailto:tgolembi@redhat.com>> wrote:
On Tue, 27 Feb 2018 13:43:59 +0100
Fabien Dupont <fdupont(a)redhat.com <mailto:fdupont@redhat.com>> wrote:
> We can still find them and run the sysprep, but I have
> the feeling that it would be more logical if virt-v2v did the sysprep when
> target is oVirt / RHV.
This is trickier than you think. For LVM volumes somebody (VDSM) has to
lock and prepare the disks for you first and there is no external API to
do that AFAIK.
Tomas
>
> On 27 February 2018 at 13:34, Richard W.M. Jones <rjones(a)redhat.com
<mailto:rjones@redhat.com>> wrote:
>
> > On Tue, Feb 27, 2018 at 12:53:08PM +0100, Pino Toscano wrote:
> > > On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
> > > > Remove ties to MAC address because it is likely to change.
> > >
> > > v2v tries to preserve the MAC address of network interfaces; few months
> > > ago we did a fix regarding this:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1506572
<https://bugzilla.redhat.com/show_bug.cgi?id=1506572>
> > >
> > > The approach of this patch is IMHO not good, since it removes the MAC
> > > address from the network-scripts, but still the rest of v2v will try
> > > to preserve the MAC addresses.
> >
> > We preserve the MAC address in metadata. On the other hand AIUI this
> > patch only removes the association in the ifcfg files and the guest
> > will reassociate it when it boots (albeit it might then mix up the
> > ethernet interfaces so that's not good).
> >
> > There's IMHO a bigger problem which is not being addressed:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1318922
<https://bugzilla.redhat.com/show_bug.cgi?id=1318922>
> >
> > > What's the reason behind this patch?
> >
> > There's a bit of background which is missing. Tomáš and I had some
> > discussions (privately, unfortunately) with the ManageIQ developers
> > who are integrating virt-v2v into MIQ/CloudForms. Their existing
> > software runs a separate virt-sysprep step on guests after they have
> > been converted by virt-v2v. They disable all sysprep the operations
> > except for just a couple, including ‘net-hwaddr’, so the effect is
> > roughly the same as this patch.
> >
> > The question was raised why they need to do that as a separate step
> > and why virt-v2v doesn't do it. And indeed there was some discussion
> > about whether or not converted guests need a new MAC address -- it's
> > at best unclear -- it is thought that VMware might reuse MAC addresses
> > which have "left" the hypervisor, although no one knows if
that's
> > really true or not.
> >
> > I don't have much opinion on this. Maybe it's best for CFME to
> > continue to run virt-sysprep as a separate step.
> >
> > Rich.
> >
> > --
> > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~
<http://people.redhat.com/~>
> > rjones
> > Read my programming and virtualization blog: http://rwmj.wordpress.com
<http://rwmj.wordpress.com/>
> > libguestfs lets you edit virtual machines. Supports shell scripting,
> > bindings from many languages. http://libguestfs.org
<http://libguestfs.org/>
> >
>
>
>
> --
>
> *Fabien Dupont*
>
> PRINCIPAL SOFTWARE ENGINEER
>
> Red Hat - Solutions Engineering
>
> fabien(a)redhat.com <mailto:fabien@redhat.com> M: +33 (0) 662 784 971
<tel:%2B33%20%280%29%20662%20784%20971> <+33662784971
<tel:%2B33662784971>>
>
> <http://redhat.com <http://redhat.com/>> *TRIED. TESTED. TRUSTED.*
>
> Twitter: @redhatway <https://twitter.com/redhatway
<https://twitter.com/redhatway>> | Instagram: @redhatinc
> <https://www.instagram.com/redhatinc/
<https://www.instagram.com/redhatinc/>> | Snapchat: @redhatsnaps
--
Tomáš Golembiovský <tgolembi(a)redhat.com <mailto:tgolembi@redhat.com>>
--
Fabien Dupont
PRINCIPAL SOFTWARE ENGINEER
Red Hat - Solutions Engineering
fabien(a)redhat.com <mailto:fabien@redhat.com> M: +33 (0) 662 784 971
<tel:+33662784971>
<http://redhat.com/> TRIED. TESTED. TRUSTED.
Twitter: @redhatway <https://twitter.com/redhatway> | Instagram: @redhatinc
<https://www.instagram.com/redhatinc/> | Snapchat: @redhatsnaps
7:01 a.m.
On Tuesday, 27 February 2018 13:34:09 CET Richard W.M. Jones wrote:
On Tue, Feb 27, 2018 at 12:53:08PM +0100, Pino Toscano wrote:
> On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
> > Remove ties to MAC address because it is likely to change.
>
> v2v tries to preserve the MAC address of network interfaces; few months
> ago we did a fix regarding this:
> https://bugzilla.redhat.com/show_bug.cgi?id=1506572
>
> The approach of this patch is IMHO not good, since it removes the MAC
> address from the network-scripts, but still the rest of v2v will try
> to preserve the MAC addresses.
We preserve the MAC address in metadata. On the other hand AIUI this
patch only removes the association in the ifcfg files and the guest
will reassociate it when it boots (albeit it might then mix up the
ethernet interfaces so that's not good).
Yes, this is my concern, i.e. that the guest network configuration
might break.
There's IMHO a bigger problem which is not being addressed:
https://bugzilla.redhat.com/show_bug.cgi?id=1318922
Possibly there could be also
https://bugzilla.redhat.com/show_bug.cgi?id=1451597
> What's the reason behind this patch?
There's a bit of background which is missing. Tomáš and I had some
discussions (privately, unfortunately) with the ManageIQ developers
who are integrating virt-v2v into MIQ/CloudForms. Their existing
software runs a separate virt-sysprep step on guests after they have
been converted by virt-v2v. They disable all sysprep the operations
except for just a couple, including ‘net-hwaddr’, so the effect is
roughly the same as this patch.
The question was raised why they need to do that as a separate step
and why virt-v2v doesn't do it.
This is what my question was about: I do not understand why this
sysprep step (to remove the MAC addresses) is done in the first place,
and without this information it is hard to put extra conversion steps
in v2v.
What issues were fixed by sysprep'ing the converted guest?
And indeed there was some discussion
about whether or not converted guests need a new MAC address -- it's
at best unclear -- it is thought that VMware might reuse MAC addresses
which have "left" the hypervisor, although no one knows if that's
really true or not.
IMHO the first thing to do would be deciding on whether the MAC address
need to be removed from the guest or not.
If it is decided they need to go, then my suggestion would be to add a
new command line option to tune this behaviour:
- if not specified, then the MAC addresses are preserved in both guest
and metadata
- if specified, then the MAC addresses will not be preserved even in
the metadata
--
Pino Toscano
7:40 a.m.
Apart from the MAC address, the network interface name may change. In my
tests, my network interface is renamed from ens160 in VMware to eth0 in RHV.
On 27 February 2018 at 14:01, Pino Toscano <ptoscano(a)redhat.com> wrote:
On Tuesday, 27 February 2018 13:34:09 CET Richard W.M. Jones wrote:
> On Tue, Feb 27, 2018 at 12:53:08PM +0100, Pino Toscano wrote:
> > On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
> > > Remove ties to MAC address because it is likely to change.
> >
> > v2v tries to preserve the MAC address of network interfaces; few months
> > ago we did a fix regarding this:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1506572
> >
> > The approach of this patch is IMHO not good, since it removes the MAC
> > address from the network-scripts, but still the rest of v2v will try
> > to preserve the MAC addresses.
>
> We preserve the MAC address in metadata. On the other hand AIUI this
> patch only removes the association in the ifcfg files and the guest
> will reassociate it when it boots (albeit it might then mix up the
> ethernet interfaces so that's not good).
Yes, this is my concern, i.e. that the guest network configuration
might break.
> There's IMHO a bigger problem which is not being addressed:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1318922
Possibly there could be also
https://bugzilla.redhat.com/show_bug.cgi?id=1451597
> > What's the reason behind this patch?
>
> There's a bit of background which is missing. Tomáš and I had some
> discussions (privately, unfortunately) with the ManageIQ developers
> who are integrating virt-v2v into MIQ/CloudForms. Their existing
> software runs a separate virt-sysprep step on guests after they have
> been converted by virt-v2v. They disable all sysprep the operations
> except for just a couple, including ‘net-hwaddr’, so the effect is
> roughly the same as this patch.
>
> The question was raised why they need to do that as a separate step
> and why virt-v2v doesn't do it.
This is what my question was about: I do not understand why this
sysprep step (to remove the MAC addresses) is done in the first place,
and without this information it is hard to put extra conversion steps
in v2v.
What issues were fixed by sysprep'ing the converted guest?
> And indeed there was some discussion
> about whether or not converted guests need a new MAC address -- it's
> at best unclear -- it is thought that VMware might reuse MAC addresses
> which have "left" the hypervisor, although no one knows if that's
> really true or not.
IMHO the first thing to do would be deciding on whether the MAC address
need to be removed from the guest or not.
If it is decided they need to go, then my suggestion would be to add a
new command line option to tune this behaviour:
- if not specified, then the MAC addresses are preserved in both guest
and metadata
- if specified, then the MAC addresses will not be preserved even in
the metadata
--
Pino Toscano
--
*Fabien Dupont*
PRINCIPAL SOFTWARE ENGINEER
Red Hat - Solutions Engineering
fabien(a)redhat.com M: +33 (0) 662 784 971 <+33662784971>
<http://redhat.com> *TRIED. TESTED. TRUSTED.*
Twitter: @redhatway <https://twitter.com/redhatway> | Instagram: @redhatinc
<https://www.instagram.com/redhatinc/> | Snapchat: @redhatsnaps
6:34 a.m.
On Tue, 27 Feb 2018 12:53:08 +0100
Pino Toscano <ptoscano(a)redhat.com> wrote:
On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
> Remove ties to MAC address because it is likely to change.
v2v tries to preserve the MAC address of network interfaces; few months
ago we did a fix regarding this:
https://bugzilla.redhat.com/show_bug.cgi?id=1506572
The approach of this patch is IMHO not good, since it removes the MAC
address from the network-scripts, but still the rest of v2v will try
to preserve the MAC addresses.
What's the reason behind this patch?
Reason is that the MAC address is likely to change after the conversion
because the environment uses different MAC prefix. It depends on the
management system. For example the default pool in oVirt has prefix
00:1A:4A:... registered to Qumranet Inc. I don't know what VMware has as
as default. Big companies probably have their own prefix and thus are
OK.
Sure, you can have custom MAC addresses with different prefix on your
network. I can't say if that is good idea or bad idea.
It seems to me that this dual approach is right thing to do. Remove the
reference from guest so it is ready for new MAC, but leave the old MAC
in metadata. That way the management system can decide what is the right
way to do.
Tomas
--
Tomáš Golembiovský <tgolembi(a)redhat.com>
6:57 a.m.
On Tue, Feb 27, 2018 at 01:34:21PM +0100, Tomáš Golembiovský wrote:
On Tue, 27 Feb 2018 12:53:08 +0100
Pino Toscano <ptoscano(a)redhat.com> wrote:
> On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
> > Remove ties to MAC address because it is likely to change.
>
> v2v tries to preserve the MAC address of network interfaces; few months
> ago we did a fix regarding this:
> https://bugzilla.redhat.com/show_bug.cgi?id=1506572
>
> The approach of this patch is IMHO not good, since it removes the MAC
> address from the network-scripts, but still the rest of v2v will try
> to preserve the MAC addresses.
>
> What's the reason behind this patch?
Reason is that the MAC address is likely to change after the conversion
because the environment uses different MAC prefix. It depends on the
management system. For example the default pool in oVirt has prefix
00:1A:4A:... registered to Qumranet Inc. I don't know what VMware has as
as default. Big companies probably have their own prefix and thus are
OK.
We're passing the source MAC through into the OVF (see rasd:MACAddress
and v2v/create_ovf.ml). Does oVirt use it?
Sure, you can have custom MAC addresses with different prefix on
your
network. I can't say if that is good idea or bad idea.
Every (real) ethernet card comes with a different MAC address, with a
different prefix for each vendor, so at least in theory there is no
problem here. It's not an issue for KVM either. But it might be an
issue for a particular management system, say if oVirt is hard-coding
that prefix somewhere, or is ignoring the rasd:MACAddress field.
It seems to me that this dual approach is right thing to do. Remove
the
reference from guest so it is ready for new MAC, but leave the old MAC
in metadata. That way the management system can decide what is the right
way to do.
The problem is going to be that ethernet ports get swapped around.
The other problem is that even if this is a good idea, Windows also
embeds the MAC address somewhere in the Registry and we aren't
touching that. Plus there's likely to be multiple other places in
Linux where it is stored, NetworkManager, systemd-networkd, etc.
This suggests that perhaps we should do this conditional on the target
hypervisor, but we'd need more information about what oVirt is doing
first.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
9:43 a.m.
On 27 Feb 2018, at 13:57, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
On Tue, Feb 27, 2018 at 01:34:21PM +0100, Tomáš Golembiovský wrote:
> On Tue, 27 Feb 2018 12:53:08 +0100
> Pino Toscano <ptoscano(a)redhat.com> wrote:
>
>> On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
>>> Remove ties to MAC address because it is likely to change.
>>
>> v2v tries to preserve the MAC address of network interfaces; few months
>> ago we did a fix regarding this:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1506572
>>
>> The approach of this patch is IMHO not good, since it removes the MAC
>> address from the network-scripts, but still the rest of v2v will try
>> to preserve the MAC addresses.
>>
>> What's the reason behind this patch?
>
> Reason is that the MAC address is likely to change after the conversion
> because the environment uses different MAC prefix. It depends on the
> management system. For example the default pool in oVirt has prefix
> 00:1A:4A:... registered to Qumranet Inc. I don't know what VMware has as
> as default. Big companies probably have their own prefix and thus are
> OK.
We're passing the source MAC through into the OVF (see rasd:MACAddress
and v2v/create_ovf.ml). Does oVirt use it?
no. Exactly for the reason Tomas mentioned, the MAC spaces are almost always entirely
different and we reallocate a different MAC every time
> Sure, you can have custom MAC addresses with different prefix on your
> network. I can't say if that is good idea or bad idea.
Every (real) ethernet card comes with a different MAC address, with a
different prefix for each vendor, so at least in theory there is no
problem here. It's not an issue for KVM either. But it might be an
issue for a particular management system, say if oVirt is hard-coding
that prefix somewhere, or is ignoring the rasd:MACAddress field.
> It seems to me that this dual approach is right thing to do. Remove the
> reference from guest so it is ready for new MAC, but leave the old MAC
> in metadata. That way the management system can decide what is the right
> way to do.
The problem is going to be that ethernet ports get swapped around.
The other problem is that even if this is a good idea, Windows also
embeds the MAC address somewhere in the Registry and we aren't
touching that. Plus there's likely to be multiple other places in
Linux where it is stored, NetworkManager, systemd-networkd, etc.
This suggests that perhaps we should do this conditional on the target
hypervisor, but we'd need more information about what oVirt is doing
first.
conditional sounds good. for ovirt specifically it may be unconditionally cleared
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
10:41 a.m.
On Tue, Feb 27, 2018 at 04:43:15PM +0100, Michal Skrivanek wrote:
> We're passing the source MAC through into the OVF (see
rasd:MACAddress
> and v2v/create_ovf.ml). Does oVirt use it?
no. Exactly for the reason Tomas mentioned, the MAC spaces are
almost always entirely different and we reallocate a different MAC
every time
That's oVirt's decision, and we can work around it as described by
erasing MAC addresses when the target is oVirt. The patch will need
to be more complete because it must at the very least deal with
NetworkManager & Windows.
However ... I'm pretty sure this is going to cause problems for oVirt.
It will mean in some circumstances that ethernet ports are swapped
(which can be serious - you don't want your public and private LANs to
get swapped over, although usually the result will be failure rather
than the guest sending out private information over a public port).
Also you'll have problems which anything which keys off the MAC
address to derive system-unique numbers, like license servers.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
10:54 a.m.
On 27 Feb 2018, at 17:41, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
On Tue, Feb 27, 2018 at 04:43:15PM +0100, Michal Skrivanek wrote:
>> We're passing the source MAC through into the OVF (see rasd:MACAddress
>> and v2v/create_ovf.ml). Does oVirt use it?
>
> no. Exactly for the reason Tomas mentioned, the MAC spaces are
> almost always entirely different and we reallocate a different MAC
> every time
That's oVirt's decision, and we can work around it as described by
erasing MAC addresses when the target is oVirt. The patch will need
to be more complete because it must at the very least deal with
NetworkManager & Windows.
However ... I'm pretty sure this is going to cause problems for oVirt.
It will mean in some circumstances that ethernet ports are swapped
(which can be serious - you don't want your public and private LANs to
get swapped over, although usually the result will be failure rather
than the guest sending out private information over a public port).
Also you'll have problems which anything which keys off the MAC
address to derive system-unique numbers, like license servers.
The reason for all that is that oVirt has a concept of MacPool which is a set of MAC
addresses (range) allowed in a particular DC. That’s typically different than VMware’s
even though it could be configured to overlap. The constraints are coming from that - when
the VM is added it cannot conflict with any VM already there (that can happen even for
overlapping ranges) and such VM is invalid (we strive not to create it as such under no
circumstances)
A clean way would be to use “add NIC” API which does the MAC allocation. In fact that’s
what’s happening when we import a VM with NICs with no MACs internally. Maybe a better
long-term solution would be to use the API in a similar way as upload API - to
define/reserve NICs. That way virt-v2v does have the information which NIC it is and maybe
it can map them correctly. Would it make sense to explore?
Thanks,
michal
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
2459
days inactive
2459
days old
16 comments
5 participants
participants (5)
-
Fabien Dupont -
Michal Skrivanek -
Pino Toscano -
Richard W.M. Jones -
Tomáš Golembiovský