[libvirt] [RFC] Multi-IQN proposal
by Shyam_Iyer＠Dell.com
Would this proposal be acceptable ?
Example XML schema for an iSCSI storage pool created --
<pool type="iscsi">
<name>dell</name>
<uuid>cf354733-b01b-8870-2040-94888640e24d</uuid>
<capacity>0</capacity>
<allocation>0</allocation>
<available>0</available>
- <source>
<initiator iqnname = "<initiator IQN1>">
<initiator iqnname = "<initiator IQN2>">
........................................
........................................
<host name="<iSCSI target hostname or Target IP address>" />
<device path="<iSCSI Target IQN name>" />
</source>
- <target>
<path>/dev/disk/by-path</path>
- <permissions>
<mode>0700</mode>
<owner>0</owner>
<group>0</group>
</permissions>
</target>
</pool>
Each initiator iqn name can be parsed to create the unique sessions.
This should solve the following possibilities --
* possibility of multiple IQNs for a single Guest
* option for Guest's own BIOS & initiator to use these IQNs (iSCSI in
Guest)
* option for hypervisor's initiator to use these IQNs on behalf of the
guest
(Multi-IQN)
Compile tested only. Needs beatification.
diff --git a/src/storage_conf.c b/src/storage_conf.c
index cb063cc..915e897 100644
--- a/src/storage_conf.c
+++ b/src/storage_conf.c
@@ -116,6 +116,7 @@ enum {
VIR_STORAGE_POOL_SOURCE_DIR = (1<<2),
VIR_STORAGE_POOL_SOURCE_ADAPTER = (1<<3),
VIR_STORAGE_POOL_SOURCE_NAME = (1<<4),
+ VIR_STORAGE_POOL_SOURCE_INITIATOR_IQN = (1<<5),
};
@@ -537,6 +538,33 @@ virStoragePoolDefParseXML(virConnectPtr conn,
goto cleanup;
}
}
+
+/* Read the conf here */
+ if (options->flags & VIR_STORAGE_POOL_SOURCE_INITATOR_IQN) {
+ int niqn, i;
+
+ if ((niqn = virXPathNodeSet(conn, "./source/host/initiator",
ctxt, &nodeset)) < 0) {
+ virStorageReportError(conn, VIR_ERR_XML_ERROR,
+ "%s", _("cannot extract storage pool source
devices"));
+ goto cleanup;
+ }
+ if (VIR_ALLOC_N(ret->source.niqn, niqn) < 0) {
+ VIR_FREE(nodeset);
+ virReportOOMError(conn);
+ goto cleanup;
+ }
+ for (i = 0 ; i < niqn ; i++ ) {
+ xmlChar *name = xmlGetProp(nodeset[i], BAD_CAST "iqnname");
+ if (path == NULL) {
+ VIR_FREE(nodeset);
+ virStorageReportError(conn, VIR_ERR_XML_ERROR,
+ "%s", _("missing storage pool source device
path"));
+ goto cleanup;
+ }
+ ret->source.initiator[i].iqnname = (char *)name;
+ }
+ }
if (options->flags & VIR_STORAGE_POOL_SOURCE_DEVICE) {
xmlNodePtr *nodeset = NULL;
int nsource, i;
diff --git a/src/storage_conf.h b/src/storage_conf.h
index 421d305..c2504be 100644
--- a/src/storage_conf.h
+++ b/src/storage_conf.h
@@ -202,7 +202,12 @@ struct _virStoragePoolSourceDevice {
} geometry;
};
-
+/* Initiator Attributes */
+typedef virStoragePoolSourceInitiatorAttr
*virStoragePoolSourceInitiatorAttrPtr;
+struct virStoragePoolSourceInitiatorAttr {
+ char *iqnname;
+ /* We could put other initiator specific things here */
+}
typedef struct _virStoragePoolSource virStoragePoolSource;
typedef virStoragePoolSource *virStoragePoolSourcePtr;
@@ -214,6 +219,9 @@ struct _virStoragePoolSource {
int ndevice;
virStoragePoolSourceDevicePtr devices;
+ /*And either one or more initiators*/
+ virStoragePoolSourceInitiatorAttrPtr initiator;
+
/* Or a directory */
char *dir;
15 years, 1 month
[libvirt] Update libvirt API and refs XML files
by Matthias Bolte
Commit 47c8709564ac3f2ec5b4a3830ac213e69b4a44d5 "Fix up a few typos in
the tree" triggered changes in docs/libvirt-api.xml and
docs/libvirt-refs.xml. The attached patch contains this changes.
The files docs/libvirt-api.xml and docs/libvirt-refs.xml are generated
by apibuild.py, why are this generated files under version control?
Matthias
15 years, 1 month
[libvirt] [PATCH 00/11] Generic data stream handling
by Daniel P. Berrange
The following series of patches introduce support for generic data
streams in the libvirt API, the remote protocol, client & daemon.
The public API takes the form of a new object virStreamPtr and
methods to read/write/close it
The remote protocol was the main hard bit. Since the protocol
allows multiple concurrent API calls on a single connection,
this needed to also allow concurrent data streams. It is also
not acceptable for a large data stream to block other traffic
while it is transferring.
Thus, we introduce a new protocol message type 'REMOTE_STREAM'
to handle transfer for the stream data. A method involving a
data streams starts off in the normal way with a REMOTE_CALL
to the server, and a REMOTE_REPLY response message. If this
was successful, there now follows the data stream traffic.
For outgoing streams (data from client to server), the client
will send zero or more REMOTE_STREAM packets containing the
data with status == REMOTE_CONTINUE. These are asynchronous
and not acknowledged by the server. At any time the server
may send an async message with a type of REMOTE_STREAM and
status of REMOTE_ERROR. This indicates to the client that the
transfer is aborting at server request. If the client wishes
to abort, it can send the server a REMOTE_STREAM+REMOTE_ERROR
message. If the client finishes its data transfer, it will
send a final REMOTE_STREAM+REMOTE_OK message, and the server
will respond with the same. This full roundtrip handshake
ensures any async error messages are guarenteed to be flushed
For incoming data streams (data from server to client), the
server sends zero or more REMOTE_STREAM packets containing the
data with status == REMOTE_CONTINUE. These are asynchronous
and not acknowledged by the client. At any time the client
may send an async message with a type of REMOTE_STREAM and
status of REMOTE_ERROR. This indicates to the server that the
transfer is aborting at client request. If the server wishes
to abort, it can send the server a REMOTE_STREAM+REMOTE_ERROR
message. When the server finishes its data transfer, it will
send a final REMOTE_STREAM+REMOTE_CONTINUE message ewith a
data length of zero (ie EOF). The client will then send a
REMOTE_STREAM+REMOTE_OK packet and the server will respond
with the same. This full roundtrip handshake ensures any async
error messages are guarenteed to be flushed
This all ensures that multiple data streams can be active in
parallel, and with a maximum data packet size of 256 KB, no
single stream can cause too much latency on the connection for
other API calls/streams.
The only thing it does not allow for is one API method to use
two or more streams. These may be famous last words, but I
don't think that use case will be neccessary for any of our
APIs...
The last 5 patches with a subject of [DEMO] are *NOT* intended
to be committed to the repository. They merely demonstrate the
use of data streams for a couple of hypothetical file upload
and download APIs. Actually they were mostly to allow me to
test the code streams code without messing around with the QEMU
migration code.
The immediate use case for this data stream code is Chris' QEMU
migration patchset.
The next use case is to allow serial console access to be tunnelled
over libvirtd, eg to make 'virsh console GUEST' work remotely.
This use case is why I included the support for non-blocking data
streams and event loop integration (not required for Chris'
migration use case)
Anyway, assuming Chris confirms that I've not broken his code, then
patches 1-6 are targetted for this next release.
.x-sc_avoid_write | 3
include/libvirt/libvirt.h | 101 ++++
include/libvirt/libvirt.h.in | 101 ++++
po/POTFILES.in | 1
qemud/Makefile.am | 1
qemud/dispatch.c | 131 ++++++
qemud/dispatch.h | 17
qemud/event.c | 54 +-
qemud/qemud.c | 56 +-
qemud/qemud.h | 33 +
qemud/remote.c | 237 ++++++++++-
qemud/remote.h | 1
qemud/remote_dispatch_args.h | 2
qemud/remote_dispatch_prototypes.h | 153 +++++++
qemud/remote_dispatch_table.h | 10
qemud/remote_generate_stubs.pl | 1
qemud/remote_protocol.c | 18
qemud/remote_protocol.h | 20
qemud/remote_protocol.x | 57 ++
qemud/stream.c | 605 +++++++++++++++++++++++++++++
qemud/stream.h | 53 ++
src/datatypes.c | 59 ++
src/datatypes.h | 33 +
src/driver.h | 40 +
src/esx/esx_driver.c | 2
src/libvirt.c | 769 +++++++++++++++++++++++++++++++++++++
src/libvirt_private.syms | 2
src/libvirt_public.syms | 18
src/lxc_driver.c | 2
src/opennebula/one_driver.c | 2
src/openvz_driver.c | 2
src/qemu_driver.c | 2
src/remote_internal.c | 601 ++++++++++++++++++++++++++++
src/test.c | 477 ++++++++++++++++++++++
src/uml_driver.c | 2
src/vbox/vbox_tmpl.c | 3
src/virsh.c | 164 +++++++
src/xen_unified.c | 2
tests/eventtest.c | 19
39 files changed, 3783 insertions(+), 71 deletions(-)
Regards,
Daniel
15 years, 1 month
[libvirt] Tunnelled migration
by Chris Lalancette
At long last, now that the stream stuff is committed to the tree,
I can repost the tunnelled migration patches. Note that these
patches will conflict in some places with danpb's previously
posted "PEER2PEER" patches, but it should be easy to
resolve the differences.
V2: Rework the monitor patch to be an API
Use the new monitor API
Remove silly use of qemuEscapeMonitorArgs()
15 years, 1 month
[libvirt] Silently ignored virDomainRestore failures
by Charles Duffy
Howdy, all.
I maintain a test infrastructure which makes heavy use of virDomainSave
and virDomainRestore, and have been seeing occasional cases where my
saved images are for some reason not restored correctly -- and, indeed,
the incoming migration streams are not even read in their entirety.
While this generally appears to be caused by issues outside of libvirt's
purview, one unfortunate issue is that libvirt can report success
performing a restore even when the operation is effectively an abject
failure.
Consider the following snippet, taken from one of my
/var/log/libvirt/qemu/<domain>.log files:
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin USER=root LOGNAME=root
/usr/bin/qemu-kvm -S -M pc-0.11 -m 512 -smp 1 <...lots of arguments
here...> -incoming exec:cat
cat: write error: Broken pipe
This leaves a running qemu hosting a catatonic guest -- but the libvirt
client (connecting through the Python bindings) received a status of
success for the operation given here.
libvirt's mechanism for validating a successful restore consists of
running a "cont" command on the guest, and then checking
virGetLastError(); AIUI, it is expected that the "cont" will not be able
to run until the restore is completed, as the monitor should not be
responsive until that time. Browsing through qemudMonitorSendCont (and
qemudMonitorCommandWithHandler, which it calls), I don't see anything
which looks at the log file with the stderr output from qemu to
determine whether an error actually occurred. (As an aside, "info
history" on the guest's monitor socket indicates that it was indeed
issued this "cont").
Should the existing cont+virGetLastError() approach be sufficient to
handle this class of error? If not, is there any guidance on what would
comprise a better system? (I suppose we could add something to the exec:
to affirmatively indicate on stderr that the decompressor [or cat, if
not using one] exited successfully, and check for that marker in the log
file... but that seems quite a dirty hack).
Thanks!
15 years, 1 month
[libvirt] [PATCH 00/27] Refactor QEMU monitor command handling
by Daniel P. Berrange
In the QEMU driver source code the methods which talk to the QEMU
monitor currently all just call qemudMonitorCommand() directly
with the raw command string, and then parse the raw reply.
In the not too distant future QEMU is introducing a new machine
parsable monitor syntax. With the current way the code is structured
supporting this new mode will be seriously unpleasant.
This large series of patches, moves all the monitor command
formatting and parsing code out into a separate source file
src/qemu/qemu_monitor_text.c. There is one API in that file
for each logical monitor command we wish to issue, accepting
(mostly) strongly typed arguments. The exception is the NIC
hotplug method which still takes the raw NIC string for now.
The main qemu_driver.c file now directly calls the appropriate
monitor command APIs, making logic there much cleaner.
When we add support for the new QEMU monitor syntax we'll gain
another file src/qemu/qemu_monitor_json.c which implements all
the same APIs as src/qemu/qemu_monitor_text.c, but using the
new JSON syntax instead of raw text strings
This patch series is soooooo large, because I did it in many
small steps, one command at a time.
It is also now much easier to debug the monitor by just setting
the env variables
LIBVIRT_LOG_OUTPUTS="1:stderr" LIBVIRT_LOG_FILTERS="1:qemu_monitor"
And you'll get the command & reply of each monitor interaction
printed
I've tested basic handling of every new method with the exception
of the migration ones, since I don't have a convenient target host
when on my laptop.
Overall we get a small increase in code size, but huge increase
in readability !
Makefile.am | 1
libvirt_private.syms | 1
qemu/qemu_conf.c | 20
qemu/qemu_conf.h | 2
qemu/qemu_driver.c | 1669 +++++---------------------------------------
qemu/qemu_monitor_text.c | 1777 +++++++++++++++++++++++++++++++++++++++++++++++
qemu/qemu_monitor_text.h | 173 ++++
7 files changed, 2171 insertions(+), 1472 deletions(-)
Daniel
15 years, 1 month
[libvirt] [PATCH] Allows for a <description> tag for domains
by Daniel Veillard
https://bugzilla.redhat.com/show_bug.cgi?id=523639
feature request which makes sense to me, the simple patch attached
seems to be sufficient, one can define and have the description back
in the dump. Doesn't try to keep the location of the tag, it always
get serialized after <uuid>.
The only drawbacks I can think of are:
- others XML formats may require the same, but honnestly it's trivial
- machine generated description (for example if the history log of
a domain gets stored there) could grow a lot and I wonder if we
have a hard limit on the size when transmitting xml descriptions
Oh and I didn't found a good place to test the feature, i.e. no test
seems to parse and reserialize XML it's always about conversions.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
15 years, 1 month
[libvirt] [PATCH] Avoid a libvirtd crash on broken input 523418
by Daniel Veillard
A simple typo in an XML domain file could lead to a crash, because
we called STRPREFIX() on the looked up value without checking it was
non-null. Patch is trivial, and should go in but I wonder if we
shouldn't make those STR macros safer too like turning
#define STRPREFIX(a,b) (strncmp((a),(b),strlen((b))) == 0)
into
#define STRPREFIX(a,b) ((a) && (b) && (strncmp((a),(b),strlen((b))) == 0))
anyway I think we should apply the patch independently, without it
libvirtd crash, with it we get the proper error report:
[root@paphio ~]# virsh define RHEL-5.4-64.xml
18:32:21.982: warning : processCallDispatchReply:7570 : Method call
error
error: Failed to define domain from RHEL-5.4-64.xml
error: internal error No <source> 'dev' attribute specified with
<interface type='bridge'/>
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
15 years, 1 month
[libvirt] [PATCH] Fix USB device re-labelling
by Mark McLoughlin
A simple misplaced break out of a switch results in:
libvir: error : Failed to open file '/sys/bus/pci/devices/0000:00:54c./vendor': No such file or directory
libvir: error : Failed to open file '/sys/bus/pci/devices/0000:00:54c./device': No such file or directory
libvir: error : this function is not supported by the hypervisor: Failed to read product/vendor ID for 0000:00:54c.
when trying to passthrough a USB host device to qemu.
* src/security_selinux.c: fix a switch/break thinko
---
src/security/security_selinux.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c
index bdd9eb2..d08d502 100644
--- a/src/security/security_selinux.c
+++ b/src/security/security_selinux.c
@@ -492,12 +492,11 @@ SELinuxSetSecurityHostdevLabel(virConnectPtr conn,
ret = usbDeviceFileIterate(conn, usb, SELinuxSetSecurityUSBLabel, vm);
usbFreeDevice(conn, usb);
-
- break;
} else {
/* XXX deal with product/vendor better */
ret = 0;
}
+ break;
}
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI: {
--
1.6.2.5
15 years, 1 month
