+++ This bug was initially created as a clone of Bug #609422 +++
Description of problem:
If you use the virtual machine manager GUI to add a disk to a VM, it works fine. If you do it via cli, it adds an extra line that causes the VM not to boot.
Version-Release number of selected component (if applicable):
RHEL 5.5
libvirt-0.6.3-33.el5
How reproducible:
100%
Steps to Reproduce:
1. start a VM ('test')
2. add a disk using vish like this:
virsh attach-disk test /dev/VolGroup00/lv-test vda
3. stop the VM and start it again.
Actual results:
Error starting domain: internal error unsupported driver name 'phy' for disk '/dev/VolGroup00/lv-test'
Expected results:
The VM can be started normally after attaching disk with cli.
Additional info:
It works fine to add disk with virt-manager
--- Additional comment from dwu on 2010-06-30 05:29:02 EDT ---
The xml sections for the new attached disk with CLI and GUI are different.
Generated by GUI
<disk type="block" device="disk">
<source dev="/dev/disk1/Disk1"/>
<target dev="vda" bus="virtio"/>
</disk>
Generated by CLI
<disk type="block" device="disk">
<driver name="phy"/>
<source dev="/dev/disk1/Disk1"/>
<target dev="vda" bus="virtio"/>
</disk>
Virsh use phy as the default driver name if no driver specified in command line.
<snip>
if (driver) {
tmp = vshRealloc(ctl, tmp, strlen(driver) + 22);
if (!tmp) goto cleanup;
sprintf(tmp, " <driver name='%s'", driver);
} else {
tmp = vshRealloc(ctl, tmp, 25);
if (!tmp) goto cleanup;
sprintf(tmp, " <driver name='phy'");
}
</snip>
But when the function qemudBuildCommandLine in qemu_conf.c try to parse the config and build a command line for qemu, it only can recognize "qemu" as a driver name.
<snip>
if (disk->driverName != NULL &&
!STREQ(disk->driverName, "qemu")) {
qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
_("unsupported driver name '%s' for disk '%s'"),
disk->driverName, disk->src);
goto error;
}
</snip>
And for virsh, only file,tap and phy are valid, we can't specify "qemu" as a driver name in the command line. The upstream code also has this problem.
This is fixed upstream by 12a41822e14b558f7ffb4812978b957f3d228f23 and dfec22cc6035a95ff1c7609ea060029cb99182cc
This was fixed by the rebase and since there already is another bug tracking this issue, I'm closing this as a dup of it.
*** This bug has been marked as a duplicate of bug 627143 ***