[Libvir] libvirt statistics
[Using `pahole' and friends - see http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git;a=summary and https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf ] These are all on x86-64. You'll get slightly different results on a 32 bit arch. Largest structures, by size: qemud_vm_def: 16608 4 qemud_vm_os_def: 16436 1 _testConn: 14504 2 qemud_vm: 12368 2 qemud_network: 8240 0 qemud_vm_disk_def: 4376 2 qemud_driver: 4192 1 qemud_vm_net_def: 4136 2 xenXMConfCache: 4112 0 _virProxyFullPacket: 4096 0 _xmlParserCtxt: 696 5 _virDriver: 432 1 utsname: 390 0 _testDom: 360 0 _xmlXPathContext: 352 4 xenUnifiedDriver: 328 0 dirent: 280 0 _xmlSAXHandler: 256 1 _IO_FILE: 216 2 _xenUnifiedPrivate: 192 1 qemud_network_def: 192 2 _xmlDoc: 168 2 _virConnect: 168 0 _testNet: 156 0 Structures with holes which could be made smaller by packaging (third number is how many bytes you'd save per allocation): qemud_vm 12368 12360 8 qemud_vm_def 16608 16600 8 private_data5648 8 remote_domain_get_info_ret 4032 8 XDR 4840 8 xen_v0_vcpuinfo 4032 8 _xmlValidCtxt 112 104 8 _xmlEntity 136 128 8 _xmlParserCtxt 696 67224 _testConn14504 14496 8 _xmlURI 8072 8 _xmlXPathObject 725616 _xmlXPathParserContext 8072 8 _xmlXPathContext 352 33616 _xmlError 8880 8 _xmlAttr9688 8 _xmlDoc168 160 8 _xmlNode 120 112 8 _IO_FILE 216 208 8 _virDomainInfo 4032 8 Longest functions (NB: long functions are not a bad thing -- read Steve McConnell). qemudParseVMDef: 9680 doRemoteOpen: 6631 xenXMParseXMLToConfig: 5678 xenXMDomainFormatXML: 5678 xend_parse_sexp_desc: 5424 qemudBuildCommandLine: 5204 virDomainParseXMLDesc: 3503 qemudGenerateXML: 2556 __virErrorMsg: 2332 testOpenFromFile: 2210 call: 2206 qemudStartNetworkDaemon: 2105 virDomainParseXMLOSDescHVM: 2078 qemudParseNetworkDef: 2023 xenHypervisorMakeCapabilitiesXML: 1838 virDomainParseXMLDiskDesc: 1686 qemudStartVMDaemon: 1683 xenXMConfigCacheRefresh: 1547 xenXMParseXMLDisk: 1545 virConfParseValue: 1516 virConfParse: 1457 qemudScanConfigDir: 1396 testLoadNetwork: 1353 dhcpStartDhcpDaemon: 1259 virXen_getvcpusinfo: 1257 testLoadDomain: 1244 qemudDomainSave: 1194 virDomainParseXMLIfDesc: 1164 xenHypervisorInit: 1104 xenXMDomainDefineXML: 1083 iptablesAddRemoveRule: 1081 testOpen: 1075 Functions with the most variables (perhaps a better indicator of complexity, I know that doRemoteOpen is a bloody complicated function for example): xenXMDomainFormatXML: 18 virDomainParseXMLDesc: 18 doRemoteOpen: 18 testLoadDomain: 17 xenHypervisorMakeCapabilitiesXML: 16 testLoadNetwork: 15 xenXMParseXMLDisk: 14 xenStoreLookupByName: 13 xend_parse_sexp_desc: 13 virDomainParseXMLDiskDesc: 13 testOpenFromFile: 12 qemudBuildCommandLine: 12 xenStoreDomainGetNetworkID: 10 xenDaemonDomainGetVcpus: 10 virDomainParseXMLOSDescHVM: 10 qemudParseInterfaceXML: 10 xenXMParseXMLVif: 9 xenXMParseXMLToConfig: 9 xenXMDomainDefineXML: 9 query_parse: 9 iptablesAddRemoveRule: 9 xenStoreListDomains: 8 xenHypervisorLookupDomainByUUID: 8 xenHypervisorInit: 8 xenDaemonListDomainsOld: 8 virDomainParseXMLOSDescPV: 8 virDomainParseXMLIfDesc: 8 testNetworkDumpXML: 8 testDomainDumpXML: 8 qemudNetworkIfaceConnect: 8 qemudGenerateXML: 8 qemudDomainSave: 8 Functions with more than one goto label: qemudAddIptablesRules: 10 doRemoteOpen: 4 xenDaemonOpen: 3 qemudStartNetworkDaemon: 3 qemudExtractVersionInfo: 3 xenXMDomainFormatXML: 2 xenHypervisorInit: 2 xend_parse_sexp_desc: 2 virParseXMLDevice: 2 __virGetNetwork: 2 __virGetDomain: 2 virDomainXMLDevID: 2 remoteForkDaemon: 2 query_parse: 2 qemudStartup: 2 qemudNetworkIfaceConnect: 2 qemudGenerateXML: 2 qemudBuildCommandLine: 2 negotiate_gnutls_on_connection: 2 Functions with the most parameters (in C these are dangerous because of C's lousy typechecking): __virRaiseError: 12 xenXMConfigSetIntFromXPath: 8 xenUnifiedDomainMigratePrepare: 8 xenDaemonDomainMigratePrepare: 8 __virDomainMigratePrepare: 8 remoteDomainMigratePrepare: 8 qemudReadMonitorOutput: 8 call: 8 xenXMConfigSetStringFromXPath: 7 xenUnifiedDomainMigratePerform: 7 xenDaemonDomainMigratePerform: 7 _virExec: 7 __virDomainMigratePerform: 7 remoteDomainMigratePerform: 7 xenUnifiedDomainMigrateFinish: 6 xend_op_ext2: 6 virXen_getvcpusinfo: 6 virExecNonBlock: 6 virExec: 6 virDomainParseXMLOSDescHVM: 6 __virDomainMigrateFinish: 6 virDomainMigrate: 6 remoteDomainMigrateFinish: 6 All global variables (nothing wrong with global variables, I say):
Re: [Libvir] feature sujestions
Thank you for your sujestions. In the coming months, I will be working in integrating Cobbler with virt-manager. I will be posting my progress here as soon as I can. Thanks again for your support. MB On 8/24/07, David Lutterkort [EMAIL PROTECTED] wrote: On Thu, 2007-08-23 at 13:17 -0400, Daniel Veillard wrote: I agree we need something along those lines, and IMHO if they are more comfortable using point and click, I guess they would also prefer have automatic discovery of where cobbler was installed. Do we have (or could add) avahi support for discovery of the service. If most install options could be centralized (think like an automatic setup template based for example on the user LDAP info), provisioning for a new user could come as simple an UI as: A centralized setting si available, pick one of the OSes Fedora 7 Fedora 6 Centos 5 ... maybe even the processor count and memory size could be defaulted from the centalized profiles. Along the same lines: enhance virt-manager to support deploying virtual machine images based on virt-image and its XML image format. There are lots of possible ways in which this could go, for example: * Focus on UI, build VM's based on images stored locally/in a fixed directory * Build above out to download images from a central server (or any webserver, which would aid in distribution of images) * Freeze an existing/running VM into an image * p2v migration that takes a physical installation and produces a VM image (even something simple that just scrapes bits off disk and packages them w/o worrying too much about device complications would be really valuable) * Tracking of image/machine association (think template images for a development group that they can 'check out' and use) David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Computers are useless; they can only give you answers! -- Picasso -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] libvirt statistics
Hi, On Thu, Sep 06, 2007 at 02:10:39PM +0100, Richard W.M. Jones wrote: [Using `pahole' and friends - see http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git;a=summary and https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf ] These are all on x86-64. You'll get slightly different results on a 32 bit arch. Largest structures, by size: qemud_vm_def: 16608 4 qemud_vm_os_def: 16436 1 _testConn: 14504 2 snip What is the second field here? Structures with holes which could be made smaller by packaging (third number is how many bytes you'd save per allocation): snip _xmlValidCtxt 112 104 8 _xmlEntity 136 128 8 _xmlParserCtxt 696 67224 _testConn14504 14496 8 _xmlURI 8072 8 _xmlXPathObject 725616 _xmlXPathParserContext 8072 8 _xmlXPathContext 352 33616 _xmlError 8880 8 _xmlAttr9688 8 _xmlDoc168 160 8 _xmlNode 120 112 8 Are those defined by libxml, or are they from the libvirt code? Functions with the most parameters (in C these are dangerous because of C's lousy typechecking): __virRaiseError: 12 12 parameters, wow! All global variables (nothing wrong with global variables, I say): extern unsigned int __invalid_size_argument_for_IOC; /* 0 */ Doesn't seem to be from libvirt code. struct qemu_feature_flags arch_info_i686_flags[4]; /* 0 */ struct qemu_feature_flags arch_info_x86_64_flags[3]; /* 0 */ struct qemud_driver * qemu_driver; /* 0 */ struct qemu_arch_info qemudArchs[7]; /* 1 */ Not many. The arrays smell like constant data, that wouldn't be a Bad Thing being global. Some may be made static, however. extern struct _IO_FILE * stderr; /* 9 */ extern struct _IO_FILE * stdin; /* 23 */ extern struct _IO_FILE * stdout; /* 23 */ System variables. enum /**/ virDrvOpenRemoteFlags; /* 0 */ I think this was supposed to be a type definition. The variable is never used. struct xenUnifiedDriverxenDaemonDriver; /* 1 */ struct xenUnifiedDriverxenHypervisorDriver; /* 1 */ struct xenUnifiedDriverxenProxyDriver; /* 1 */ struct xenUnifiedDriverxenStoreDriver; /* 1 */ struct xenUnifiedDriverxenXMDriver; /* 1 */ Those seem to work like class definitions, so they are not a Bad Thing, too. extern xmlFreeFuncxmlFree; /* 3 */ extern xmlMallocFunc xmlMalloc; /* 0 */ Not from libvirt code. -- Eduardo pgpZaw5ww4LAw.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] libvirt statistics
On Thu, Sep 06, 2007 at 02:10:39PM +0100, Richard W.M. Jones wrote: [Using `pahole' and friends - see http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git;a=summary and https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf ] These are all on x86-64. You'll get slightly different results on a 32 bit arch. Largest structures, by size: qemud_vm_def: 16608 4 qemud_vm_os_def: 16436 1 _testConn: 14504 2 qemud_vm: 12368 2 qemud_network: 8240 0 qemud_vm_disk_def: 4376 2 qemud_driver: 4192 1 qemud_vm_net_def: 4136 2 xenXMConfCache: 4112 0 Hmm, practically all of those large structs come from the statically allocated char arrays of PATH_MAX. Switching them to be malloc'd would save far more than packing the structs. 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] libvirt statistics
Eduardo Habkost wrote: Hi, On Thu, Sep 06, 2007 at 02:10:39PM +0100, Richard W.M. Jones wrote: [Using `pahole' and friends - see http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git;a=summary and https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf ] These are all on x86-64. You'll get slightly different results on a 32 bit arch. Largest structures, by size: qemud_vm_def: 16608 4 qemud_vm_os_def: 16436 1 _testConn: 14504 2 snip What is the second field here? Good question! I had to look at the source code and it turns out the the second numeric field is the number of holes. Structures with holes which could be made smaller by packaging (third number is how many bytes you'd save per allocation): snip _xmlValidCtxt 112 104 8 _xmlEntity 136 128 8 _xmlParserCtxt 696 67224 _testConn14504 14496 8 _xmlURI 8072 8 _xmlXPathObject 725616 _xmlXPathParserContext 8072 8 _xmlXPathContext 352 33616 _xmlError 8880 8 _xmlAttr9688 8 _xmlDoc168 160 8 _xmlNode 120 112 8 Are those defined by libxml, or are they from the libvirt code? They're in libxml2. The way that the dwarves programs work is they consider the whole program or shared library, everything it contains and all dependent libraries down to libc. enum /**/ virDrvOpenRemoteFlags; /* 0 */ I think this was supposed to be a type definition. The variable is never used. Yes, it's a bug! Patch coming up ... 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: [Libvir] Extending libvirt to probe NUMA topology
Daniel Veillard wrote: 1) Provide a function describing the topology as an XML instance: char * virNodeGetTopology(virConnectPtr conn); which would return an XML instance as in virConnectGetCapabilities. I toyed with the idea of extending virConnectGetCapabilities() to add a topology section in case of NUMA support at the hypervisor level, but it was looking to me that the two might be used at different times and separating both might be a bit cleaner, but I could be convinced otherwise. I'd definitely prefer to extend virConnectGetCapabilities XML. It avoids changing the remote driver and language bindings, and really callers only need to pull capabilities once per connection. - topology cells num='2' cell id='0' cpus num='2' cpu id='0'/ cpu id='1'/ /cpus memory size='2097152'/ /cell cell id='1' cpus num='2' cpu id='2'/ cpu id='3'/ /cpus memory size='2097152'/ /cell /cells /topology - A few things to note: - the cells element list the top sibling cells Not nodes? - the cell element describes as child the resources available like the list of CPUs, the size of the local memory, that could be extended by disk descriptions too disk dev='/dev/sdb'/ and possibly other special devices (no idea what ATM). - in case of deeper hierarchical topology one may need to be able to name sub-cells and the format could be extended for example as cells num='2' cells num='2' cell id='1' ... /cell cell id='2' ... /cell /cells cells num='2' cell id='3' ... /cell cell id='4' ... /cell /cells /cells But that can be discussed/changed when the need arise :-) Especially note that 4 (or more) socket AMDs have a topology like this, with two different penalties for reaching nodes which are one and two hops away. Do we have a way to describe the penalties along different paths? 2) Function to get the free memory of a given cell: unsigned long virNodeGetCellFreeMemory(virConnectPtr conn, int cell); that's relatively simple, would match the request from the initial mail but I'm wondering a bit. If the program tries to do a best placement it will usually run that request for a number of cells no ? Maybe a call returning the memory amounts for a range of cells would be more appropriate. Yes, I guess they'd want to get the free memory for all nodes. But IBM will have a better idea about this. 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
[Libvir] [PATCH] Fix enum virDrvOpenRemoteFlags
(Thanks Eduardo for pointing this one out ...)
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
Index: src/remote_internal.c
===
RCS file: /data/cvs/libvirt/src/remote_internal.c,v
retrieving revision 1.21
diff -u -p -r1.21 remote_internal.c
--- src/remote_internal.c 21 Aug 2007 10:08:12 - 1.21
+++ src/remote_internal.c 6 Sep 2007 14:56:43 -
@@ -230,12 +230,12 @@ remoteForkDaemon(virConnectPtr conn)
/* Must not overlap with virDrvOpenFlags */
-enum {
+enum virDrvOpenRemoteFlags {
VIR_DRV_OPEN_REMOTE_RO = (1 0),
VIR_DRV_OPEN_REMOTE_UNIX = (1 1),
VIR_DRV_OPEN_REMOTE_USER = (1 2),
VIR_DRV_OPEN_REMOTE_AUTOSTART = (1 3),
-} virDrvOpenRemoteFlags;
+};
static int
doRemoteOpen (virConnectPtr conn, struct private_data *priv, const char *uri_str, int flags)
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] Extending libvirt to probe NUMA topology
On Thu, Sep 06, 2007 at 03:40:23PM +0100, Richard W.M. Jones wrote: Daniel Veillard wrote: 1) Provide a function describing the topology as an XML instance: char *virNodeGetTopology(virConnectPtr conn); which would return an XML instance as in virConnectGetCapabilities. I toyed with the idea of extending virConnectGetCapabilities() to add a topology section in case of NUMA support at the hypervisor level, but it was looking to me that the two might be used at different times and separating both might be a bit cleaner, but I could be convinced otherwise. I'd definitely prefer to extend virConnectGetCapabilities XML. It avoids changing the remote driver and language bindings, and really callers only need to pull capabilities once per connection. yeah, I understand that concern, simplifies a lot of stuff inside, but the goal at the library level is to simplify the user code even if that means a more complex implementation. However if people think they don't need a separate call then I'm really fine with this. - topology cells num='2' cell id='0' cpus num='2' cpu id='0'/ cpu id='1'/ /cpus memory size='2097152'/ /cell cell id='1' cpus num='2' cpu id='2'/ cpu id='3'/ /cpus memory size='2097152'/ /cell /cells /topology - A few things to note: - the cells element list the top sibling cells Not nodes? A Node in libvirt terminology is a single physical machine, cell is a weel accepted term I think for a sub-node within a NUMA box. - the cell element describes as child the resources available like the list of CPUs, the size of the local memory, that could be extended by disk descriptions too disk dev='/dev/sdb'/ and possibly other special devices (no idea what ATM). - in case of deeper hierarchical topology one may need to be able to name sub-cells and the format could be extended for example as cells num='2' cells num='2' cell id='1' ... /cell cell id='2' ... /cell /cells cells num='2' cell id='3' ... /cell cell id='4' ... /cell /cells /cells But that can be discussed/changed when the need arise :-) Especially note that 4 (or more) socket AMDs have a topology like this, with two different penalties for reaching nodes which are one and two hops away. Do we have a way to describe the penalties along different paths? As hinted in my mail, I think the access costs will have to be added separately and probably as a array map, unless people come with a more intelligent way of exposing those informations. 2) Function to get the free memory of a given cell: unsigned long virNodeGetCellFreeMemory(virConnectPtr conn, int cell); that's relatively simple, would match the request from the initial mail but I'm wondering a bit. If the program tries to do a best placement it will usually run that request for a number of cells no ? Maybe a call returning the memory amounts for a range of cells would be more appropriate. Yes, I guess they'd want to get the free memory for all nodes. But IBM will have a better idea about this. Well I'm looking for feedback :-) 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
Re: [Libvir] [PATCH] Fix enum virDrvOpenRemoteFlags
On Thu, Sep 06, 2007 at 03:53:57PM +0100, Richard W.M. Jones wrote:
(Thanks Eduardo for pointing this one out ...)
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
Index: src/remote_internal.c
===
RCS file: /data/cvs/libvirt/src/remote_internal.c,v
retrieving revision 1.21
diff -u -p -r1.21 remote_internal.c
--- src/remote_internal.c 21 Aug 2007 10:08:12 - 1.21
+++ src/remote_internal.c 6 Sep 2007 14:56:43 -
@@ -230,12 +230,12 @@ remoteForkDaemon(virConnectPtr conn)
/* Must not overlap with virDrvOpenFlags */
-enum {
+enum virDrvOpenRemoteFlags {
VIR_DRV_OPEN_REMOTE_RO = (1 0),
VIR_DRV_OPEN_REMOTE_UNIX = (1 1),
VIR_DRV_OPEN_REMOTE_USER = (1 2),
VIR_DRV_OPEN_REMOTE_AUTOSTART = (1 3),
-} virDrvOpenRemoteFlags;
+};
static int
doRemoteOpen (virConnectPtr conn, struct private_data *priv, const char
*uri_str, int flags)
Sure, +1 !
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] [PATCH] Allow modifying existing block device, making virDomainAttachDevice modify the device if it already exists
The attached patch adds code to xend_internal.c:xenDomainAttachDevice
that checks to see if the device mentioned in the passed-in XML already
exists, and if so calls op_device_configure to modify the device. It is
particularly useful for connecting and disconnecting a hardware cdrom
device to an FV guest.
I considered making new API a la virDomainModifyDevice, but decided
overloading virDomainAttachDevice was cleaner (and didn't change
existing API).
I have tested the patch on f7 with xen 3.1 and a windows 2000 guest.
Since the patch merely wraps Xen's device_configure call, we're not
adding much risk of breakage.
Please ACK.
Take care,
--Hugh
--
Red Hat Virtualization Group http://redhat.com/virtualization
Hugh Brock | virt-manager http://virt-manager.org
[EMAIL PROTECTED]| virtualization library http://libvirt.org
diff -ruN libvirt.orig/src/xend_internal.c libvirt/src/xend_internal.c
--- libvirt.orig/src/xend_internal.c 2007-09-06 11:28:05.0 -0400
+++ libvirt/src/xend_internal.c 2007-09-06 10:47:25.0 -0400
@@ -3087,6 +3087,7 @@
char *sexpr, *conf, *str;
int hvm = 0, ret;
xenUnifiedPrivatePtr priv;
+char class[8], ref[80];
if ((domain == NULL) || (domain-conn == NULL) || (domain-name == NULL)) {
virXendError((domain ? domain-conn : NULL), VIR_ERR_INVALID_ARG,
@@ -3116,8 +3117,16 @@
*(conf + strlen(conf) -1) = 0; /* suppress final ) */
}
else conf = sexpr;
-ret = xend_op(domain-conn, domain-name, op, device_create,
-config, conf, NULL);
+if (virDomainXMLDevID(domain, xml, class, ref)) {
+/* device doesn't exist, define it */
+ret = xend_op(domain-conn, domain-name, op, device_create,
+ config, conf, NULL);
+}
+else {
+/* device exists, attempt to modify it */
+ret = xend_op(domain-conn, domain-name, op, device_configure,
+ config, conf, dev, ref, NULL);
+}
free(sexpr);
return ret;
}
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] Allow modifying existing block device, making virDomainAttachDevice modify the device if it already exists
On Thu, Sep 06, 2007 at 11:45:39AM -0400, Hugh Brock wrote:
The attached patch adds code to xend_internal.c:xenDomainAttachDevice
that checks to see if the device mentioned in the passed-in XML already
exists, and if so calls op_device_configure to modify the device. It is
particularly useful for connecting and disconnecting a hardware cdrom
device to an FV guest.
I considered making new API a la virDomainModifyDevice, but decided
overloading virDomainAttachDevice was cleaner (and didn't change
existing API).
I have tested the patch on f7 with xen 3.1 and a windows 2000 guest.
Since the patch merely wraps Xen's device_configure call, we're not
adding much risk of breakage.
Okay looks sensible.
diff -ruN libvirt.orig/src/xend_internal.c libvirt/src/xend_internal.c
--- libvirt.orig/src/xend_internal.c 2007-09-06 11:28:05.0 -0400
+++ libvirt/src/xend_internal.c 2007-09-06 10:47:25.0 -0400
@@ -3087,6 +3087,7 @@
char *sexpr, *conf, *str;
int hvm = 0, ret;
xenUnifiedPrivatePtr priv;
+char class[8], ref[80];
if ((domain == NULL) || (domain-conn == NULL) || (domain-name ==
NULL)) {
virXendError((domain ? domain-conn : NULL), VIR_ERR_INVALID_ARG,
@@ -3116,8 +3117,16 @@
*(conf + strlen(conf) -1) = 0; /* suppress final ) */
}
else conf = sexpr;
-ret = xend_op(domain-conn, domain-name, op, device_create,
-config, conf, NULL);
+if (virDomainXMLDevID(domain, xml, class, ref)) {
+/* device doesn't exist, define it */
+ret = xend_op(domain-conn, domain-name, op, device_create,
+ config, conf, NULL);
+}
+else {
+/* device exists, attempt to modify it */
+ret = xend_op(domain-conn, domain-name, op, device_configure,
+ config, conf, dev, ref, NULL);
+}
free(sexpr);
return ret;
}
virDomainXMLDevID looks frightening to me since we write to an array of
undisclosed size, but that is independant from the patch which looks fine to
me.
+1
Thanks !
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
Re: [Libvir] [PATCH] Allow modifying existing block device, making virDomainAttachDevice modify the device if it already exists
On Thu, Sep 06, 2007 at 11:59:08AM -0400, Daniel Veillard wrote:
On Thu, Sep 06, 2007 at 11:45:39AM -0400, Hugh Brock wrote:
The attached patch adds code to xend_internal.c:xenDomainAttachDevice
that checks to see if the device mentioned in the passed-in XML already
exists, and if so calls op_device_configure to modify the device. It is
particularly useful for connecting and disconnecting a hardware cdrom
device to an FV guest.
I considered making new API a la virDomainModifyDevice, but decided
overloading virDomainAttachDevice was cleaner (and didn't change
existing API).
I have tested the patch on f7 with xen 3.1 and a windows 2000 guest.
Since the patch merely wraps Xen's device_configure call, we're not
adding much risk of breakage.
Okay looks sensible.
diff -ruN libvirt.orig/src/xend_internal.c libvirt/src/xend_internal.c
--- libvirt.orig/src/xend_internal.c2007-09-06 11:28:05.0
-0400
+++ libvirt/src/xend_internal.c 2007-09-06 10:47:25.0 -0400
@@ -3087,6 +3087,7 @@
char *sexpr, *conf, *str;
int hvm = 0, ret;
xenUnifiedPrivatePtr priv;
+char class[8], ref[80];
if ((domain == NULL) || (domain-conn == NULL) || (domain-name ==
NULL)) {
virXendError((domain ? domain-conn : NULL), VIR_ERR_INVALID_ARG,
@@ -3116,8 +3117,16 @@
*(conf + strlen(conf) -1) = 0; /* suppress final ) */
}
else conf = sexpr;
-ret = xend_op(domain-conn, domain-name, op, device_create,
-config, conf, NULL);
+if (virDomainXMLDevID(domain, xml, class, ref)) {
+/* device doesn't exist, define it */
+ret = xend_op(domain-conn, domain-name, op, device_create,
+ config, conf, NULL);
+}
+else {
+/* device exists, attempt to modify it */
+ret = xend_op(domain-conn, domain-name, op,
device_configure,
+ config, conf, dev, ref, NULL);
+}
free(sexpr);
return ret;
}
virDomainXMLDevID looks frightening to me since we write to an array of
undisclosed size, but that is independant from the patch which looks fine to
me.
Yep, this patch is fine, but we absolutely have to fix virDomainXMLDevID
as the value it writes into the pre-allocated 'ref' parameter is taken from
an XML attribute which can be an arbitrary size can thus potentially
overflow the '80' char buffer passed from xenDaemonDetachDevice or this
new call for changing CD media.
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] Extending libvirt to probe NUMA topology
* Daniel Veillard [EMAIL PROTECTED] [2007-09-06 08:55]: On Wed, Jun 13, 2007 at 10:40:40AM -0500, Ryan Harper wrote: Hello all, I wanted to start a discussion on how we might get libvirt to be able to probe the NUMA topology of Xen and Linux (for QEMU/KVM). In Xen, I've recently posted patches for exporting topology into the [1]physinfo hypercall, as well adding a [2]hypercall to probe the Xen heap. I believe the topology and memory info is already available in Linux. With these, we have enough information to be able to write some simple policy above libvirt that can create guests in a NUMA-aware fashion. Let's restart that discussion, I would really like to see this implemented within the next month. Thanks for starting this back up. I'd like to suggest the following for discussion: (1) A function to discover topology (2) A function to check available memory (3) Specifying which cpus to use prior to domain start Thoughts? Okay following the discussions back in June and what seems available as APIs on various setups I would like to suggest the following: 1) Provide a function describing the topology as an XML instance: char * virNodeGetTopology(virConnectPtr conn); which would return an XML instance as in virConnectGetCapabilities. I toyed with the idea of extending virConnectGetCapabilities() to add a topology section in case of NUMA support at the hypervisor level, but it was looking to me that the two might be used at different times and separating both might be a bit cleaner, but I could be convinced otherwise. This doesn't change much the content in any way. I think the most important in the call is to get the topology informations as the number of processors, memory and NUMA cells are already available from virNodeGetInfo(). I suggest a format exposing the hierarchy in the XML structure, which will allow for more complex topologies for example on Sun hardware: Not having a deep libvirt background, I'm not sure I can argue one way or another. The topology discovery (nr_numa_nodes, nr_cpus, cpu_to_node) - they won't be changing for the lifetime of the libvirt node. - topology cells num='2' cell id='0' cpus num='2' cpu id='0'/ cpu id='1'/ /cpus memory size='2097152'/ /cell cell id='1' cpus num='2' cpu id='2'/ cpu id='3'/ /cpus memory size='2097152'/ /cell /cells /topology - A few things to note: - the cells element list the top sibling cells - the cell element describes as child the resources available like the list of CPUs, the size of the local memory, that could be extended by disk descriptions too disk dev='/dev/sdb'/ and possibly other special devices (no idea what ATM). The only concern I have is the memory size -- I don't believe we have a way to get at anything other than current available memory. As far as other resources, yes that makes sense, I believe there is topology information for pci resources, though for Xen, none of that is available. - in case of deeper hierarchical topology one may need to be able to name sub-cells and the format could be extended for example as cells num='2' cells num='2' cell id='1' ... /cell cell id='2' ... /cell /cells cells num='2' cell id='3' ... /cell cell id='4' ... /cell /cells /cells But that can be discussed/changed when the need arise :-) Yep. - topology may later be extended with other child elements for example to expand the description with memory access costs from cell to cell. I don't know what's the best way, mapping an array in XML is usually not very nice. - the memory size is indicated on an attribute (instead as the content as we use on domain dumps), to preserve extensibility we may need to express more structure there (memory banks for example). We could also add a free='x' attribute indicating the amount available there, but as you suggested it's probably better to provide a separate call for this. I would expect that function to be available even for ReadOnly connections since it's descriptive only, which means it would need to be added to the set of proxy supported call. The call will of course be added to the driver block. Implementation on recent Xen could use the hypercall. For KVM I'm wondering a bit, I don't have a NUMA box around (but can probably find one), I assume that we could either use libnuma if found at compile time or get informations from /proc. On Solaris there is a specific library as Dan exposed in the thread. I think coming first with a Xen only support
Re: [Libvir] [PATCH] docs spelling fixes
Eduardo Habkost wrote: ... -lt;/capabilitiesgt;/prepThe fist block (in red) indicates the host hardware capbilities, currently +lt;/capabilitiesgt;/prepThe fist block (in red) indicates the host hardware capabilities, currently should be first, I think, if we are going to be pedantic about it :). Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] docs spelling fixes
On Thu, Sep 06, 2007 at 01:53:53PM -0400, Chris Lalancette wrote:
Eduardo Habkost wrote:
...
-lt;/capabilitiesgt;/prepThe fist block (in red) indicates the host
hardware capbilities, currently
+lt;/capabilitiesgt;/prepThe fist block (in red) indicates the host
hardware capabilities, currently
should be first, I think, if we
are
going to be pedantic about it :).
ispell didn't get this one. :)
Updated patch.
--- libvirt/docs/format.html16 Jul 2007 21:30:30 - 1.25
+++ libvirt/docs/format.html6 Sep 2007 17:54:54 -
@@ -59,7 +59,7 @@
/ulpThe format of the devices and their type may grow over time, but the
following should be sufficient for basic use:/ppA codedisk/code device
indicates a block device, it can have two
values for the type attribute either 'file' or 'block' corresponding to the 2
-options availble at the Xen layer. It has two mandatory children, and one
+options available at the Xen layer. It has two mandatory children, and one
optional one in no specific order:/pullisource with a file attribute
containing the path in Domain 0 to the
file or a dev attribute if using a block device, containing the device
name ('hda5' or '/dev/hda5')/li
@@ -72,7 +72,7 @@
number of children in no specific order:/pullisource: indicating the
bridge name/li
limac: the optional mac address provided in the address attribute/li
liip: the optional IP address provided in the address attribute/li
- liscript: the script used to bridge the interfcae in the Domain 0/li
+ liscript: the script used to bridge the interface in the Domain 0/li
litarget: and optional target indicating the device name./li
/ulpA codeconsole/code element describes a serial console connection to
the guest. It has no children, and a single attribute codetty/code which
@@ -237,11 +237,11 @@
liVirtual network
pProvides a virtual network using a bridge device in the host.
Depending on the virtual network configuration, the network may be
-totally isolated,NAT'ing to aan explicit network device, or NAT'ing to
+totally isolated, NAT'ing to an explicit network device, or NAT'ing to
the default route. DHCP and DNS are provided on the virtual network in
all cases and the IP range can be determined by examining the virtual
network config with 'codevirsh net-dumpxml lt;network
-namegt;/code'. There is one virtual network called'default' setup out
+namegt;/code'. There is one virtual network called 'default'' setup out
of the box which does NAT'ing to the default route and has an IP range of
code192.168.22.0/255.255.255.0/code. Each guest will have an
associated tun device created with a name of vnetN, which can also be
@@ -311,7 +311,7 @@
/li
liTCP tunnel
pA TCP client/server architecture provides a virtual network. One VM
-provides the server end of the netowrk, all other VMS are configured as
+provides the server end of the network, all other VMS are configured as
clients. All network traffic is routed between the VMs via the server.
This mode is also available to unprivileged users. There is no default
DNS or DHCP support and no outgoing network access. To provide outgoing
@@ -411,7 +411,7 @@
lt;/featuresgt;
lt;/guestgt;/span
...
-lt;/capabilitiesgt;/prepThe fist block (in red) indicates the host
hardware capbilities, currently
+lt;/capabilitiesgt;/prepThe first block (in red) indicates the host
hardware capabilities, currently
it is limited to the CPU properties but other information may be available,
it shows the CPU architecture, and the features of the chip (the feature
block is similar to what you will find in a Xen fully virtualized domain
--
Eduardo
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] Allow modifying existing block device, making virDomainAttachDevice modify the device if it already exists
Daniel P. Berrange wrote: On Thu, Sep 06, 2007 at 11:59:08AM -0400, Daniel Veillard wrote: On Thu, Sep 06, 2007 at 11:45:39AM -0400, Hugh Brock wrote: The attached patch adds code to xend_internal.c:xenDomainAttachDevice that checks to see if the device mentioned in the passed-in XML already exists, and if so calls op_device_configure to modify the device. It is particularly useful for connecting and disconnecting a hardware cdrom device to an FV guest. virDomainXMLDevID looks frightening to me since we write to an array of undisclosed size, but that is independant from the patch which looks fine to me. Yep, this patch is fine, but we absolutely have to fix virDomainXMLDevID as the value it writes into the pre-allocated 'ref' parameter is taken from an XML attribute which can be an arbitrary size can thus potentially overflow the '80' char buffer passed from xenDaemonDetachDevice or this new call for changing CD media. Dan. Very good -- if someone would apply this one please, I will have a look at making the XMLDevID code a bit saner... --Hugh -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org [EMAIL PROTECTED]| virtualization library http://libvirt.org -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
