For this bug I've tried to reproduce it:
1.To disable net drive ,but the Ethernet device was not same as attachment,device was gone not appeared red fork.
2.To delete /etc/qemu-ifup and qemu-ifdown file to simulate a bridge cable disconnect.but I cannot connect with guest.
Both these operations for simulating reproduce driver problems during convert guest between two different product,and google it said that most probles were caused by driver disfunction.
looked through some blogs and materials.Vmware and RHV are both high-level application ，Not only that, but the two have very different network models,so I need the image that guest booted with no IP or Gateway infomation to liuzi.waiting for the image now.

Created attachment 1713130 [details]
Get-NetIPAddress output

Checking the vm where the issue is reproduced, this does not seem to be a qemu-ga bug.
in fact, qemu-ga is actually reflecting valid information from the guest-os.
this information can be viewed using Powershell cmdlet "Get-NetIPAddress" (view attachment)
https://bugzilla.redhat.com/attachment.cgi?id=1713130

Apparently there are still some IpAddress object that holds this IpAddress configuration,
this can be a leftover of network configuration from the VM conversion.
it can also be related to static ip configuration before the conversion,
for example if the static ip was set using New-NetIPAddress powershell cmdlet (which adds a new Ip address),
instead of Set-NetIPAddress (which Modifies the configuration of an IP address).

(In reply to Basil Salman from comment #8)
> Checking the vm where the issue is reproduced, this does not seem to be a
> qemu-ga bug.
> in fact, qemu-ga is actually reflecting valid information from the guest-os.
> this information can be viewed using Powershell cmdlet "Get-NetIPAddress"
> (view attachment)
> https://bugzilla.redhat.com/attachment.cgi?id=1713130
> 

That may be but it is still questionable whether the behavior of qemu-ga is correct. Is it supposed to return IP setup for unavailable interfaces? Is it something management apps or admins care about when interacting with qemu-ga?

If we want to keep the behavior it would make sense to extend the API to reflect whether the reported interface is up or down.

> Apparently there are still some IpAddress object that holds this IpAddress
> configuration,
> this can be a leftover of network configuration from the VM conversion.
> it can also be related to static ip configuration before the conversion,
> for example if the static ip was set using New-NetIPAddress powershell
> cmdlet (which adds a new Ip address),
> instead of Set-NetIPAddress (which Modifies the configuration of an IP
> address).

Yes, most likely relic from the VMware environment.

(In reply to Tomáš Golembiovský from comment #9)
> (In reply to Basil Salman from comment #8)
> > Checking the vm where the issue is reproduced, this does not seem to be a
> > qemu-ga bug.
> > in fact, qemu-ga is actually reflecting valid information from the guest-os.
> > this information can be viewed using Powershell cmdlet "Get-NetIPAddress"
> > (view attachment)
> > https://bugzilla.redhat.com/attachment.cgi?id=1713130
> > 
> 
> That may be but it is still questionable whether the behavior of qemu-ga is
> correct. Is it supposed to return IP setup for unavailable interfaces? Is it
> something management apps or admins care about when interacting with qemu-ga?
> 
> If we want to keep the behavior it would make sense to extend the API to
> reflect whether the reported interface is up or down.
> 
Well in this case the interface is not unavailable, the interface is the same virtio-net device,
Ipaddress objects can be bound to a NIC using InterfaceIndex and Alias and i think that the previous 
NIC had the same value those properties, and that's why it was shown under virtio-net.
Also this is not an incorrect configuration in terms of Windows as such configuration can be useful.

> > Apparently there are still some IpAddress object that holds this IpAddress
> > configuration,
> > this can be a leftover of network configuration from the VM conversion.
> > it can also be related to static ip configuration before the conversion,
> > for example if the static ip was set using New-NetIPAddress powershell
> > cmdlet (which adds a new Ip address),
> > instead of Set-NetIPAddress (which Modifies the configuration of an IP
> > address).
> 
> Yes, most likely relic from the VMware environment.

Is it okay if we close this as not a bug?

(In reply to Basil Salman from comment #10)
> (In reply to Tomáš Golembiovský from comment #9)
> > (In reply to Basil Salman from comment #8)
> > > Checking the vm where the issue is reproduced, this does not seem to be a
> > > qemu-ga bug.
> > > in fact, qemu-ga is actually reflecting valid information from the guest-os.
> > > this information can be viewed using Powershell cmdlet "Get-NetIPAddress"
> > > (view attachment)
> > > https://bugzilla.redhat.com/attachment.cgi?id=1713130
> > > 
> > 
> > That may be but it is still questionable whether the behavior of qemu-ga is
> > correct. Is it supposed to return IP setup for unavailable interfaces? Is it
> > something management apps or admins care about when interacting with qemu-ga?
> > 
> > If we want to keep the behavior it would make sense to extend the API to
> > reflect whether the reported interface is up or down.
> > 
> Well in this case the interface is not unavailable, the interface is the
> same virtio-net device,
> Ipaddress objects can be bound to a NIC using InterfaceIndex and Alias and i
> think that the previous 
> NIC had the same value those properties, and that's why it was shown under
> virtio-net.

If I recall the situation was that virtio interface was configured to use DHCP, was not enabled and did not have *any* IP assigned. So this does not quite match. Or are you implying it is possible to have both static address and DHCP configured on single interface in Windows? Or is it just reporting some cached IP from previous run? If yes than that shouldn't be reported by qemu-ga then.

> Also this is not an incorrect configuration in terms of Windows as such
> configuration can be useful.

Maybe, but the question then is how do pass the important information to the consumers of qemu-ga API. If qemu-ga reports IPs from guest OS that are not available then it does not sound too useful to me.

> 
> > > Apparently there are still some IpAddress object that holds this IpAddress
> > > configuration,
> > > this can be a leftover of network configuration from the VM conversion.
> > > it can also be related to static ip configuration before the conversion,
> > > for example if the static ip was set using New-NetIPAddress powershell
> > > cmdlet (which adds a new Ip address),
> > > instead of Set-NetIPAddress (which Modifies the configuration of an IP
> > > address).
> > 
> > Yes, most likely relic from the VMware environment.
> 
> Is it okay if we close this as not a bug?

Definitely not.

(In reply to Tomáš Golembiovský from comment #11)
> (In reply to Basil Salman from comment #10)
> > (In reply to Tomáš Golembiovský from comment #9)
> > > (In reply to Basil Salman from comment #8)
> > > > Checking the vm where the issue is reproduced, this does not seem to be a
> > > > qemu-ga bug.
> > > > in fact, qemu-ga is actually reflecting valid information from the guest-os.
> > > > this information can be viewed using Powershell cmdlet "Get-NetIPAddress"
> > > > (view attachment)
> > > > https://bugzilla.redhat.com/attachment.cgi?id=1713130
> > > > 
> > > 
> > > That may be but it is still questionable whether the behavior of qemu-ga is
> > > correct. Is it supposed to return IP setup for unavailable interfaces? Is it
> > > something management apps or admins care about when interacting with qemu-ga?
> > > 
> > > If we want to keep the behavior it would make sense to extend the API to
> > > reflect whether the reported interface is up or down.
> > > 
> > Well in this case the interface is not unavailable, the interface is the
> > same virtio-net device,
> > Ipaddress objects can be bound to a NIC using InterfaceIndex and Alias and i
> > think that the previous 
> > NIC had the same value those properties, and that's why it was shown under
> > virtio-net.
> 
> If I recall the situation was that virtio interface was configured to use
> DHCP, was not enabled and did not have *any* IP assigned. So this does not
> quite match. Or are you implying it is possible to have both static address
> and DHCP configured on single interface in Windows? Or is it just reporting
> some cached IP from previous run? If yes than that shouldn't be reported by
> qemu-ga then.
> 
After further inspection apparently this IP is assigned from link layer,
this is due link being off ( cable unplugged), so it
> > Also this is not an incorrect configuration in terms of Windows as such
> > configuration can be useful.
> 
> Maybe, but the question then is how do pass the important information to the
> consumers of qemu-ga API. If qemu-ga reports IPs from guest OS that are not
> available then it does not sound too useful to me.
> > 
> > > > Apparently there are still some IpAddress object that holds this IpAddress
> > > > configuration,
> > > > this can be a leftover of network configuration from the VM conversion.
> > > > it can also be related to static ip configuration before the conversion,
> > > > for example if the static ip was set using New-NetIPAddress powershell
> > > > cmdlet (which adds a new Ip address),
> > > > instead of Set-NetIPAddress (which Modifies the configuration of an IP
> > > > address).
> > > 
> > > Yes, most likely relic from the VMware environment.
> > 
> > Is it okay if we close this as not a bug?
> 
> Definitely not.

I was able to reproduce something similar with qemu cli without the use of rhv or vmware.
using set_link off qmp command.
in this case qemu-ga still reports the old ip, even though it is disconencted.

Let's check the code: https://github.com/libguestfs/virt-v2v/blob/master/v2v/convert_windows.ml#L632 - this is PS script that should configure static IP after VM is up after V2V.

Based on the team discussion, marking as duplicate of BZ#1862893

*** This bug has been marked as a duplicate of bug 1862893 ***