Bug 1518539
Summary: | Macvtap network will be lost during v2v conversion | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | mxie <mxie> | ||||||||
Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> | ||||||||
Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | high | ||||||||||
Version: | 7.5 | CC: | juzhou, mzhan, ptoscano, tzheng, xiaodwan | ||||||||
Target Milestone: | rc | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | V2V | ||||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2019-04-15 08:41:24 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Created attachment 1360189 [details]
converted-network
Created attachment 1360190 [details]
virt-v2v-network_macvtap.log
Fixed upstream with https://github.com/libguestfs/libguestfs/commit/1629ec6a5639cf5e226e80bcee749ae8851b1fae which is in libguestfs >= 1.41.1. In short: virt-v2v will produce a warning, as these host passthrough devices cannot be converted. ... and I noticed now this is a duplicate of bug 1151902. *** This bug has been marked as a duplicate of bug 1151902 *** |
Created attachment 1360187 [details] macvtap Description of problem: Macvtap network will be lost during v2v conversion Version-Release number of selected component (if applicable): virt-v2v-1.36.10-2.el7.x86_64 libguestfs-1.36.10-2.el7.x86_64 libvirt-3.9.0-3.el7.x86_64 qemu-kvm-rhev-2.10.0-9.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Prepare a guest whose network type is "direct",in other words,guest has macvtap network,pls refer to screenshot"macvtap" # virsh dumpxml resume-rhel7-99 .... <interface type='direct'> <mac address='52:54:00:00:96:50'/> <source dev='eno1' mode='bridge'/> <model type='rtl8139'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> .... 2.Convert this guest to rhv by virt-v2v, there is no error/warning during conversion # virt-v2v resume-rhel7-99 -o rhv -os 10.73.131.93:/home/nfs_export [ 0.0] Opening the source -i libvirt resume-rhel7-99 [ 0.0] Creating an overlay to protect the source from being modified [ 0.4] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export [ 0.5] Opening the overlay [ 1.6] Inspecting the overlay [ 11.8] Checking for sufficient free disk space in the guest [ 11.8] Estimating space required on target for each disk [ 11.8] Converting Red Hat Enterprise Linux Server 7.4 (Maipo) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 54.4] Mapping filesystem data to avoid copying unused and blank areas [ 54.4] Closing the overlay [ 54.5] Checking if the guest needs BIOS or UEFI to boot [ 54.5] Assigning disks to buses [ 54.5] Copying disk 1/1 to /tmp/v2v.bT6UU1/bdf9c90b-e6f0-439c-aa9f-6305fd5fad7e/images/336171ef-fc13-4aff-bb55-c029c0660d5e/8dc3cfb3-114d-4614-870e-d6d861967d7f (qcow2) (100.00/100%) [ 93.2] Creating output metadata [ 93.2] Finishing off 3.Import guest from export domain to data domain at rhv but found converted guest has no network, pls refer to screenshot "converted-network",check network status in converted guest as below: #ifconfig lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Local Loopback) RX packets 1577923 bytes 19419644834 (18.0 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1577923 bytes 19419644834 (18.0 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether 52:54:00:fb:d4:22 txqueuelen 1000 (Ethernet) RX packets 2202 bytes 231221 (225.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1709 bytes 886888 (866.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Actual results: As above description Expected results: 1.Guest with macvtap network could have network after v2v conversion 2.If v2v can't convert macvtap network of guest, should pop up a warning during conversion Additional info: