[virt-tools-list] virt-install cannot determine proper disk type on remote host

[Cole Robinson]

On 7/2/19 6:30 AM, Marko Todorić wrote:
> Description of problem:
> When using virt-install to perform remote installation of VM using disk 
> of a type block device (virt-install 
> --connect=qemu+ssh://hostname/system 
> --disk=/dev/mapper/mpatha,bus=virtio,cache=none ...) it will define a VM 
> disk as a "file" instead of "block" type device, and will define 
> "source" as "file" instead of "dev".
> 
> Example, it will create a disk like this:
>      <disk type='file' device='disk'>
>        <driver name='qemu' type='raw' cache='none' io='native'/>
>        <source file='/dev/mapper/mpatha'/>
>        <backingStore/>
>        <target dev='vda' bus='virtio'/>
>        <alias name='virtio-disk0'/>
>        <address type='pci' domain='0x0000' bus='0x00' slot='0x06' 
> function='0x0'/>
>      </disk>
> 
> When it should be:
>      <disk type='block' device='disk'>
>        <driver name='qemu' type='raw' cache='none' io='native'/>
>        <source dev='/dev/mapper/mpatha'/>
>        <backingStore/>
>        <target dev='vda' bus='virtio'/>
>        <alias name='virtio-disk0'/>
>        <address type='pci' domain='0x0000' bus='0x00' slot='0x06' 
> function='0x0'/>
>      </disk>
> 
> If using virt-install on local hypervisor, it will define disk just 
> fine. We are using multipath devices (NetApp LUNs) that we are serving 
> to VM as a disk.
> 
> 
> Version-Release number of selected component (if applicable):
> Tested on virt-install 1.5.0 and virt-install 2.1.0
> 
> How reproducible:
> Every time it creates a VM on a remote hypervisor using virt-install 
> --connect option
> 
> Steps to Reproduce:
> 1. virt-install --connect=qemu+ssh://hostname/system --name=test --hvm 
> --graphics vnc --disk path=/dev/mapper/mpatha,bus=virtio,cache=none 
> --vcpus=2 --memory=2048 --cdrom=/ISO/CentOS-7-x86_64-Minimal-1810.iso 
> --boot hd,cdrom,menu=on --os-type=linux --os-variant=rhel7 --network 
> bridge=br7,model=virtio --noreboot
> 
> Actual results:
> It will create a disk defined in XML like this:
>      <disk type='file' device='disk'>
>        <driver name='qemu' type='raw' cache='none' io='native'/>
>        <source file='/dev/mapper/mpatha'/>
>        <backingStore/>
>        <target dev='vda' bus='virtio'/>
>        <alias name='virtio-disk0'/>
>        <address type='pci' domain='0x0000' bus='0x00' slot='0x06' 
> function='0x0'/>
>      </disk>
> 
> Expected results:
> It should create a disk defined in XML like this:
>      <disk type='block' device='disk'>
>        <driver name='qemu' type='raw' cache='none' io='native'/>
>        <source dev='/dev/mapper/mpatha'/>
>        <backingStore/>
>        <target dev='vda' bus='virtio'/>
>        <alias name='virtio-disk0'/>
>        <address type='pci' domain='0x0000' bus='0x00' slot='0x06' 
> function='0x0'/>
>      </disk>
> 
> Additional info:
> VM will seem to work fine but not sure if there could be any issues 
> because disk is improperly defined.
> And also cannot be migrated using virsh migrate without using --unsafe. 
> If i edit XML and define it as "block", migrate works as expected.
> 

virt-install will use libvirt's storage APIs to determine if existing
storage is a file or a block device, and the file format like qcow2 etc.
In this case, if /dev/mapper is not part of a libvirt storage pool, we
default to assuming the path is of type 'file'. On a local host, we will
try and probe files under /dev/ to determine their file type but we
don't have that option for remote hosts. Which is why you are seeing the
behavior difference.

For the qemu driver, there isn't much difference in how type=block vs
type=file is handled that I know of, which is why you didn't notice much
difference.

You can work around it by adding type=block to your --disk option. Or
create a libvirt mpath pool to track /dev/mapper contents.

- Cole