Description of problem: Chipset should be set to Q35 if converting from XEN to RHV by v2v rhv-upload Version-Release number of selected component (if applicable): Software Version:4.4.7.6-0.11.el8ev virt-v2v-1.42.0-14.module+el8.5.0+11846+77888a74.x86_64 How reproducible: 100% Steps to Reproduce: 1. Convert a vm form XEN to RHV by virt-v2v rhv-upload. # LIBGUESTFS_BACKEND=direct virt-v2v -ic xen+ssh://root.x.x/ -o rhv-upload -of raw -os fc_data -oc https://x.x.x.x/ovirt-engine/api -op /root/rhv_upload_passwd_file -oo rhv-cluster=FC -oa preallocated -oo rhv-direct --mac 00:16:3e:65:4a:33:network:ovirtmgmt xen-pv-rhel6.10-x86_64 -on xiaodwan-xen-pv-rhel6.10-x86_64BDv 2. Wait until the conversion finishes, then check the chipset of the VM in rhv. Actual results: The Chipset was set to BIOS. Expected results: It should be Q35. Additional info:
This was solved for import from VMware in bz 1961945, need to do the same for XEN and Libvirt
Verified: ovirt-engine-4.4.8.3-0.10.el8ev virt-v2v-1.42.0-9.module+el8.4.0+9561+069bb9c1.x86_64 vdsm-4.40.80.4-1.el8ev.x86_64 qemu-kvm-5.2.0-16.module+el8.4.0+11923+e8b883e4.4.x86_64 libvirt-daemon-7.0.0-14.3.module+el8.4.0+11878+84e54169.x86_64 Verification scenario: 1. Import RHEL and Windows VM from Xen 2. After import completion, verify VMs chipset/firmaware typeis now Q35 chipset with BIOS
(In reply to Nisim Simsolo from comment #2) > Verified: > ovirt-engine-4.4.8.3-0.10.el8ev > virt-v2v-1.42.0-9.module+el8.4.0+9561+069bb9c1.x86_64 > vdsm-4.40.80.4-1.el8ev.x86_64 > qemu-kvm-5.2.0-16.module+el8.4.0+11923+e8b883e4.4.x86_64 > libvirt-daemon-7.0.0-14.3.module+el8.4.0+11878+84e54169.x86_64 > > Verification scenario: > 1. Import RHEL and Windows VM from Xen Nisim, was it verified by executing virt-v2v with 'rhv-upload'? > 2. After import completion, verify VMs chipset/firmaware typeis now Q35 > chipset with BIOS
(In reply to Arik from comment #3) > > Nisim, was it verified by executing virt-v2v with 'rhv-upload'? > virt-v2v
(In reply to Nisim Simsolo from comment #4) https://bugzilla.redhat.com/show_bug.cgi?id=1983610#c2 was Verified using WebAdmin Also verified using virt-v2v command: 1. Convert a vm form XEN to RHV by virt-v2v rhv-upload: # LIBGUESTFS_BACKEND=direct virt-v2v -ic xen+ssh://root.X.X/ -o rhv-upload -of raw -os SD_name -oc https://X.X.X.X/ovirt-engine/api -op /root/rhv_upload_passwd_file -oo rhv-cluster=Default -oa preallocated -oo rhv-direct rhel74_qcow2 -on 111_rhel74_qcow2_ru 2. Verify import process completed with no errors. 3. Open edit VM dialog and verify chipset/firmware type is Q35 chipset with BIOS 4. Run VM Verify VM is running successfully enter VM and verify actual chipset/firmware type is Q35: # dmidecode | grep -i q35 -A 9 -B 3 Base Board Information Manufacturer: Red Hat Product Name: RHEL-AV Version: RHEL-8.4.0 PC (Q35 + ICH9, 2009) Serial Number: Not Specified Asset Tag: Not Specified Features: Board is a hosting board Location In Chassis: Not Specified Chassis Handle: 0x0300 Type: Motherboard Contained Object Handles: 0
This bugzilla is included in oVirt 4.4.8 release, published on August 19th 2021. Since the problem described in this bug report should be resolved in oVirt 4.4.8 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.
(In reply to Arik from comment #1) > This was solved for import from VMware in bz 1961945, need to do the same > for XEN and Libvirt Hi Arik, The issue was solved on XEN. But it seems to be missed when converting from libvirt to RHV. my rhv server is 4.4.8.3-0.10.el8ev. The v2v command is: virt-v2v -ic qemu:///system -o rhv-upload -of raw -os nfs_data -oc https://x.x.x.x/ovirt-engine/api -op /tmp/rhv_upload_passwd_file -oo rhv-cafile=/tmp/rhv_upload_ca.pem -oo rhv-cluster=NFS -oo rhv-direct --mac 52:54:00:9e:81:c2:network:ovirtmgmt avocado-vt-vm1 -on avocado-vt-vm1Yul The os in xml is: <os>\n <type arch=\'x86_64\' machine=\'pc-i440fx-rhel7.6.0\'>hvm</type>\n <smbios mode=\'sysinfo\'/>\n </os> Could you help to check if it should also be fixed? Thanks xiaodwan
(In reply to Xiaodai Wang from comment #7) > (In reply to Arik from comment #1) > > This was solved for import from VMware in bz 1961945, need to do the same > > for XEN and Libvirt > > Hi Arik, > > The issue was solved on XEN. > > But it seems to be missed when converting from libvirt to RHV. > > my rhv server is 4.4.8.3-0.10.el8ev. > > The v2v command is: > virt-v2v -ic qemu:///system -o rhv-upload -of raw -os nfs_data -oc > https://x.x.x.x/ovirt-engine/api -op /tmp/rhv_upload_passwd_file -oo > rhv-cafile=/tmp/rhv_upload_ca.pem -oo rhv-cluster=NFS -oo rhv-direct --mac > 52:54:00:9e:81:c2:network:ovirtmgmt avocado-vt-vm1 -on avocado-vt-vm1Yul > > The os in xml is: > <os>\n <type arch=\'x86_64\' machine=\'pc-i440fx-rhel7.6.0\'>hvm</type>\n > <smbios mode=\'sysinfo\'/>\n </os> > > Could you help to check if it should also be fixed? That's problematic for us to handle because we can't differentiate between VMs that are imported from KVM through virt-v2v and ones we find on export domains, and we don't want to change VMs that are found on an export domain, so we intentionally don't try to convert them to q35