Re: [Libvir] Proposal for the storage API (for discussion only)
Daniel P. Berrange wrote: On Fri, Oct 19, 2007 at 01:35:25PM +0100, Richard W.M. Jones wrote: I think this is fair enough. The important part is to make sure that the sysadmin can configure it, and it doesn't make much difference whether we use scriptlets or just have configuration options. It depends on the level of configuration. I don't want the sysadmin to be configuring command line args directly. For any input XML metadata to the libvirt API, we should always run a pre-determined command argv. This is important to ensure that the same storage description results in the same underlying operations no matter what machine it is run on. This ensures that applications have a consistent API, and that people debugging bug reports don't have to worry about local modifications to the API's meaning. The sysadmin can define the configure the storage pools they wish to have available via the APIs we provide directly. Now, if we want the sys-admin to be able to provide specific command line tools, for storage then I'd suggest we add an explicit 'site local' storage pool type. A 'site local' pool type would simple hand all the operations off to sysadmin configured commands. This way, if they use the built in lvm, or file, or iscsi, or block device backends we know exactly what the results are going to be. If they use the 'site local' backend we know to expect the unexpected. Sure ... What I had in mind what that the sys admin should be able to enable and disable different back-ends, but the actual command line being used would be hidden within libvirt's C code. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: Patch Re: [Libvir] save and restore guest
Farkas Levente wrote: Daniel P. Berrange wrote: On Fri, Oct 19, 2007 at 01:56:10PM +0200, Farkas Levente wrote: Farkas Levente wrote: Daniel P. Berrange wrote: The save/restore capability is currently only available in the KVM-ified version of QEMU. We could make it try to save, and failing that destroy the guest. The xendomains scripts isn't a good model to emulate though. The autostart/kill functionality is part of the libvirt daemon itself. Any save/restore capability would be best integrated there for those who like to save and restore guest at libvirtd stop and start i attached a patch we use to for it. it's based on xen's sripts. LIBVIRTD_AUTO_ONLY still not implemented but the sysconfig file already contains it. if you like to set the default behavior to the current then set LIBVIRTD_RESTORE to false. imho it'd be useful to include in the upstream libvirtd too. and the patch:-) As I mentioned above, doing this in the init script is a bad idea because it does not interact well with domain autostart. The libvirt dameon itself will autostart domains when it starts. So you may be saving the guests at shutdown, but at the next boot any which are marked autostart will be started fresh the subsequent restore for them will fail since they are already running. Doing this all correctly requires doing it in the daemon not the initscript. yes, but currently it's not implemented:-( but if you don't autostart any guest (which is the current default) my patch at least working until it'll be implemented. The problem is that if we put in your patch, we add a set of configuration options which we'll have to keep supporting forever, even when the 'proper' solution is done (whatever that might be). Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: Patch Re: [Libvir] save and restore guest
Richard W.M. Jones wrote: Farkas Levente wrote: Daniel P. Berrange wrote: On Fri, Oct 19, 2007 at 01:56:10PM +0200, Farkas Levente wrote: Farkas Levente wrote: Daniel P. Berrange wrote: The save/restore capability is currently only available in the KVM-ified version of QEMU. We could make it try to save, and failing that destroy the guest. The xendomains scripts isn't a good model to emulate though. The autostart/kill functionality is part of the libvirt daemon itself. Any save/restore capability would be best integrated there for those who like to save and restore guest at libvirtd stop and start i attached a patch we use to for it. it's based on xen's sripts. LIBVIRTD_AUTO_ONLY still not implemented but the sysconfig file already contains it. if you like to set the default behavior to the current then set LIBVIRTD_RESTORE to false. imho it'd be useful to include in the upstream libvirtd too. and the patch:-) As I mentioned above, doing this in the init script is a bad idea because it does not interact well with domain autostart. The libvirt dameon itself will autostart domains when it starts. So you may be saving the guests at shutdown, but at the next boot any which are marked autostart will be started fresh the subsequent restore for them will fail since they are already running. Doing this all correctly requires doing it in the daemon not the initscript. yes, but currently it's not implemented:-( but if you don't autostart any guest (which is the current default) my patch at least working until it'll be implemented. The problem is that if we put in your patch, we add a set of configuration options which we'll have to keep supporting forever, even when the 'proper' solution is done (whatever that might be). i can argue with that any 0.x version should have to be compatible with any earlier versions. but at least i can use it until then:-) -- Levente Si vis pacem para bellum! -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: Patch Re: [Libvir] save and restore guest
On Mon, Oct 22, 2007 at 12:53:48PM +0200, Farkas Levente wrote: Richard W.M. Jones wrote: Farkas Levente wrote: Daniel P. Berrange wrote: As I mentioned above, doing this in the init script is a bad idea because it does not interact well with domain autostart. The libvirt dameon itself will autostart domains when it starts. So you may be saving the guests at shutdown, but at the next boot any which are marked autostart will be started fresh the subsequent restore for them will fail since they are already running. Doing this all correctly requires doing it in the daemon not the initscript. yes, but currently it's not implemented:-( but if you don't autostart any guest (which is the current default) my patch at least working until it'll be implemented. The problem is that if we put in your patch, we add a set of configuration options which we'll have to keep supporting forever, even when the 'proper' solution is done (whatever that might be). i can argue with that any 0.x version should have to be compatible with any earlier versions. There is simply no question of including this code in libvirt. It does work in the general case does not even get us incrementally towards the general case. Including a half-baked solution which we would need to throw out in the future start from scratch is not sustainable. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Re: Should we settle on one SSL implementation?
Bernardo Innocenti wrote: I remember this topic being discussed some time ago, but software is fluid and maybe it's time to respin the topic. It would seem a worthwhile goal to unify SSL/TLS implementations like we did for spell checkers. Or, if it turns out to be too hard, at least it would be nice to their pki files. I've asked whether we have a standard layout for /etc/pki before, but no one seems to know. We're now shipping no less than 4 different implementations of SSL: - openssl (OpenBSD's implementation) - nss (Netscape's implementation) - gnutls (LGPL implementation) - puretls (Java implementation) Make that at least five - ocaml-ocamlnet has a pure-OCaml SSL impl. I'm sure Perl Python probably have their own too. But which one should replace the others? When we implemented encryption in libvirt, we chose gnutls because it has excellent examples which allow you to actually write code to use it in a short period of time. The others have (or we perceived them to have) hideous, confusing or undocumented APIs. For a short while I documented the certificate management code in terms of the OpenSSL command line tools. But after I found out about 'certtool' (part of GnuTLS), I was able to rewrite that documentation and make it considerably simpler[1]. 'certtool' is a lot more sane than the OpenSSL stuff. Nevertheless, I don't think you're going to get rid of the competing SSL libraries. Rewriting code to use a different API is a lot of make-work that no one wants to do, and doesn't contribute much benefit to anyone. Rich. [1] http://libvirt.org/remote.html#Remote_certificates -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] PATCH: 0/4 Implement CDROM media change for QEMU/KVM driver
On Tue, Oct 16, 2007 at 09:46:10PM +0100, Daniel P. Berrange wrote: This series of patches provides CDROM media change for QEMU/KVM driver. It builds on the previous patch, incorporating the feedback everyone gave. I split the refactoring out from the main new feature patch hence the series of 4... okay, sorry it took so long ! 1-3 are refactoring patches, fine by me 4 is a very needed functionality, yes please ! So +1, definitely ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Small cleanup patch for Xen NUMA
xenHypervisorNodeGetCellsFreeMemory was calling xend to find the
number of cells on a node and keeping the information thereafter in
a static variable. This patch just move the lookup code in the xen_unified
driver, using the unified call (and hence the hypervisor instead of
xend rpc). Provides the same for CPUs. Also helps centralizing those
lookup in case Xen supports dynamic CPUs or cells in the future.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Index: src/xen_internal.c
===
RCS file: /data/cvs/libxen/src/xen_internal.c,v
retrieving revision 1.96
diff -u -p -r1.96 xen_internal.c
--- src/xen_internal.c 29 Sep 2007 18:37:47 - 1.96
+++ src/xen_internal.c 22 Oct 2007 15:01:56 -
@@ -3035,24 +3035,27 @@ xenHypervisorNodeGetCellsFreeMemory(virC
xen_op_v2_sys op_sys;
int i, j, ret;
xenUnifiedPrivatePtr priv;
-static int nbNodeCells = -1;
-virNodeInfo nodeInfo;
+int nbNodeCells;
+if (conn == NULL) {
+virXenErrorFunc (VIR_ERR_INVALID_ARG, __FUNCTION__,
+invalid argument, 0);
+return -1;
+}
-if (nbNodeCells == -1) {
-if (xenDaemonNodeGetInfo(conn, nodeInfo)) {
-virXenErrorFunc (VIR_ERR_XEN_CALL, __FUNCTION__,
- cannot determine actual number of cells,0);
-return -1;
-}
-nbNodeCells = nodeInfo.nodes;
+nbNodeCells = xenNbCells(conn);
+if (nbNodeCells 0) {
+ virXenErrorFunc (VIR_ERR_XEN_CALL, __FUNCTION__,
+cannot determine actual number of cells,0);
+ return(-1);
}
-if ((conn == NULL) || (maxCells 1) || (startCell = nbNodeCells)) {
+if ((maxCells 1) || (startCell = nbNodeCells)) {
virXenErrorFunc (VIR_ERR_INVALID_ARG, __FUNCTION__,
invalid argument, 0);
return -1;
}
+
/*
* Support only sys_interface_version =4
*/
Index: src/xen_unified.c
===
RCS file: /data/cvs/libxen/src/xen_unified.c,v
retrieving revision 1.24
diff -u -p -r1.24 xen_unified.c
--- src/xen_unified.c 15 Oct 2007 21:38:56 - 1.24
+++ src/xen_unified.c 22 Oct 2007 15:01:56 -
@@ -37,6 +37,9 @@
#include xs_internal.h
#include xm_internal.h
+static int
+xenUnifiedNodeGetInfo (virConnectPtr conn, virNodeInfoPtr info);
+
/* The five Xen drivers below us. */
static struct xenUnifiedDriver *drivers[XEN_UNIFIED_NR_DRIVERS] = {
[XEN_UNIFIED_HYPERVISOR_OFFSET] = xenHypervisorDriver,
@@ -64,6 +67,62 @@ xenUnifiedError (virConnectPtr conn, vir
errmsg, info, NULL, 0, 0, errmsg, info);
}
+/*
+ * Helper functions currently used in the NUMA code
+ * Those variables should not be accessed directly but through helper
+ * functions xenNbCells() and xenNbCpu() available to all Xen backends
+ */
+static int nbNodeCells = -1;
+static int nbNodeCpus = -1;
+
+/**
+ * xenNumaInit:
+ * @conn: pointer to the hypervisor connection
+ *
+ * Initializer for previous variables. We currently assume that
+ * the number of physical CPU and the numebr of NUMA cell is fixed
+ * until reboot which might be false in future Xen implementations.
+ */
+static void
+xenNumaInit(virConnectPtr conn) {
+virNodeInfo nodeInfo;
+int ret;
+
+ret = xenUnifiedNodeGetInfo(conn, nodeInfo);
+if (ret 0)
+return;
+nbNodeCells = nodeInfo.nodes;
+nbNodeCpus = nodeInfo.cpus;
+}
+
+/**
+ * xenNbCells:
+ * @conn: pointer to the hypervisor connection
+ *
+ * Number of NUMa cells present in the actual Node
+ *
+ * Returns the number of NUMA cells available on that Node
+ */
+int xenNbCells(virConnectPtr conn) {
+if (nbNodeCells 0)
+xenNumaInit(conn);
+return(nbNodeCells);
+}
+
+/**
+ * xenNbCpus:
+ * @conn: pointer to the hypervisor connection
+ *
+ * Number of NUMa cells present in the actual Node
+ *
+ * Returns the number of NUMA cells available on that Node
+ */
+int xenNbCpus(virConnectPtr conn) {
+if (nbNodeCpus 0)
+xenNumaInit(conn);
+return(nbNodeCpus);
+}
+
/*- Dispatch functions. -*/
/* These dispatch functions follow the model used historically
Index: src/xen_unified.h
===
RCS file: /data/cvs/libxen/src/xen_unified.h,v
retrieving revision 1.5
diff -u -p -r1.5 xen_unified.h
--- src/xen_unified.h 6 Jul 2007 15:11:22 - 1.5
+++ src/xen_unified.h 22 Oct 2007 15:01:56 -
@@ -116,6 +116,9 @@ struct _xenUnifiedPrivate {
typedef struct _xenUnifiedPrivate *xenUnifiedPrivatePtr;
+
+int xenNbCells(virConnectPtr conn);
+int
[Libvir] Re: Should we settle on one SSL implementation?
On Monday 22 October 2007 09:47:12 Richard W.M. Jones wrote: Nevertheless, I don't think you're going to get rid of the competing SSL libraries. Rewriting code to use a different API is a lot of make-work that no one wants to do, and doesn't contribute much benefit to anyone. This is true and not the aim of the crypto consolidation project. What we are aiming to do is create a --with-nss option for as many packages as feasible and then Fedora can use that in package building. We have also created an openssl compatible API to help ease the transition. -Steve -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH] finish NUMA code reorg, plug cpuset at creat time support
The following patch finishes the cleanup for NUMA parsing code:
- the cpuset parsing is moved to xml.c
- some comments and cleanups of the include
then add the output of a (cpus '...') line based on the /domain/vcpu/@cpuset
attributes, this is parsed and reserialized as ranges to avoid any possibility
of misinterpretation of say ^ or any special syntax we may want to add in
the future.
A few things to note:
- dependant on the tiny patch I sent earlier today
- if we notice that the set covers all CPU maybe we should
avoid outputing (cpus '...'), trivial to add
- mostly untested yet
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Index: src/xend_internal.c
===
RCS file: /data/cvs/libxen/src/xend_internal.c,v
retrieving revision 1.150
diff -u -p -r1.150 xend_internal.c
--- src/xend_internal.c 22 Oct 2007 13:06:15 - 1.150
+++ src/xend_internal.c 22 Oct 2007 16:31:17 -
@@ -1896,352 +1896,6 @@ sexpr_to_xend_node_info(struct sexpr *ro
}
/**
- * skipSpaces:
- * @str: pointer to the char pointer used
- *
- * Skip potential blanks, this includes space tabs, line feed,
- * carriage returns and also '\\' which can be erronously emitted
- * by xend
- */
-static void
-skipSpaces(const char **str) {
-const char *cur = *str;
-
-while ((*cur == ' ') || (*cur == '\t') || (*cur == '\n') ||
- (*cur == '\r') || (*cur == '\\')) cur++;
-*str = cur;
-}
-
-/**
- * parseNumber:
- * @str: pointer to the char pointer used
- *
- * Parse a number
- *
- * Returns the CPU number or -1 in case of error. @str will be
- * updated to skip the number.
- */
-static int
-parseNumber(const char **str) {
-int ret = 0;
-const char *cur = *str;
-
-if ((*cur '0') || (*cur '9'))
-return(-1);
-
-while ((*cur = '0') (*cur = '9')) {
-ret = ret * 10 + (*cur - '0');
- cur++;
-}
-*str = cur;
-return(ret);
-}
-
-/**
- * parseCpuNumber:
- * @str: pointer to the char pointer used
- * @maxcpu: maximum CPU number allowed
- *
- * Parse a CPU number
- *
- * Returns the CPU number or -1 in case of error. @str will be
- * updated to skip the number.
- */
-static int
-parseCpuNumber(const char **str, int maxcpu) {
-int ret = 0;
-const char *cur = *str;
-
-if ((*cur '0') || (*cur '9'))
-return(-1);
-
-while ((*cur = '0') (*cur = '9')) {
-ret = ret * 10 + (*cur - '0');
- if (ret maxcpu)
- return(-1);
- cur++;
-}
-*str = cur;
-return(ret);
-}
-
-#if 0 /* Not used yet */
-/**
- * saveCpuSet:
- * @conn: connection
- * @cpuset: pointer to a char array for the CPU set
- * @maxcpu: number of elements available in @cpuset
- *
- * Serialize the cpuset to a string
- *
- * Returns the new string NULL in case of error. The string need to be
- * freed by the caller.
- */
-static char *
-saveCpuSet(virConnectPtr conn, char *cpuset, int maxcpu)
-{
-virBufferPtr buf;
-char *ret;
-int start, cur;
-int first = 1;
-
-if ((cpuset == NULL) || (maxcpu = 0) || (maxcpu 10))
-return(NULL);
-
-buf = virBufferNew(1000);
-if (buf == NULL) {
- virXendError(conn, VIR_ERR_NO_MEMORY, _(allocate buffer));
- return(NULL);
-}
-cur = 0;
-start = -1;
-while (cur maxcpu) {
-if (cpuset[cur]) {
- if (start == -1)
- start = cur;
- } else if (start != -1) {
- if (!first)
- virBufferAdd(buf, ,, -1);
-else
- first = 0;
- if (cur == start + 1)
- virBufferVSprintf(buf, %d, start);
- else if (cur == start + 2)
- virBufferVSprintf(buf, %d,%d, start, cur - 1);
- else
- virBufferVSprintf(buf, %d-%d, start, cur - 1);
- start = -1;
- }
- cur++;
-}
-if (start != -1) {
- if (!first)
- virBufferAdd(buf, ,, -1);
- if (maxcpu == start + 1)
- virBufferVSprintf(buf, %d, start);
- else if (maxcpu == start + 2)
- virBufferVSprintf(buf, %d,%d, start, maxcpu - 1);
- else
- virBufferVSprintf(buf, %d-%d, start, maxcpu - 1);
-}
-ret = virBufferContentAndFree(buf);
-return(ret);
-}
-#endif
-
-/**
- * parseCpuSet:
- * @str: pointer to a CPU set string pointer
- * @sep: potential character used to mark the end of string if not 0
- * @cpuset: pointer to a char array for the CPU set
- * @maxcpu: number of elements available in @cpuset
- *
- * Parse the cpu set, it will set the value for enabled CPUs in the @cpuset
- * to 1, and 0 otherwise. The syntax allows coma separated entries each
- * can
[Libvir] [PATCH 4/5] docs: Remove duplicated qemu bridge example
Signed-off-by: Jim Paris [EMAIL PROTECTED] --- docs/format.html |6 +- docs/libvir.html |6 +- 2 files changed, 2 insertions(+), 10 deletions(-) diff --git a/docs/format.html b/docs/format.html index 8a519af..5553d10 100644 --- a/docs/format.html +++ b/docs/format.html @@ -274,11 +274,7 @@ support a variety of options:/polliUserspace SLIRP stack lt;source dev='br0'/gt; lt;target dev='vnet7'/gt; lt;mac address=11:22:33:44:55:66/gt; -lt;/interfacegt; lt;interface type='bridge'gt; - lt;source dev='br0'/gt; - lt;target dev='vnet7'/gt; - lt;mac address=11:22:33:44:55:66/gt; - lt;/interfacegt;/pre +lt;/interfacegt;/pre /li liGeneric connection to LAN pProvides a means for the administrator to execute an arbitrary script diff --git a/docs/libvir.html b/docs/libvir.html index be6f9bb..7eb8a5b 100644 --- a/docs/libvir.html +++ b/docs/libvir.html @@ -1008,11 +1008,7 @@ support a variety of options:/p lt;source dev='br0'/gt; lt;target dev='vnet7'/gt; lt;mac address=11:22:33:44:55:66/gt; -lt;/interfacegt; lt;interface type='bridge'gt; - lt;source dev='br0'/gt; - lt;target dev='vnet7'/gt; - lt;mac address=11:22:33:44:55:66/gt; - lt;/interfacegt;/pre +lt;/interfacegt;/pre /li liGeneric connection to LAN pProvides a means for the administrator to execute an arbitrary script -- 1.5.3.4 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] PATCH: Support NIC model selection for QEMU/KVM
Hi, Sometime between kvm-36 and kvm-46 I ran into problems with the default QEMU network card (ne2k-pci). Switching it fixed the problems, but libvirt doesn't support changing the NIC model. These patches add support for: interface nic model=rtl8139/ /interface which becomes qemu -net nic,model=rtl8139,mac=... By default, no model is appended to the qemu command line, as before. Documentation update some fixes are included too. -jim -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH 5/5] docs: Document nic model options for qemu
Signed-off-by: Jim Paris [EMAIL PROTECTED] --- docs/format.html |9 +++-- docs/libvir.html | 13 +++-- 2 files changed, 18 insertions(+), 4 deletions(-) diff --git a/docs/format.html b/docs/format.html index 5553d10..d73adb1 100644 --- a/docs/format.html +++ b/docs/format.html @@ -219,8 +219,13 @@ XML description is quite similar, here is a simple example:/pprelt;domain linetworking interface definitions definitions are somewhat different due to a different model from Xen see below/li /ulpexcept those points the options should be quite similar to Xen HVM -ones./ph3a name=Net1 id=Net1Networking options for QEmu and KVM (added in 0.2.0)/a/h3pThe networking support in the QEmu and KVM case is more flexible, and -support a variety of options:/polliUserspace SLIRP stack +ones./ph3a name=Net1 id=Net1Networking options for QEmu and KVM (added in 0.2.0)/a/h3pThe networking support in the QEmu and KVM case is more flexible. +Common options control how the interface is presented to the VM. For example:/ppre +lt;interface type='user'gt; + span style=color: #E5; background-color: #FFlt;mac address=11:22:33:44:55:66/gt;/span + span style=color: #E5; background-color: #FFlt;nic model=rtl8139/gt;/span +lt;/interfacegt;/prepSupported models for codenic model/code (added in ?.?.?) depend +on the architecture and can be found in the QEmu documentation./ppOn the host side, the network interface can be connected in a number of ways:/polliUserspace SLIRP stack pProvides a virtual LAN with NAT to the outside world. The virtual network has DHCP amp; DNS services and will give the guest VM addresses starting from code10.0.2.15/code. The default router will be diff --git a/docs/libvir.html b/docs/libvir.html index 7eb8a5b..7113b4a 100644 --- a/docs/libvir.html +++ b/docs/libvir.html @@ -951,8 +951,17 @@ ones./p h3a name=Net1Networking options for QEmu and KVM (added in 0.2.0)/a/h3 -pThe networking support in the QEmu and KVM case is more flexible, and -support a variety of options:/p +pThe networking support in the QEmu and KVM case is more flexible. +Common options control how the interface is presented to the VM. For example:/p +pre +lt;interface type='user'gt; + span style=color: #E5; background-color: #FFlt;mac address=11:22:33:44:55:66/gt;/span + span style=color: #E5; background-color: #FFlt;nic model=rtl8139/gt;/span +lt;/interfacegt;/pre +pSupported models for codenic model/code (added in ?.?.?) depend +on the architecture and can be found in the QEmu documentation./p + +pOn the host side, the network interface can be connected in a number of ways:/p ol liUserspace SLIRP stack pProvides a virtual LAN with NAT to the outside world. The virtual -- 1.5.3.4 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH 3/5] docs: Fix typo in QEMU network examples
Signed-off-by: Jim Paris [EMAIL PROTECTED] --- docs/format.html |8 docs/libvir.html |8 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/format.html b/docs/format.html index efdbcde..8a519af 100644 --- a/docs/format.html +++ b/docs/format.html @@ -230,7 +230,7 @@ support a variety of options:/polliUserspace SLIRP stack prelt;interface type='user'/gt;/pre pre lt;interface type='user'gt; - lt;mac address=11:22:33:44:55:66:/gt; + lt;mac address=11:22:33:44:55:66/gt; lt;/interfacegt; /pre /li @@ -253,7 +253,7 @@ support a variety of options:/polliUserspace SLIRP stack lt;interface type='network'gt; lt;source network='default'/gt; lt;target dev='vnet7'/gt; - lt;mac address=11:22:33:44:55:66:/gt; + lt;mac address=11:22:33:44:55:66/gt; lt;/interfacegt; /pre /li @@ -273,11 +273,11 @@ support a variety of options:/polliUserspace SLIRP stack lt;interface type='bridge'gt; lt;source dev='br0'/gt; lt;target dev='vnet7'/gt; - lt;mac address=11:22:33:44:55:66:/gt; + lt;mac address=11:22:33:44:55:66/gt; lt;/interfacegt; lt;interface type='bridge'gt; lt;source dev='br0'/gt; lt;target dev='vnet7'/gt; - lt;mac address=11:22:33:44:55:66:/gt; + lt;mac address=11:22:33:44:55:66/gt; lt;/interfacegt;/pre /li liGeneric connection to LAN diff --git a/docs/libvir.html b/docs/libvir.html index 22bb168..be6f9bb 100644 --- a/docs/libvir.html +++ b/docs/libvir.html @@ -964,7 +964,7 @@ support a variety of options:/p prelt;interface type='user'/gt;/pre pre lt;interface type='user'gt; - lt;mac address=11:22:33:44:55:66:/gt; + lt;mac address=11:22:33:44:55:66/gt; lt;/interfacegt; /pre /li @@ -987,7 +987,7 @@ support a variety of options:/p lt;interface type='network'gt; lt;source network='default'/gt; lt;target dev='vnet7'/gt; - lt;mac address=11:22:33:44:55:66:/gt; + lt;mac address=11:22:33:44:55:66/gt; lt;/interfacegt; /pre /li @@ -1007,11 +1007,11 @@ support a variety of options:/p lt;interface type='bridge'gt; lt;source dev='br0'/gt; lt;target dev='vnet7'/gt; - lt;mac address=11:22:33:44:55:66:/gt; + lt;mac address=11:22:33:44:55:66/gt; lt;/interfacegt; lt;interface type='bridge'gt; lt;source dev='br0'/gt; lt;target dev='vnet7'/gt; - lt;mac address=11:22:33:44:55:66:/gt; + lt;mac address=11:22:33:44:55:66/gt; lt;/interfacegt;/pre /li liGeneric connection to LAN -- 1.5.3.4 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH 2/5] qemu: specify nic model when invoking qemu
Signed-off-by: Jim Paris [EMAIL PROTECTED]
---
src/qemu_conf.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index c463ffb..c1260ed 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -1738,7 +1738,8 @@ int qemudBuildCommandLine(virConnectPtr conn,
while (net) {
char nic[100];
-if (snprintf(nic, sizeof(nic),
nic,macaddr=%02x:%02x:%02x:%02x:%02x:%02x,vlan=%d,
+if (snprintf(nic, sizeof(nic),
nic%s%s,macaddr=%02x:%02x:%02x:%02x:%02x:%02x,vlan=%d,
+ (net-model[0] ? ,model= : ), net-model,
net-mac[0], net-mac[1],
net-mac[2], net-mac[3],
net-mac[4], net-mac[5],
--
1.5.3.4
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH 1/5] qemu: Add nic model to XML format.
Signed-off-by: Jim Paris [EMAIL PROTECTED]
---
src/qemu_conf.c | 21 +
src/qemu_conf.h |2 ++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index f3b8f4e..c463ffb 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -644,6 +644,7 @@ static struct qemud_vm_net_def
*qemudParseInterfaceXML(virConnectPtr conn,
struct qemud_vm_net_def *net = calloc(1, sizeof(struct qemud_vm_net_def));
xmlNodePtr cur;
xmlChar *macaddr = NULL;
+xmlChar *model = NULL;
xmlChar *type = NULL;
xmlChar *network = NULL;
xmlChar *bridge = NULL;
@@ -687,6 +688,9 @@ static struct qemud_vm_net_def
*qemudParseInterfaceXML(virConnectPtr conn,
if ((macaddr == NULL)
(xmlStrEqual(cur-name, BAD_CAST mac))) {
macaddr = xmlGetProp(cur, BAD_CAST address);
+} else if ((model == NULL)
+ (xmlStrEqual(cur-name, BAD_CAST nic))) {
+model = xmlGetProp(cur, BAD_CAST model);
} else if ((network == NULL)
(net-type == QEMUD_NET_NETWORK)
(xmlStrEqual(cur-name, BAD_CAST source))) {
@@ -739,6 +743,21 @@ static struct qemud_vm_net_def
*qemudParseInterfaceXML(virConnectPtr conn,
qemudRandomMAC(net);
}
+if (model) {
+int len;
+
+if ((len = xmlStrlen(model)) = (QEMUD_MAX_MODEL_LEN-1)) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
+ NIC model type '%s' is too long, model);
+goto error;
+} else {
+strncpy(net-model, (char *)model, len);
+net-model[len] = '\0';
+}
+xmlFree(model);
+model = NULL;
+}
+
if (net-type == QEMUD_NET_NETWORK) {
int len;
@@ -872,6 +891,8 @@ static struct qemud_vm_net_def
*qemudParseInterfaceXML(virConnectPtr conn,
return net;
error:
+if (model)
+xmlFree(model);
if (network)
xmlFree(network);
if (address)
diff --git a/src/qemu_conf.h b/src/qemu_conf.h
index e1844da..d95871e 100644
--- a/src/qemu_conf.h
+++ b/src/qemu_conf.h
@@ -79,6 +79,7 @@ enum qemud_vm_net_type {
};
#define QEMUD_MAX_NAME_LEN 50
+#define QEMUD_MAX_MODEL_LEN 16
#define QEMUD_MAX_XML_LEN 4096
#define QEMUD_MAX_ERROR_LEN 1024
@@ -86,6 +87,7 @@ enum qemud_vm_net_type {
struct qemud_vm_net_def {
int type;
unsigned char mac[QEMUD_MAC_ADDRESS_LEN];
+char model[QEMUD_MAX_MODEL_LEN];
union {
struct {
char ifname[BR_IFNAME_MAXLEN];
--
1.5.3.4
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] PATCH: Support NIC model selection for QEMU/KVM
On Mon, Oct 22, 2007 at 04:33:40PM -0400, Daniel Veillard wrote: On Mon, Oct 22, 2007 at 03:44:38PM -0400, Jim Paris wrote: Hi, Sometime between kvm-36 and kvm-46 I ran into problems with the default QEMU network card (ne2k-pci). Switching it fixed the problems, but libvirt doesn't support changing the NIC model. These patches add support for: interface nic model=rtl8139/ /interface which becomes qemu -net nic,model=rtl8139,mac=... By default, no model is appended to the qemu command line, as before. Documentation update some fixes are included too. Hum, I would really prefer if we were able to identify the issue and fix it transparently for the user (for example by detecting the kvm version if possible) rather than add an option in the permanent data file just to make stuff work. I hope this is possible, but can't really tell. In Fedora/RHEL we simply switched Xen, QEMU and KVM to all use rtl8139 by defualt since ne2k is crap. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] PATCH: Support NIC model selection for QEMU/KVM
Daniel P. Berrange wrote: On Mon, Oct 22, 2007 at 04:33:40PM -0400, Daniel Veillard wrote: On Mon, Oct 22, 2007 at 03:44:38PM -0400, Jim Paris wrote: Hi, Sometime between kvm-36 and kvm-46 I ran into problems with the default QEMU network card (ne2k-pci). Switching it fixed the problems, but libvirt doesn't support changing the NIC model. These patches add support for: interface nic model=rtl8139/ /interface which becomes qemu -net nic,model=rtl8139,mac=... By default, no model is appended to the qemu command line, as before. Documentation update some fixes are included too. Hum, I would really prefer if we were able to identify the issue and fix it transparently for the user (for example by detecting the kvm version if possible) rather than add an option in the permanent data file just to make stuff work. I hope this is possible, but can't really tell. In Fedora/RHEL we simply switched Xen, QEMU and KVM to all use rtl8139 by defualt since ne2k is crap. Getting it fixed upstream might be best. We could also just have libvirt always append model=rtl8139, but I'd be concerned that we could break existing VMs for some users if we swap out the network card unexpectedly. An upstream change would have the same problem. Regardless of what the defaults are, I don't think exposing a knob that lets you control what NIC the guest sees is that much of a hack; describing the guest hardware is what the config xml is mostly for. -jim -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH] Fix failure of HVM domain definition on Xen 3.0.3 or earlier(BZ328841)
Hi VirDomainDefineXML() fails, when HVM domain using CD-ROM is created on Xen 3.0.3 or earlier. --BZ328841(https://bugzilla.redhat.com/show_bug.cgi?id=328841) One of attached patches (define.patch) fixes it. But, when domain is started by virsh start using the configuration file created by fixing this, the problem that the CD-ROM device is missed occurs. So, another patch (start.patch) fixes this problem. Signed-off-by: Masayuki Sunou [EMAIL PROTECTED] Thanks, Masayuki Sunou. define.patch Description: Binary data start.patch Description: Binary data -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
