Bug 1375471

Summary: virt-clone changes disk type=volume to type=file
Product: [Community] Virtualization Tools Reporter: Xiaodai Wang <xiaodwan>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED DEFERRED QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: berrange, crobinso, gscrivan, juzhou, mxie, mzhan, tzheng
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-15 18:26:33 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:

Description Xiaodai Wang 2016-09-13 08:40:15 UTC
Description of problem:
the disk type is changed after clone

Version-Release number of selected component (if applicable):
virt-manager-1.4.0-2.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1. Open virt-manager
2. Check the disk type of guest.
    <disk type='volume' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source pool='default' volume='rhel7.2-ftp.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>
3. Clone the guest and check the xml after clone.
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel7.2-ftp-clone.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>

Actual results:
The disk type is changed from "type='volume'" to "type='file'" after clone.

Expected results:
The disk type should be same as before.

Additional info:

Comment 2 Pavel Hrdina 2017-01-19 10:06:00 UTC
Moving to upstream, this doesn't have any effect on functionality.

Comment 3 Cole Robinson 2019-06-15 18:26:33 UTC
Nice find :) The behavior isn't strictly intentional but I don't really know if it classifies as a bug or not. I see the volume= stuff as a convenience option and more so for things like network pools where it's less clear how to translate volume XML into <disk> source XML.

If someone shows up with a patch to fix this I will consider it, but I don't think we need to track it in the bug tracker