mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-22 05:35:25 +00:00
virsh: Allow attach-disk to specify disk target bus
By default, the bus type is inferred from the style of the device name('target' in this command), e.g. a device named 'sda' will typically be exported using a SCSI bus. Actually, not only SCSI bus, but USB/SATA bus also use this kind of device name. So add '--bus' option for attach-disk command to allow user specify the target bus. Signed-off-by: Yanbing Du <ydu@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This commit is contained in:
parent
1cd8f500ee
commit
7e157858b4
@ -277,6 +277,10 @@ static const vshCmdOptDef opts_attach_disk[] = {
|
||||
.flags = VSH_OFLAG_REQ,
|
||||
.help = N_("target of disk device")
|
||||
},
|
||||
{.name = "targetbus",
|
||||
.type = VSH_OT_STRING,
|
||||
.help = N_("target bus of disk device")
|
||||
},
|
||||
{.name = "driver",
|
||||
.type = VSH_OT_STRING,
|
||||
.help = N_("driver of disk device")
|
||||
@ -502,7 +506,7 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd)
|
||||
const char *source = NULL, *target = NULL, *driver = NULL,
|
||||
*subdriver = NULL, *type = NULL, *mode = NULL,
|
||||
*cache = NULL, *serial = NULL, *straddr = NULL,
|
||||
*wwn = NULL;
|
||||
*wwn = NULL, *targetbus = NULL;
|
||||
struct DiskAddress diskAddr;
|
||||
bool isFile = false, functionReturn = false;
|
||||
int ret;
|
||||
@ -536,6 +540,7 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd)
|
||||
vshCommandOptStringReq(ctl, cmd, "serial", &serial) < 0 ||
|
||||
vshCommandOptStringReq(ctl, cmd, "wwn", &wwn) < 0 ||
|
||||
vshCommandOptStringReq(ctl, cmd, "address", &straddr) < 0 ||
|
||||
vshCommandOptStringReq(ctl, cmd, "targetbus", &targetbus) < 0 ||
|
||||
vshCommandOptStringReq(ctl, cmd, "sourcetype", &stype) < 0)
|
||||
goto cleanup;
|
||||
|
||||
@ -590,7 +595,11 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd)
|
||||
if (source)
|
||||
virBufferAsprintf(&buf, "<source %s='%s'/>\n",
|
||||
isFile ? "file" : "dev", source);
|
||||
virBufferAsprintf(&buf, "<target dev='%s'/>\n", target);
|
||||
virBufferAsprintf(&buf, "<target dev='%s'", target);
|
||||
if (targetbus)
|
||||
virBufferAsprintf(&buf, " bus='%s'", targetbus);
|
||||
virBufferAddLit(&buf, "/>\n");
|
||||
|
||||
if (mode)
|
||||
virBufferAsprintf(&buf, "<%s/>\n", mode);
|
||||
|
||||
|
@ -2089,17 +2089,21 @@ B<Note>: using of partial device definition XML files may lead to unexpected
|
||||
results as some fields may be autogenerated and thus match devices other than
|
||||
expected.
|
||||
|
||||
=item B<attach-disk> I<domain> I<source> I<target>
|
||||
[[[I<--live>] [I<--config>] | [I<--current>]] | [I<--persistent>]]
|
||||
[I<--driver driver>] [I<--subdriver subdriver>] [I<--cache cache>]
|
||||
[I<--type type>] [I<--mode mode>] [I<--sourcetype sourcetype>]
|
||||
[I<--serial serial>] [I<--wwn wwn>] [I<--rawio>]
|
||||
[I<--address address>] [I<--multifunction>] [I<--print-xml>]
|
||||
=item B<attach-disk> I<domain> I<source> I<target> [[[I<--live>] [I<--config>]
|
||||
| [I<--current>]] | [I<--persistent>]] [I<--targetbus bus>] [I<--driver
|
||||
driver>] [I<--subdriver subdriver>] [I<--cache cache>] [I<--type type>]
|
||||
[I<--mode mode>] [I<--sourcetype sourcetype>] [I<--serial serial>] [I<--wwn
|
||||
wwn>] [I<--rawio>] [I<--address address>] [I<--multifunction>] [I<--print-xml>]
|
||||
|
||||
Attach a new disk device to the domain.
|
||||
I<source> is path for the files and devices. I<target> controls the bus or
|
||||
device under which the disk is exposed to the guest OS. It indicates the
|
||||
"logical" device name. I<driver> can be I<file>, I<tap> or I<phy> for the Xen
|
||||
"logical" device name; the optional I<targetbus> attribute specifies the type
|
||||
of disk device to emulate; possible values are driver specific, with typical
|
||||
values being I<ide>, I<scsi>, I<virtio>, I<xen>, I<usb>, I<sata>, or I<sd>, if
|
||||
omitted, the bus type is inferred from the style of the device name (e.g. a
|
||||
device named 'sda' will typically be exported using a SCSI bus). I<driver> can
|
||||
be I<file>, I<tap> or I<phy> for the Xen
|
||||
hypervisor depending on the kind of access; or I<qemu> for the QEMU emulator.
|
||||
Further details to the driver can be passed using I<subdriver>. For Xen
|
||||
I<subdriver> can be I<aio>, while for QEMU subdriver should match the format
|
||||
|
Loading…
Reference in New Issue
Block a user