Bug 1662286

Created attachment 1517035 [details]
screenshot1

Created attachment 1517036 [details]
screenshot2

Yes - interesting.  3 disks.  The system disk is copied and converted
successfully.  The 2 remaining disks are copied, but for some reason
Windows doesn't see them on the target.  RHV metadata on the target
looks fine.

FYI, have seen these symptoms with other versions of libguestfs and OS, as a function of the conversion process and not a bug but a Microsoft feature.  For Windows Datacenter or Enterprise editions, the default SAN disk policy is to offline any non-boot disks the first time the OS sees them, unless you change the default policy and/or override the policy on them individually.  This is due to safety concerns when working with "shared" SAN disks and clustered environments.  If changing to virtio-scsi (at least), after running virt-v2v (and thus virt-p2v), Windows will see the "old" direct-attach disks as new SAN ones, since their driver/device path has changed.  If onlining the disks in Disk Manager resolves the "missing" disks, then this is the probable root cause.  See here for some references and examples on how to script changing the policy: http://longwhiteclouds.com/2017/08/15/windows-script-for-marking-all-disks-online/.  Changing the disk policy can be done as a prep step on the source side, or as a firstboot script with a reboot afterwards.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

My apologies, this bug was closed by a broken process that we
do not have any control over.  Reopening.

It still needs investigation by someone.

Moving to RHEL 9.  It seems (comment 4) like this is expected behaviour, in which
case it's not a bug, but it still needs investigation.

Hopefully this will reproduce using:

- just virt-v2v, that is, using a VM on the source side -- the disks
  should be attached via virtio-scsi, so that, when they become
  virtio-blk after conversion, the same symptom is triggered;

- libvirt output (I don't see how RHV should be relevant here).

(In reply to Laszlo Ersek from comment #12)
> Hopefully this will reproduce using:
> 
> - just virt-v2v, that is, using a VM on the source side -- the disks
>   should be attached via virtio-scsi, so that, when they become
>   virtio-blk after conversion, the same symptom is triggered;
> 
> - libvirt output (I don't see how RHV should be relevant here).

I think so.

Although it's probably not relevant here, this tool - written by v2v alumnus
Matt Booth - can open Dynamic Disks from Linux:

https://github.com/mdbooth/libldm

FWIW my goal is to reproduce this symptom and then to close the BZ as NOTABUG. Most of comment 4 describes that this is intentional behavior on Windows' part, and the last part of comment 4 (the auto-onlining) is really not to my liking. First, we should avoid adding more firstboot scripts if possible, second, indiscriminately messing with the onlining policy looks like a disaster -- Microsoft has a safety feature and we override it without asking the user? *shudder*. I'd rather let the user manually re-online the disks after conversion, or change the policy *before* conversion (manually, or using some kind of Windows scripting if they have a large set of VMs to convert). Virt-v2v intends to make the converted machine bootable; these are data disks, not boot disks.

I reproduced the symptom with a Windows Server 2019 VM using three virtio-scsi disks (on the source (libvirt) side).

After manually onlining Disk 1 and Disk 2 in the converted domain, the array got automatically assembled, and the text file I had previously placed on R:, still in the source domain, could be successfully read back.

Perhaps of relevance, I should note that even in the *source* domain, when I was initially creating the software RAID array, I had to manually online Disk 1 and Disk 2. In comment 0, point 2.1 says, "Right click Unallocated Disk 1 which you want included in your RAID and select new spanned volume". However, the menu entry "new spanned volume" is greyed out (unavailable) until after: (a) the disks are manually onlined, and (b) the disks are manually "initialized" (= partitioned). So these steps are actually missing from comment#0. The point being: even on the source side, before conversion, any extra disks have to be onlined manually, and Disk Manager does explain that this requirement is due to local policy (if you hover over the Disk 1 and Disk 2 icons in Disk Manager with the mouse).

So I think there's nothing for virt-v2v to do here. Change the disk onlining policy on the source side, then convert; or convert, and then either manually online, or change the policy.

(virt-v2v version used for comment 15: upstream 03c7f0561081)

(In reply to Laszlo Ersek from comment #15)
> I reproduced the symptom with a Windows Server 2019 VM using three
> virtio-scsi disks (on the source (libvirt) side).

To clarify:

- manual onlining was required in both the original domain and the converted domain

- three virtio-scsi disks were used on the source side; virt-v2v converted each of those to virtio-blk (which is what triggers the policy on the target end)

I should have spelled my initial sentence as:

"I reproduced the symptom with a Windows Server 2019 VM, after conversion -- and the original VM, managed by libvirt, used three virtio-scsi disks".