[virt-tools-list] [PATCH] virt-clone: further fix guest booting when cloning a qcow2 image

[Wanlong Gao]

On 03/28/2012 06:53 AM, Cole Robinson wrote:

> On 03/24/2012 01:13 PM, Wanlong Gao wrote:
>> commit f0195e95d5 didn't fix the problem completely,
>> we should get the orig_disk's driver_type when setup
>> cloning.
>>
>> Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com>
>> ---
>>  virtinst/CloneManager.py |    5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/virtinst/CloneManager.py b/virtinst/CloneManager.py
>> index ff3c074..dee3c59 100644
>> --- a/virtinst/CloneManager.py
>> +++ b/virtinst/CloneManager.py
>> @@ -499,7 +499,7 @@ class CloneDesign(object):
>>              xmldisk.path = None
>>              xmldisk.type = clone_disk.type
>>              xmldisk.path = clone_disk.path
>> -            xmldisk.driver_type = clone_disk.driver_type
>> +            xmldisk.driver_type = orig_disk.driver_type
>>  
>>          # Save altered clone xml
>>          self._clone_xml = self._guest.get_xml_config()
>> @@ -553,7 +553,8 @@ class CloneDesign(object):
>>                      device = VirtualDisk.DEVICE_CDROM
>>  
>>                  d = VirtualDisk(disk.path, conn=self._hyper_conn,
>> -                                device=device, validate=validate)
>> +                                device=device, driverType=disk.driver_type,
>> +                                validate=validate)
>>                  d.target = disk.target
>>              except Exception, e:
>>                  logging.debug("", exc_info=True)
> 
> Hmm, can you give an example invocation where the current code fails? I'm
> having trouble understanding the problem.
> 
> Then hopefully we can turn that into a unit test that demonstrates the fix.


Sure,

After cloning a guest with "qcow2" image, the cloned guest
can't boot with the no boot able image error, the issue is
that "virt-clone" didn't sync the disk's driver type, below
is the description of this issue,

[root at gaowanlong ~]# virsh dumpxml 6u1-clone
...
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
...

[root at gaowanlong ~]# virt-clone -o 6u1-clone -n 6u1-clone-clone -f /work/image/6u1-clone-clone.img --print-xml
...
    <disk type="file" device="disk">
      <driver name="qemu" type="raw"/>      <-------------not sync the driver type
...

Then I sent a patch to sync the "disk driver type", after patch applied,
[root at gaowanlong ~]# virt-clone -o 6u1-clone -n 6u1-clone-clone -f /work/image/6u1-clone-clone.img --print-xml
...
    <disk type="file" device="disk">
      <driver name="qemu" type="qcow2"/>     <-----------here sync the qcow2
...



And the VNC information now handled like below,

[root at gaowanlong ~]# virsh dumpxml 6u1-clone
...
    <graphics type='vnc' port='5900' autoport='no' listen='192.168.122.1'>
      <listen type='address' address='192.168.122.1'/>
    </graphics>
...

[root at gaowanlong ~]# virt-clone -o 6u1-clone -n 6u1-clone-clone -f /work/image/6u1-clone-clone.img --print-xml
...
    <graphics type="vnc" port="5900" autoport="no" listen="192.168.122.1">
      <listen type="address" address="192.168.122.1"/>
    </graphics>
...

Assume you set port='5900' and no autoport.
Then, copied guest's vnc will have the same port with the orignal.
If one of them started, another can't get vnc.

So, if you find 'port=xxxx' in the orignal xml, you should modify it as autoport
with some warning. Then, you can run both of guests at once.

Thanks,
Wanlong Gao

> 
> Thanks,
> Cole
>