Bug 1339482

Summary: create clone fails because of guest_agent channel path
Product: Red Hat Enterprise Linux 7 Reporter: Frank Büttner <bugzilla>
Component: virt-managerAssignee: virt-mgr-maint
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: phrdina
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-25 10:14:56 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:
Embargoed:

Description Frank Büttner 2016-05-25 07:41:07 UTC 
Description of problem:
When clone an VM, which contains an guest_agent channel then starting the clone fails, because the path don't match the clone name.

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

How reproducible:
every time

Steps to Reproduce:
1. run virt-manager
2. clone an vm
3. try to start the vm

Actual results:
Start fails, because the clone have the same guest_agent channel path as the source.


Expected results:
Running vm.

Additional info:
You must call virsh edit cloneName and change this part:
 <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-SourceName/org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>

to:
 <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-cloneName/org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
Comment 2 Pavel Hrdina 2016-05-25 10:14:56 UTC 

*** This bug has been marked as a duplicate of bug 1270696 ***