[libvirt] Associate a LUN as disk with WWNN/WWPN
by Osier Yang
Hi, all
This is a rough thought about how to allow the user to associate
a LUN as disk with WWNN/WWPN. Never mind if some thought
is complete wrong, I'm complete new to this area. :-)
The initial idea was to introduce new XML for the vHBA which the
LUN which be assisned to in a domain XML, just like comment #2
of RHBZ# 543037:
<quote>
AFAIU libvirt needs a way to:
- Associate a virtual adapter WWN with a VM (in the VM xml)
- Learn to start a virtual adapter when the VM is started, and destroy the
adapter when the VM is stopped.
- Possibly a way to associate a WWN with a scsi pool, to start / stop a
virtual adapter with the pool.
</quote>
But afer thinking more, I'd think it might be not good idea:
As far as I could understand, the requirement of the BZ wants
a way to create/migrate a guest with NPIV. I'm goint to talk
create first,and migration then.
=== Creation
If we try to support this all inside libvirt, it means we need to
new XML for indicates the WWNN/WWPN of the vHBA or Physical HBA,
this is fine we can do it, though it's a bit annoyed where to add
it. The biggest problem is there is a race here, we can't known
the path of the LUN unless the storage admin assigned (zone / mask,
will already use assign for brevity) a LUN to the (v)HBA, and it
appears on host successfully. However, domain define/create doesn't
allow the disk source path be empty, except it's CDROM, or Floppy.
The works which need to be done before domain define should
be:
- If the user wants to create new vHBA.
1) auto-generate /or specify WWNN/WWPN (with Qumranet's OUI: 00-1A-4A)
2) allows to select fabric WWN, (to guide the choice of which FC
adapter to select for the Vport creation, assuming different
adapters connect to different fabrics)
3) create the vHBA with virNodeDeviceCreateXML API
4) Ask / prompt the user to ask the storage admin assigns the LUN
to the vHBA.
5) Waits for the LUN shows up on host (perhaps via storage pool
API)
6) Use the LUN's path (e.g.
/dev/disk/by-id/scsi-3600c0ff000d7a2a5d163ff4490100000000-part1)
as the disk source path.
- If the user wants to select a existed (v)HBA.
1), 2) and 3) are ommited
3) and 4) might be also ommited if there is a LUN already assigned
to the selected (v)HBA.
As we can see, there are lots of interaction. If we simply wants
to do all these work inside libvirt, we lose the user friendly
interaction, and just makes our life harder.
So, I would these work should be done in external / upper apps,
e.g. virt-manager, or Boxes in future. What libvirt needs to
do (as far as I could get):
1) support the fabric WWN in node device XML
2) may be we can do auto-generating the WWNN/WWPN inside libvirt
if they are not specified. But from a user's p.o.v, I'd see it
is in UI, but not in codes silently.
3) perhaps provides methods to get the (v)HBA's fabric's WWN?
=== Migration
If we do things as explained above for domain's creation, the disk
XML will be like:
<disk type='disk' device='disk'>
<driver name='qemu' type='raw'/>
<source
file='/dev/disk/by-id/scsi-3600c0ff000d7a2a5d163ff4490100000000-part1/'>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03
function='0x0'/>
</disk>
It's just similiar with disk which uses a normal disk image. So we needs
to something to indentify it's special, it's a LUN assigned to a (v)HBA.
Ways to do that in my mind are:
1) If we could find the WWNN/WWPN/fabricwwn by the LUN's path, (I'm not
sure if there is a good way yet), things will be much simpler, what
we need might be just a simple flag to tell the disk source path is
LUN assigned to (v)HBA. e.g.
<source file='$path_of_lun' type='fc_hba'/>
2) if there is no way to get the WWNN/WWPN/fabricwwn by LUN's path, we
might need the whole config of (v)HBA. e.g.
<souce protocol='fc' file='$path_of_lun'>
<hba>
<wwnn>$wwnn</wwnn>
<wwpn>$wwpn</wwpn>
<fabricwwn>$fabricwwn</fabricwwn>
</hba>
</source>
And then in virt-manager or Boxes, it needs to detect if there is disk
use FC LUN, if it's it should teach dest libvirt to create another vHBA,
and assign the same LUN to it. Then migration could do just as normal.
But problem of doing like so is the migration won't work anyway with
virsh.
Hmmm, /me thinking if it will be disireable to introduce hook support
for migration. Things will be much simpler if we support hooks?
Thoughts and Opinions?
Regards,
Osier
12 years, 12 months
[libvirt] [PATCH] virsh: correct return value error
by ajia＠redhat.com
From: Alex Jia <ajia(a)redhat.com>
The 'true' bool value should be 1, and false is 0.
https://bugzilla.redhat.com/show_bug.cgi?id=758590
Signed-off-by: Alex Jia <ajia(a)redhat.com>
---
tools/virsh.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 01da8e5..618b0c1 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -1745,7 +1745,7 @@ cmdDomblklist(vshControl *ctl, const vshCmd *cmd)
VIR_FREE(source);
}
- ret = 0;
+ ret = true;
cleanup:
VIR_FREE(disks);
--
1.7.1
12 years, 12 months
[libvirt] [PATCH] util: avoid null deref on qcowXGetBackingStore
by ajia＠redhat.com
From: Alex Jia <ajia(a)redhat.com>
Detected by Coverity. the only case is caller passes a NULL to 'format' variable,
then taking 'if (format)' false branch, the function qcow2GetBackingStoreFormat
will directly dereferences the NULL 'format' pointer variable.
Signed-off-by: Alex Jia <ajia(a)redhat.com>
---
src/util/storage_file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/util/storage_file.c b/src/util/storage_file.c
index f33ea74..ba9cfc5 100644
--- a/src/util/storage_file.c
+++ b/src/util/storage_file.c
@@ -333,7 +333,7 @@ qcowXGetBackingStore(char **res,
* between the end of the header (QCOW2_HDR_TOTAL_SIZE)
* and the start of the backingStoreName (offset)
*/
- if (isQCow2)
+ if (isQCow2 && format)
qcow2GetBackingStoreFormat(format, buf, buf_size, QCOW2_HDR_TOTAL_SIZE, offset);
return BACKING_STORE_OK;
--
1.7.1
12 years, 12 months
[libvirt] [PATCH 00/14] Cleanup node suspend code
by Daniel P. Berrange
This patch series does a large number of pretty small / trivial
cleanups of the recently committed node suspend code.
There are a few important changes though
- Patch 1 changes public API enum values
- Patch 3 changes the capabilities XML schema
- Patch 11 ensures we don't probe suspend info unles we need it
- Patch 14 fixes a bug
Obviously due to 1 & 3 we need to do this before the next release
12 years, 12 months
[libvirt] [libvirt-glib] gir: use libraries from build tree, not installed ones
by Christophe Fergeau
If we don't explicitly mention path to our uninstalled libraries
to g-ir-scanner, it will use installed libvirt-* libraries instead
of the ones we just built to run a binary during the generation of
the gir file. However this binary will have been compiled with the
uninstalled ones,
This is an issue if the installed libraries are not ABI compatible
with the uninstalled one, and will cause a compile failure because
the binary will fail to run.
This fix has been suggested by Colin Walters (gobject-introspection
maintainer).
---
libvirt-gobject/Makefile.am | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/libvirt-gobject/Makefile.am b/libvirt-gobject/Makefile.am
index 1e0f851..c4405f0 100644
--- a/libvirt-gobject/Makefile.am
+++ b/libvirt-gobject/Makefile.am
@@ -130,6 +130,8 @@ LibvirtGObject-1.0.gir: libvirt-gobject-1.0.la $(G_IR_SCANNER) Makefile.am
--include-uninstalled $(top_builddir)/libvirt-gconfig/LibvirtGConfig-1.0.gir \
--identifier-prefix=GVir \
--symbol-prefix=gvir \
+ --library=$(top_builddir)/libvirt-glib/libvirt-glib-1.0.la \
+ --library=$(top_builddir)/libvirt-gconfig/libvirt-gconfig-1.0.la \
--library=$(builddir)/libvirt-gobject-1.0.la \
--output $@ \
-I$(top_builddir) \
--
1.7.7.3
12 years, 12 months
[libvirt] [PATCH] virsh: Update docs for block related commands
by Osier Yang
commit 3ac26e26 allows to lookup the disk via both target name
and source path. But virsh documents were not updated.
---
tools/virsh.c | 15 ++++++++++-----
tools/virsh.pod | 14 +++++++++-----
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 27ecaf3..94b5478 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -1059,7 +1059,8 @@ static const vshCmdInfo info_domblkstat[] = {
static const vshCmdOptDef opts_domblkstat[] = {
{"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain name, id or uuid")},
- {"device", VSH_OT_DATA, VSH_OFLAG_REQ, N_("block device")},
+ {"device", VSH_OT_DATA, VSH_OFLAG_REQ, N_("Fully-qualified source path or unique "
+ "target name of the block device")},
{"human", VSH_OT_BOOL, 0, N_("print a more human readable output")},
{NULL, 0, 0, NULL}
};
@@ -1637,7 +1638,8 @@ static const vshCmdInfo info_domblkinfo[] = {
static const vshCmdOptDef opts_domblkinfo[] = {
{"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain name, id or uuid")},
- {"device", VSH_OT_DATA, VSH_OFLAG_REQ, N_("block device")},
+ {"device", VSH_OT_DATA, VSH_OFLAG_REQ, N_("Fully-qualified source path or unique target"
+ "name of the block device")},
{NULL, 0, 0, NULL}
};
@@ -5959,7 +5961,8 @@ static const vshCmdInfo info_block_pull[] = {
static const vshCmdOptDef opts_block_pull[] = {
{"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain name, id or uuid")},
- {"path", VSH_OT_DATA, VSH_OFLAG_REQ, N_("Fully-qualified path of disk")},
+ {"path", VSH_OT_DATA, VSH_OFLAG_REQ, N_("Fully-qualified source path or unique "
+ "target name of the disk")},
{"bandwidth", VSH_OT_DATA, VSH_OFLAG_NONE, N_("Bandwidth limit in MB/s")},
{NULL, 0, 0, NULL}
};
@@ -5983,7 +5986,8 @@ static const vshCmdInfo info_block_job[] = {
static const vshCmdOptDef opts_block_job[] = {
{"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain name, id or uuid")},
- {"path", VSH_OT_DATA, VSH_OFLAG_REQ, N_("Fully-qualified path of disk")},
+ {"path", VSH_OT_DATA, VSH_OFLAG_REQ, N_("Fully-qualified source path or unique"
+ "target name of the disk")},
{"abort", VSH_OT_BOOL, VSH_OFLAG_NONE, N_("Abort the active job on the speficied disk")},
{"info", VSH_OT_BOOL, VSH_OFLAG_NONE, N_("Get active job information for the specified disk")},
{"bandwidth", VSH_OT_DATA, VSH_OFLAG_NONE, N_("Set the Bandwidth limit in MB/s")},
@@ -6039,7 +6043,8 @@ static const vshCmdInfo info_block_resize[] = {
static const vshCmdOptDef opts_block_resize[] = {
{"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain name, id or uuid")},
- {"path", VSH_OT_DATA, VSH_OFLAG_REQ, N_("Fully-qualified path of block device")},
+ {"path", VSH_OT_DATA, VSH_OFLAG_REQ, N_("Fully-qualified source path or unique "
+ "target name of the block device")},
{"size", VSH_OT_INT, VSH_OFLAG_REQ, N_("New size of the block device in kilobytes, "
"the size must be integer")},
{NULL, 0, 0, NULL}
diff --git a/tools/virsh.pod b/tools/virsh.pod
index a5758f4..61951e6 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -569,14 +569,16 @@ image has been pulled, the disk no longer depends on the backing image.
It pulls data for the entire disk in the background, the process of the
operation can be checked with B<blockjob>.
-I<path> specifies fully-qualified path of the disk.
+I<path> specifies fully-qualified source path (<source file='name'/>) or
+unique target name (<target dev='name'/>) of the disk.
I<bandwidth> specifies copying bandwidth limit in Mbps.
=item B<blockjob> I<domain> I<path> [I<--abort>] [I<--info>] [I<bandwidth>]
Manage active block operations.
-I<path> specifies fully-qualified path of the disk.
+I<path> specifies fully-qualified source path (<source file='name'/>) or
+unique target name (<target dev='name'/>) of the disk.
If I<--abort> is specified, the active job on the specified disk will
be aborted.
If I<--info> is specified, the active job information on the specified
@@ -585,9 +587,11 @@ I<bandwidth> can be used to set bandwidth limit for the active job.
=item B<blockresize> I<domain> I<--path> I<--size>
-Resize a block device of domain while the domain is running, I<--path>
-specifies the absolute path of the block device, I<--size> specifies the
-new size in kilobytes
+Resize a block device of domain while the domain is running.
+
+I<path> specifies fully-qualified source path (<source file='name'/>) or
+unique target name (<target dev='name'/>) of the disk.
+I<--size> specifies the new size in kilobytes.
=item B<dominfo> I<domain-id>
--
1.7.7.3
12 years, 12 months
[libvirt] gdb works abnormally when debug the libvirt.
by ShaoHe Feng
When I to use gdb to check whether qemuMonitorJSONIOProcessEvent
processes the Event that I expect.
but the gdb works abnormally.
I list the the position of the source file by gdb. It is the correct
functionqemuMonitorJSONIOProcessEvent.
However I set break point on this position. then "info b", it is the
wrong function qemuMonitorJSONIOProcess.
I debug my libvirt on Ubuntu 11.10 this time.But I have set a break
point at this function on redhat 6.0 before, it can work well.
My gcc version is: gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
My gdb version is: GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
here is the info:
(gdb) list qemu/qemu_monitor_json.c:88
83 qemuMonitorJSONIOProcessEvent(qemuMonitorPtr mon,
84 virJSONValuePtr obj)
85 {
86 const char *type;
87 int i;
88 int findEventFlag = -1;
89 VIR_DEBUG("mon=%p obj=%p", mon, obj);
90
91 type = virJSONValueObjectGetString(obj, "event");
92 if (!type) {
(gdb) b qemu/qemu_monitor_json.c:88
Breakpoint 5 at 0x4a18d4: file qemu/qemu_monitor_json.c, line 88.
(gdb) info b
Num Type Disp Enb Address What
5 breakpoint keep y 0x00000000004a18d4 in
qemuMonitorJSONIOProcess at qemu/qemu_monitor_json.c:88
(gdb)
12 years, 12 months
[libvirt] [PATCH] build: fix typo in last patch
by Eric Blake
* src/remote_protocol-structs: Use correct RPC name.
---
Pushing under the build-breaker rule. Osier attempted to fix this
already, but added a typo.
src/remote_protocol-structs | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/remote_protocol-structs b/src/remote_protocol-structs
index 62c0248..927b6c6 100644
--- a/src/remote_protocol-structs
+++ b/src/remote_protocol-structs
@@ -2019,5 +2019,5 @@ enum remote_procedure {
REMOTE_PROC_DOMAIN_EVENT_DISK_CHANGE = 248,
REMOTE_PROC_DOMAIN_OPEN_GRAPHICS = 249,
REMOTE_PROC_NODE_SUSPEND_FOR_DURATION = 250,
- REMOTE_PROC_NODE_SUSPEND_FOR_DURATION = 251,
+ REMOTE_PROC_DOMAIN_BLOCK_RESIZE = 251,
};
--
1.7.7.3
12 years, 12 months
[libvirt] [PATCH] Fix leak build config file path
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
* src/libvirt.c: Free user directory path
---
src/libvirt.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index cdd111c..55ef743 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -974,8 +974,11 @@ virConnectConfigFile(void)
goto error;
if (virAsprintf(&path, "%s/.libvirt/libvirt.conf",
- userdir) < 0)
+ userdir) < 0) {
+ VIR_FREE(userdir);
goto no_memory;
+ }
+ VIR_FREE(userdir);
}
return path;
--
1.7.6.4
12 years, 12 months
