Bitlocker vtpm test - #6914
Closed
sparimi-rh wants to merge 47 commits into
Closed
Conversation
It's kind of whacked that this is encoded in the test data, but for our internal testing we are moving all VMs to our vsphere 8 server. Update test defaults to match
v2v: move all test cases to use vsphere 8 See merge request libvirt-auto/tp-libvirt!2
Some uncommon cleanup paths miss passing the `--nvram` option to `virsh undefine`, which makes undefine fail for efi VMs. Passing it unconditionally is safe for libvirt's qemu driver, and other code already does this widely
v2v: use `virsh undefine --nvram` in cleanup paths See merge request libvirt-auto/tp-libvirt!3
The VM v2vci-esx8.0-windows-guests-with-mutiple-os was recreated on the new vSphere 8 server with UEFI boot. The UEFI install added an extra EFI System Partition, shifting the second OS root from /dev/sdb2 to /dev/sdb3. Update root_option to match the actual partition layout. Ref: LNXVAST-2500 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The VM v2vci-esx8.0-win2022-nvme-disk-thin-provision uses BIOS boot on vSphere (ESX dumpxml shows <os><type>hvm</type></os> without firmware='efi'). The test cfg had boottype=2 (q35+UEFI) which caused the VMChecker to fail with "Incorrect boottype of VM" after a successful conversion. Change boottype from 2 to 1 (q35+BIOS) to match the actual VM configuration. Ref: LNXVAST-2508 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
v2v: fix boottype for windows_vm_with_nvme_disk test See merge request libvirt-auto/tp-libvirt!5
v2v: fix root_option for multiple_os.second_os test See merge request libvirt-auto/tp-libvirt!4
_get_vmtools_info returned int(exit_code), making exit code 0 falsy. wait_for() treated it as "not ready" and kept polling until the 900s timeout, then returned None. The subsequent `if res:` check (None is falsy) silently passed the test without verifying anything. Fix: return exit code as string so "0" is truthy, and handle all cases explicitly: - Pattern not found in log -> test.fail with regex details - Exit code 0 -> log success - Exit code 1603 on win2019/win2025 -> log known issue - Any other exit code -> test.fail Ref: RHEL-51169 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
After v2v conversion, win2016 guests show a Device Manager error (code 45) for the CPU — the Intel/AMD Processor driver does not appear in the driver list. This is a win2016-specific issue (confirmed not reproducible on win10, win11, win2019, win2022) and is cosmetic — the guest boots and runs normally. The current code treats a missing CPU driver as a test failure, but for win2016 this is a known, unfixable VMware/Windows interaction (RHEL-17685, closed as minor). Skipping the check for win2016 avoids a false test failure. The fix is self-healing: if the underlying issue is ever resolved and the CPU driver appears in win2016's driver list, the normal regex check will match first and this elif branch will not be reached. Ref: RHEL-17685, LNXVAST-2542 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add v2v_login_timeout = 900 to all 7 v2v test cfg files. This works with the avocado-vt change that made create_session() read this param (defaults to 900 if absent). Having this in the cfg files allows ci-shared-datas to override the value via replaces, e.g. setting it to 600 for v2v jobs to reduce post-conversion login wait time. Ref: LNXVAST-2482 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Remove _ESX70_ and _ESX80_ from variable names since the ESX version should not be encoded in the variable name. The actual VM names are configured in ci-shared-datas. Exception: VM_NAME_ESX*_NBDKIT_V2V_EXAMPLE variables are preserved as they specifically test against different ESX versions. Ref: LNXVAST-2556 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The 800s threshold was set for the old CI infrastructure. On the new NFS storage (virtlab-storage02), 100GB disk conversion consistently takes ~1200s. Four runs on idle virtlab2619 showed times of 1236s, 1231s, 1156s, and 1197s. Raising to 1500s gives ~20% headroom above observed times while still catching genuine performance regressions. Related: LNXVAST-2578 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The vcenter_ip test replaces vpx_hostname with an invalid IP to verify error logging. But the CI job runs with esx_uri only, where the command uses the ESXi hostname, not the vCenter hostname. The vpx_hostname replacement is a no-op and v2v succeeds unexpectedly. Add invalid_esx_hostname so the test code also replaces the ESXi hostname. Both if-blocks in the invalid_source checkpoint run independently, so whichever hostname is in the URI gets replaced. Verified locally on virtlab2619: - vcenter_ip: now correctly replaces to esx://root@1.2.3.4, v2v fails with connection timeout as expected - esxi_ip: unchanged, still passes Related: LNXVAST-2694 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Win11 uses EFI Secure Boot. Without boottype=3, the test fails with "Incorrect boottype of VM" because the converted VM uses q35+OVMF but the test expects BIOS boot. Same fix already applied for empty_gw.win11 and other EFI Windows variants (win2025, win2019). Signed-off-by: Carlos Campos <ccamposr@redhat.com>
Match the MAC address against the 'Physical Address' field in ipconfig output instead of searching the entire adapter block. The DHCPv6 Client DUID line contains a MAC address that is the same across all adapters (it is a per-machine identifier set at Windows installation time). When the DUID happens to contain the target static IP NIC's MAC, the old 'mac_addr in v' check matches ALL adapter blocks, causing the code to select the wrong adapter (typically the DHCP adapter) and fail to find the static IP. This is hit when: - The VM has 2+ NICs (DHCP + static IP) - The DUID was generated from the static IP NIC's MAC (e.g., the VM was originally created with only that NIC) Affects: empty_gw.win2022 on VMs where the DUID contains the static IP NIC's MAC. Other VMs (win11, win2019) are unaffected because their DUIDs contain a different MAC. Signed-off-by: Carlos Campos <ccamposr@redhat.com>
…OS image Use a new placeholder VM_NAME_EMPTY_V2V_EXAMPLE (mapped to generic-empty-vm in ci-shared-datas) for 8 tests that fail before accessing VM content: function_test_esx.cfg: - vcenter_ip: connection error (invalid vpx hostname) - esxi_ip: connection error (invalid esx hostname) - invalid_mac_ip.addr: CLI argument parsing error - invalid_mac_ip.prefix: CLI argument parsing error - must_ip: missing -ip password file - no_vpx_username: authentication failure v2v_options.cfg: - print_source: metadata only (--print-source, output_mode=none) - vpx_with_invalid_esx_ipv6: connection error (invalid ipv6) These tests exercise CLI validation, connection errors, or metadata inspection. They never inspect the guest OS, so an empty VM works. This avoids tying negative/CLI tests to specific OS images. Requires ci-shared-datas change to add VM_NAME_EMPTY_V2V_EXAMPLE replacement mapping to generic-empty-vm. Signed-off-by: Carlos Campos <ccamposr@redhat.com>
v2v_options.py unconditionally NFS-mounts vddk_libdir_src to get the VDDK library, even when vddk_libdir is already set to a valid local path and vddk_libdir_src is empty. This causes test failures in environments where VDDK is pre-staged locally. Guard the NFS mount with a check on vddk_libdir_src. When empty, use the vddk_libdir parameter directly. When set (CI), mount normally. No behavior change for CI environments where vddk_libdir_src is always populated. Signed-off-by: Carlos Campos <ccamposr@redhat.com>
When using ESXi datastore NFS, the regular umount may not release the mount immediately, causing os.rmdir to fail with EBUSY. Fall back to lazy umount and handle rmdir failure gracefully. Signed-off-by: Surya Gupta <surygupt@redhat.com>
Remove the NFS_FUNC_VMX_V2V_EXAMPLE override from the vmx_default.cpu_topology variant in convert_from_file.cfg. The parent vmx_default already sets vmx_nfs_src to NFS_VMX_V2V_EXAMPLE which points to the vSphere datastore NFS (virtlab-storage02:/data/rhel-virt-tools-v2v). The cpu_topology variant was overriding this to NFS_FUNC_VMX_V2V_EXAMPLE which points to the old manually-maintained libvirt-storage NFS mirror. With Surya's ci-shared-datas MR!2572 merged, all VMX files are accessible directly from the vSphere datastore NFS, so the override to the old NFS path is no longer needed. Signed-off-by: Carlos Campos <ccamposr@redhat.com>
`root` is a non-standard user, but Administrator@vsphere.local is default admin account we can depend on existing
Drop this and we get it from config instead
This pattern is busted, and the cow_on_read test has been broken for forever AFAICT. The issue is nbdkit creates a root owned socket in a tmpdir, and the virt-inspector launched appliance is a libvirt VM running as the qemu user. The perennial problem :/ First run a chown command to make the socket accessible. This let's us just focus on the point of the test
These tests were ignoring errors and as a result none of them were testing what they expected to.
Those only matter for the timing tests
200ms makes these tests take close to 2hrs
validates that specified VM has a certain set of special characters so we are hitting all intended cases
the function_test_esx case covers it all now
These tests are all either os agnostic, or don't even require an OS because they are testing a specific failure path. Make that clear with the naming Signed-off-by: Cole Robinson <crobinso@redhat.com>
This name is more clear about the intention
This name makes it more clear about the intention
+ Implicitly require NFS locations to be passed. Trying to handle both NFS and local paths made things really messy for CI config, and CI only uses NFS. + Handle unmounting and tmpdir cleanup on failure
Reference: https://gitlab.cee.redhat.com/libvirt-auto/avocado-vt/-/merge_requests/5#note_22379014 Problem: v2v cases with leading and trailing '.*' in string takes too much time to finish the pattern search. Solution: speed up the specific case from the bug by dropping the trailing and leading '.*' in the regex string. Signed-off-by: Ganesh Hubale <ghubale@redhat.com>
|
Warning Review limit reached
Next review available in: 54 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (15)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
sparimi-rh
force-pushed
the
bitlocker-vtpm-test
branch
from
July 10, 2026 14:17
e4bbc72 to
258b921
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Update the luks_key with new recovery key which was saved post enabling bitlocker in Win11 VM v2vci-esx8.0-win11-efi-with-vtpm-and-bitlocker