Re: [Libvir] [PATCH] finish NUMA code reorg, plug cpuset at creat time support
On Tue, 30 Oct 2007 16:54:36 -0400 Daniel Veillard wrote: Okay sorry it took so long, I got distrated by something else and I wanted to come back with a more complete patch for the following: - make sure that cpu expressions coming from the user are reparsed and translated to ranges to make sure we don't have a mismatch between the external representations and what is accepted both by libvirt and xend - Saving the pinning in the XML makes things really complex. alls the XML dump routines of xend assume an SExpr input but the affinity is not available there. Querying xend may be very costly and it way better to ask at the xen_unified level where the hypervisor hypercall will be used if available - as a result I removed the DumpXML entry point from xen_unified because you need to extend parameters in the xend case - also when coming from the proxy you just have the domain id and it's harder to get the cpu list in an efficient way without messing even more with the code I still think CPU affinity in the domain is misplaced, but well, okay I agree to do this for real cpus, this complicates the code a bit though. The associated patch compiles, but I have not yet tested it, it's basically how I would expect to finish the NUMA work, but it certainly need debug and testing. I will look at this tomorrow, but I welcome feedback :-) sounds good to me, I tested with your patch, and I have four fixes for it. This is a test I did : [on RHEL5.1] --- dumpxml (conf - XML) state:inactive ...(1) and (2) (SExpr - XML) state:active define (XML - conf) create (XML - SExpr) start(conf - XML - SExpr) [on fedora8] --- dumpxml (SExpr - XML) state:inactive (cannot get by Xen) ...(3) (SExpr - XML) state:active (get by Xen) ...(3) define (XML - SExpr) create (XML - SExpr) start(nothing translation) (1) numa6_fix1.patch I cannot run the dumpxml command with inactive domain on RHEL5.1. So, I added the check of domain ID and xendConfigVersion. (2) numa6_fix2.patch The discontinuous number is invalid for inactive domain on RHEL5.1. I guess the cause is wrong argument is specified as maxcpu. (e.g.) - normal case conf : cpus = 0,1 dumpxml: vcpu cpuset='0,1'4/vcpu - invalid case conf : cpus = 0,3 dumpxml: vcpu cpuset='0'4/vcpu (3) numa6_fix3.patch The expression is different between inactive domain and active domain, when I don't have vcpu setting for the domain (i.e. any cpu is pinned). inactive domain : vcpu cpuset=''2/vcpu active domain : vcpu2/vcpu So, I conform to the expression of active domain. (4) numa6_fix4.patch The expression is different between xm vcpu-list and virsh dumpxml, when I specified continuous number. (e.g.) # xm vcpu-list 200 Name ID VCPUs CPU State Time(s) CPU Affinity test 200 0 1 -b- 10.9 0-1 test 200 1 0 -b- 9.1 0-1 test 200 2 4 -b- 3.1 3-4 test 200 3 5 -b- 3.9 5-6 # ./virsh dumpxml 200| grep cpu vcpu cpuset='0,1,3-6'4/vcpu So, I change the expression from , to -(range) that I can use to create the domain. (e.g.) # ./virsh dumpxml 200| grep cpu vcpu cpuset='0-1,3-6'4/vcpu Regards, Saori. numa6_fix2.patch Description: Binary data numa6_fix1.patch Description: Binary data numa6_fix3.patch Description: Binary data numa6_fix4.patch Description: Binary data -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] finish NUMA code reorg, plug cpuset at creat time support
On Wed, Oct 31, 2007 at 05:20:01PM +0900, Saori Fukuta wrote: On Tue, 30 Oct 2007 16:54:36 -0400 Daniel Veillard wrote: The associated patch compiles, but I have not yet tested it, it's basically how I would expect to finish the NUMA work, but it certainly need debug and testing. I will look at this tomorrow, but I welcome feedback :-) sounds good to me, I tested with your patch, and I have four fixes for it. Cool thanks a lot for debugging while I was asleep :-) This is a test I did : [on RHEL5.1] --- dumpxml (conf - XML) state:inactive ...(1) and (2) (SExpr - XML) state:active define (XML - conf) create (XML - SExpr) start(conf - XML - SExpr) [on fedora8] --- dumpxml (SExpr - XML) state:inactive (cannot get by Xen) ...(3) (SExpr - XML) state:active (get by Xen) ...(3) define (XML - SExpr) create (XML - SExpr) start(nothing translation) excellent, thanks a lot ! (1) numa6_fix1.patch I cannot run the dumpxml command with inactive domain on RHEL5.1. So, I added the check of domain ID and xendConfigVersion. yes makes sense ! I also fixed that routine in the XEND case because the value for cpus was leaked if non-NULL. (2) numa6_fix2.patch The discontinuous number is invalid for inactive domain on RHEL5.1. I guess the cause is wrong argument is specified as maxcpu. (e.g.) - normal case conf : cpus = 0,1 dumpxml: vcpu cpuset='0,1'4/vcpu - invalid case conf : cpus = 0,3 dumpxml: vcpu cpuset='0'4/vcpu Hum right this is a bug, I tried to be smart and failed :-) (3) numa6_fix3.patch The expression is different between inactive domain and active domain, when I don't have vcpu setting for the domain (i.e. any cpu is pinned). inactive domain : vcpu cpuset=''2/vcpu active domain : vcpu2/vcpu So, I conform to the expression of active domain. oh, yes another bug ! (4) numa6_fix4.patch The expression is different between xm vcpu-list and virsh dumpxml, when I specified continuous number. (e.g.) # xm vcpu-list 200 Name ID VCPUs CPU State Time(s) CPU Affinity test 200 0 1 -b- 10.9 0-1 test 200 1 0 -b- 9.1 0-1 test 200 2 4 -b- 3.1 3-4 test 200 3 5 -b- 3.9 5-6 # ./virsh dumpxml 200| grep cpu vcpu cpuset='0,1,3-6'4/vcpu So, I change the expression from , to -(range) that I can use to create the domain. (e.g.) # ./virsh dumpxml 200| grep cpu vcpu cpuset='0-1,3-6'4/vcpu Hum, I'm not sure why you prefer to use a range for 2 consecutive values, this should be equivalent both for xend and libvirt, but it's a bit simpler, so no problem ! I commited the aggregated patches, I think at this point we should be okay with NUMA support except for potential bugs showing up on testing and the vcpu pinning informations storage which I still think would be better addressed at the virsh level. What is needed now is more testing I think. thanks a lot for your fast testing and debugging ! 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] [RFC] Linux-VServer support
On Wed, Oct 31, 2007 at 04:09:54AM +, Daniel P. Berrange wrote: On Tue, Oct 30, 2007 at 04:28:59PM +0100, Daniel Hokka Zakrisson wrote: This is an initial stab at adding Linux-VServer support to libvirt. There are still a couple of things missing, like scheduler support in the XML parsing, and proper network support. Great to see interest in adding more drivers ! I've not had time to look Definitely, welcome aboard ! I'm just a bit worried that it's Yet Another Daniel in the project, confusion guaranteed :-) at your patch in great detail yet, but I'll give some more detailed feedback in the next day or so. My first comment though - why the xid123/xid field in the XML - the unique integer ID for a domain should really be in the 'id' attribute domain id='123'. There are a couple of other small XML format consistency issues like that to check up on. I looked at the code, that seems clean but I have a concern about the overall XML format. Could you paste a couple of examples. Also I think Linux-VServer and OpenVZ kind of configuration may end up with the same kind of limitations or differences, so I would like to try to harmonize both format when possible. I've got a few questions though. virsh's schedinfo hardcodes the available options, should I be adding new ones there? Would better introspection from getSchedulerType make this a non-issue? How do the network domains interact and associate with the regular domains? Yes, the virsh schedinfo command is broken in this respect. Rather than hardcoding params, it should simply allow virsh schedinfo --set foo=bar --set wizz=123 To determine the data types for each param, it can simply query the existing values with getSchedularInfo and then update them accordingly. the scheduling side of the API is probably the part where it's the harder to keep a coherent access between hypervisors, that's the reason why Rich designed a very flexible mechanism but drivers should use some introspection by looking at parameters names to process them, and provide good error reporting. virsh command can certainly be improved as Dan suggested, yes. thanks for the patch, but let's discuss and fix the XML format before trying to finish and push that first version :-) 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] [RFC] Linux-VServer support
Daniel P. Berrange wrote: On Tue, Oct 30, 2007 at 04:28:59PM +0100, Daniel Hokka Zakrisson wrote: This is an initial stab at adding Linux-VServer support to libvirt. There are still a couple of things missing, like scheduler support in the XML parsing, and proper network support. Great to see interest in adding more drivers ! I've not had time to look at your patch in great detail yet, but I'll give some more detailed feedback in the next day or so. My first comment though - why the xid123/xid field in the XML - the unique integer ID for a domain should really be in the 'id' attribute domain id='123'. There are a couple of other small XML format consistency issues like that to check up on. Yeah, the only reason I did it with a separate element was that I really don't know XPath, so I hadn't figured out how to get the id in that case. NB, in most cases there is no need to implement network support in each driver. The libvirt networking APIs happen to be implemented in the QEMU driver codebase, but they're not really dependant on QEMU - the same functionality is shared across all drivers. If you connect to the Xen hypervisor, libvirt will auto-magically hook up the networking APIs to go via the QEMU driver. The same should work OK for VServer without you needing todo anything special. Well, Linux-VServer is different from most (all?) other virtualization technologies in that we do IP isolation, rather than virtualizing the network stack. This means that guests are merely limited to a subset of the IP addresses assigned to the host, so there's no routing or bridging involved. I've got a few questions though. virsh's schedinfo hardcodes the available options, should I be adding new ones there? Would better introspection from getSchedulerType make this a non-issue? How do the network domains interact and associate with the regular domains? Yes, the virsh schedinfo command is broken in this respect. Rather than hardcoding params, it should simply allow virsh schedinfo --set foo=bar --set wizz=123 To determine the data types for each param, it can simply query the existing values with getSchedularInfo and then update them accordingly. Dan. -- Daniel Hokka Zakrisson -- 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 05:23:47PM -0400, Jim Paris wrote: 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. Agreed. The specifics of the hardware configuration emulated for the domain have their place in the XML file. But I'm not sure what other compatibility issues may arise if we applied such a patch. Also I hate seeing a patch rot in the list archive without proper process but I don't feel like I understand all the issues at stake here to really try to apply it myself ... What would we beak by applying this patch, and can this be fixed ? Daniel, wondering ... -- 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 failure of HVM domain definition on Xen 3.0.3 or earlier(BZ328841)
On Tue, Oct 23, 2007 at 02:14:29PM +0900, Masayuki Sunou wrote: 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. Could you please explain the patch, it changes the XML parsing and seems to change the S-Expr generation. How ? Providing examples or explanations of how the patch works will help. 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] Again this seems to change parsing of S-Expr input to accept an empty value. Could you explain what this patch does, i.e. what kind of input is being targetted and what is changed by the patch. 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: 2/7 public API header files
On Mon, Oct 29, 2007 at 03:57:01AM +, Daniel P. Berrange wrote:
This patch adds a public header file defining the application facing contract
for the storage APIs.
+/* -*- c -*-
+ * storage.h:
+ * Summary: storage management interfaces
+ * Description: Provides the interfaces of the libvirt library to handle
+ * storage management from a process running in the host
+ *
+ * Copy: Copyright (C) 2005-2007 Red Hat, Inc.
+ *
+ * See COPYING.LIB for the License of this software
+ *
+ * Author: Daniel Veillard [EMAIL PROTECTED]
Need to fix the author I guess :-)
+ */
+
+
+
+#ifndef __VIR_VIRLIB_H__
+#error Do not include storage.h directly. Use libvirt.h instead
+#endif
That would be one reason against the split, if you can't reference files
individually I don't think we can export them as an API...
+#ifndef __VIR_VIRLIB_STORAGE_H__
+#define __VIR_VIRLIB_STORAGE_H__
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+/**
+ * virStoragePool:
+ *
+ * a virStoragePool is a private structure representing a storage pool
+ */
+typedef struct _virStoragePool virStoragePool;
+
+/**
+ * virStoragePoolPtr:
+ *
+ * a virStoragePoolPtr is pointer to a virStoragePool private structure,
this is the
+ * type used to reference a storage pool in the API.
+ */
+typedef virStoragePool *virStoragePoolPtr;
+
+
+typedef enum {
+ VIR_STORAGE_POOL_INACTIVE = 0,
+ VIR_STORAGE_POOL_ACTIVE = 1,
+} virStoragePoolState;
+
+typedef struct _virStoragePoolInfo virStoragePoolInfo;
+
+struct _virStoragePoolInfo {
+ int state; /* virStoragePoolState flags */
+ unsigned long long capacity; /* Logical size bytes */
+ unsigned long long allocation; /* Current allocation bytes */
+};
There is no name available ? Once you got a pointer to that structure,
how do you expose its capability to the user ?
+typedef virStoragePoolInfo *virStoragePoolInfoPtr;
+
+
+/**
+ * virStorageVol:
+ *
+ * a virStorageVol is a private structure representing a storage volume
+ */
+typedef struct _virStorageVol virStorageVol;
+
+/**
+ * virStorageVolPtr:
+ *
+ * a virStorageVolPtr is pointer to a virStorageVol private structure, this
is the
+ * type used to reference a storage volume in the API.
+ */
+typedef virStorageVol *virStorageVolPtr;
+
+
+typedef enum {
+ VIR_STORAGE_POOL_FILE = 0,
+ VIR_STORAGE_POOL_BLOCK = 1,
+} virStoragePoolType;
+
+typedef struct _virStorageVolInfo virStorageVolInfo;
+
+struct _virStorageVolInfo {
+ int type; /* virStoragePoolType flags */
+ unsigned long long capacity; /* Logical size bytes */
+ unsigned long long allocation; /* Current allocation bytes */
+};
Same thing, I feel it lacks some external naming in the structure,
+typedef virStorageVolInfo *virStorageVolInfoPtr;
+
+/*
+ * Get connection from pool.
+ */
+virConnectPtrvirStoragePoolGetConnect(virStoragePoolPtr
pool);
+
+/*
+ * List active storage pools
+ */
+int virConnectNumOfStoragePools (virConnectPtr conn);
+int virConnectListStoragePools (virConnectPtr conn,
+ char **const names,
+ int maxnames);
+
+/*
+ * List inactive storage pools
+ */
+int virConnectNumOfDefinedStoragePools(virConnectPtr conn);
+int virConnectListDefinedStoragePools(virConnectPtr conn,
+ char **const names,
+ int maxnames);
+
+/*
+ * Lookup network by name or uuid
+ */
+virStoragePoolPtrvirStoragePoolLookupByName(virConnectPtr conn,
+const char *name);
+virStoragePoolPtrvirStoragePoolLookupByUUID(virConnectPtr conn,
+const unsigned char
*uuid);
+virStoragePoolPtrvirStoragePoolLookupByUUIDString(virConnectPtr
conn,
+ const char
*uuid);
+
+/*
+ * Create active transient storage pool
+ */
+virStoragePoolPtrvirStoragePoolCreateXML(virConnectPtr conn,
+ const char *xmlDesc);
+
+/*
+ * Define inactive persistent storage pool
+ */
+virStoragePoolPtrvirStoragePoolDefineXML(virConnectPtr conn,
+ const char *xmlDesc);
+
+/*
+ * Delete persistent storage pool
+ */
+int virStoragePoolUndefine(virStoragePoolPtr pool);
+
+/*
+ * Activate persistent pool
+ */
+int virStoragePoolCreate(virStoragePoolPtr pool);
+
+/*
+ * StoragePool destroy/free
+ */
+int
Re: [Libvir] PATCH: 3/7 internal driver API
On Mon, Oct 29, 2007 at 03:57:29AM +, Daniel P. Berrange wrote: This patch defines the internal driver API for the storage API calls. It also provides the cache implementation for the virStoragePoolPtr and virStorageVolPtr objects. The virStorageVolPtr object is a little different in that it doesn't reference the virConnectPtr object directly. Instead it points to the virStoragePoolPtr object. This Okay makes the reference counting 'interesting', because when we get a virStorageVolPtr object, we have increment the count on both the pool and the connection. This was starting to get complex, so to keep it sane I don't bother with referencing counting on the virStorageVolPtr object itself. So how do you get rid of it ? You assume they will always stay around ? Also what's the story about locking in that patch, you're trying to allow concurrent operations on multiple storage pools (which may be needed due to storage and network latencies) [...] + * Provides the connection pointer associated with a storage poolk. The s/poolk/pool/ The patch code looks mostly common :-) 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: 1/7 Split up the public header files
On Wed, Oct 31, 2007 at 09:53:07AM -0400, Daniel Veillard wrote: On Mon, Oct 29, 2007 at 03:56:18AM +, Daniel P. Berrange wrote: This patch splits up the libvirt.h file into multiple pieces. The big header file was getting rather long hard to follow, with API calls for domains and networks all mixed together, and macros typedefs methods all mixed up. Adding another 25 APIs for storage won't improve this. So this splits up the header into libvirt/connection.h- connection related API calls objects libvirt/node.h - host node information APIs objects libvirt/domain.h- hypervisor/domain API calls objects libvirt/network.h - virtual networking API calls objects The original libvirt.h, now simply #include's all four of these files. The header files aren't intended to be included directly - apps carry on just using the main header file. The main impact is not covered by this patch, it's the documentation generation, which also mean that on the web site the doc page for libvirt would become nearly empty and 4 new pages would be added. I'm not against the change (though it will break all previous reference to documentation functions embedded in list archives) but the documentation impact seems to not have been considered and it's not neglectible, really. Hmm, yes I forgot about the docs - it will have an impact there. One could argue though that the impact will be positive, since it'll split the docs into more managable chunks each page dealing with a specific class of APIs. In any case, this patch doesn't really block any of the storage work - its just something I tried out. We can easily stay with existing scheme and reconsider it another time. 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
On Wed, Oct 31, 2007 at 03:05:07PM +, Daniel P. Berrange wrote: On Wed, Oct 31, 2007 at 09:34:33AM -0400, Daniel Veillard wrote: 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. Agreed. The specifics of the hardware configuration emulated for the domain have their place in the XML file. But I'm not sure what other compatibility issues may arise if we applied such a patch. Also I hate seeing a patch rot in the list archive without proper process but I don't feel like I understand all the issues at stake here to really try to apply it myself ... Having thought about it, I think its reasonable to aply some variant of this patch. Guest a question of how we want to present it as XML. Just to present some variants... interface type=bridge nic model=rtl8139/ source bridge=xenbr0/ target dev=vif1.0/ /interface [...] I guess I'd lean towards the first variant, which was Jim's original suggestion. yes, I prefer that one too Of course for any of this to solve Jim's problem, we need virt-install and / or virt-manager to explicitly ask for the RTL8139 nic when creating new guests, otherwise you're still at the mercy of the underlying default NIC choice in QEMU/KVM/XEn which may or may not be RTL8139. Well at least nic .../ can be added after creation to guarantee the profile won't change if the default gets eventually changed. 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: Support NIC model selection for QEMU/KVM
On Wed, Oct 31, 2007 at 09:34:33AM -0400, Daniel Veillard wrote: On Mon, Oct 22, 2007 at 05:23:47PM -0400, Jim Paris wrote: 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. Agreed. The specifics of the hardware configuration emulated for the domain have their place in the XML file. But I'm not sure what other compatibility issues may arise if we applied such a patch. Also I hate seeing a patch rot in the list archive without proper process but I don't feel like I understand all the issues at stake here to really try to apply it myself ... Having thought about it, I think its reasonable to aply some variant of this patch. Guest a question of how we want to present it as XML. Just to present some variants... interface type=bridge nic model=rtl8139/ source bridge=xenbr0/ target dev=vif1.0/ /interface interface type=bridge model=rtl8139 source bridge=xenbr0/ target dev=vif1.0/ /interface interface type=bridge modelrtl8139/model source bridge=xenbr0/ target dev=vif1.0/ /interface interface type=bridge source bridge=xenbr0/ target dev=vif1.0 model=rtl8139/ /interface I guess I'd lean towards the first variant, which was Jim's original suggestion. Of course for any of this to solve Jim's problem, we need virt-install and / or virt-manager to explicitly ask for the RTL8139 nic when creating new guests, otherwise you're still at the mercy of the underlying default NIC choice in QEMU/KVM/XEn which may or may not be RTL8139. Regards, 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: 1/7 Split up the public header files
On Wed, Oct 31, 2007 at 03:20:00PM +, Daniel P. Berrange wrote: On Wed, Oct 31, 2007 at 09:53:07AM -0400, Daniel Veillard wrote: On Mon, Oct 29, 2007 at 03:56:18AM +, Daniel P. Berrange wrote: This patch splits up the libvirt.h file into multiple pieces. The big header file was getting rather long hard to follow, with API calls for domains and networks all mixed together, and macros typedefs methods all mixed up. Adding another 25 APIs for storage won't improve this. So this splits up the header into libvirt/connection.h- connection related API calls objects libvirt/node.h - host node information APIs objects libvirt/domain.h- hypervisor/domain API calls objects libvirt/network.h - virtual networking API calls objects The original libvirt.h, now simply #include's all four of these files. The header files aren't intended to be included directly - apps carry on just using the main header file. The main impact is not covered by this patch, it's the documentation generation, which also mean that on the web site the doc page for libvirt would become nearly empty and 4 new pages would be added. I'm not against the change (though it will break all previous reference to documentation functions embedded in list archives) but the documentation impact seems to not have been considered and it's not neglectible, really. Hmm, yes I forgot about the docs - it will have an impact there. One could argue though that the impact will be positive, since it'll split the docs into more managable chunks each page dealing with a specific class of APIs. I'm not against, we just need to check all cross references :-\ In any case, this patch doesn't really block any of the storage work - its just something I tried out. We can easily stay with existing scheme and reconsider it another time. let's just make it a separate kind of change and track it on its own, I may give it some testing ... 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] [RFC] Linux-VServer support
On Wed, Oct 31, 2007 at 02:24:58PM +0100, Daniel Hokka Zakrisson wrote: Daniel P. Berrange wrote: On Tue, Oct 30, 2007 at 04:28:59PM +0100, Daniel Hokka Zakrisson wrote: This is an initial stab at adding Linux-VServer support to libvirt. There are still a couple of things missing, like scheduler support in the XML parsing, and proper network support. Great to see interest in adding more drivers ! I've not had time to look at your patch in great detail yet, but I'll give some more detailed feedback in the next day or so. My first comment though - why the xid123/xid field in the XML - the unique integer ID for a domain should really be in the 'id' attribute domain id='123'. There are a couple of other small XML format consistency issues like that to check up on. Yeah, the only reason I did it with a separate element was that I really don't know XPath, so I hadn't figured out how to get the id in that case. prefix the name with @ to say your accessing an attribute children instead of an element children e.g.: '/domain/@id' if XPath is the only real problem that can be solved easilly, grab me on IRC ! 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: 2/7 public API header files
On Wed, Oct 31, 2007 at 10:03:01AM -0400, Daniel Veillard wrote:
On Mon, Oct 29, 2007 at 03:57:01AM +, Daniel P. Berrange wrote:
for the storage APIs.
+typedef struct _virStoragePoolInfo virStoragePoolInfo;
+
+struct _virStoragePoolInfo {
+ int state; /* virStoragePoolState flags */
+ unsigned long long capacity; /* Logical size bytes */
+ unsigned long long allocation; /* Current allocation bytes */
+};
There is no name available ? Once you got a pointer to that structure,
how do you expose its capability to the user ?
This is akin to the virDomainInfoPtr object - its just a struct containing
some basic status metadata. The main handle to the thing is virStoragePoolPtr
which is an opaque handle.
+struct _virStorageVolInfo {
+ int type; /* virStoragePoolType flags */
+ unsigned long long capacity; /* Logical size bytes */
+ unsigned long long allocation; /* Current allocation bytes */
+};
Same thing, I feel it lacks some external naming in the structure,
Same here - cf virDomainInfoPtr.
+int virStoragePoolShutdown(virStoragePoolPtr pool);
+intvirStoragePoolDestroy (virStoragePoolPtr
pool);
+intvirStoragePoolFree (virStoragePoolPtr
pool);
Hum, I really wonder about the precise semantic for those 3 operations
To be honest I've not 100% finalized, but current thoughts are:
- virStoragePoolShutdown() de-activate the pool - eg logout of iSCSI server,
or unmount the disk, etc
- virStoragePoolDestroy() the same, but also free's the virStoragePoolPtr
object
cf virDomainDestroy, vs virDomainShutdown
- virStoragePoolFree just free the virStoragePoolPtr.
I think we might want a way to remove all trace of a pool, eg
- virStoragePoolDelete() trash the data, eg rm -rf the directory, or
remove
the LVM volume group, or blow away the partition
table
If it were not for the historical precent of the virDomain apis, I'd be
calling this last one, virStoragePoolDestroy, but I don't want to overload
'Destory' already has defined semantics in thec context of a domain which is
that its equivalent to a forced Shutdown + Free. So i figure it best to
pick virStoragePoolDelete instead.
+ */
+virStorageVolPtr virStorageVolLookupByName(virStoragePoolPtr pool,
+ const char *name);
+virStorageVolPtr virStorageVolLookupByUUID(virStoragePoolPtr pool,
+ const unsigned char *uuid);
+virStorageVolPtr virStorageVolLookupByUUIDString(virStoragePoolPtr pool,
+ const char *uuid);
+
+const char*virStorageVolGetName(virStorageVolPtr vol);
so there is a public name, keep it in the structure, you can't garantee
the storage will have exactly the name the user expect, aliasing is
frequent in storage I think.
Yep, you can only really on 'name' being consistent for as long as a storage
pool is active. It may come up with a different name next time.
For long term persistent naming, I think we need some form of unique key
which is an opaque char *, comprised of whatever 'unique' metadata we
can pull out of the underlying physical storage - cf the mail 0/7 which
discussed 'open issues'
The API being derived from existing APIs they of course looks rather sane
to me, but the XML formats is also part of the APIs not described here.
The XML is basically following the style I posted in the last of my
messages in the 'Storage concepts' thread.
I'll be making some changes as suggested by Rich to make things more optional
so will post a revised XML description next time.
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] [RFC] Linux-VServer support
On Wed, Oct 31, 2007 at 05:14:10PM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
Are the parameters for the scheduler all integers ? If you really
never end up with an information set more structured than that then
scheduler fill_rate1='100' interval1='1000' fill_rate2='25'
interval2='1000'
idle_time='1'/
would probably be simpler. The question is would other kind of scheduler
use more structured parameters ? Seems to me it's not the case and that
ad-hoc parsing to convert {name, value} pairs would just work.
Actually, the same settings can be applied to the CPUs separately, e.g.
scheduler
param name='fill_rate1'100/param
param name='interval1'1000/param
cpu id='0'
param name='idle_time'1/param
param name='fill_rate2'25/param
param name='interval2'1000/param
/cpu
/scheduler
should at some point be possible (it's not in the current patch).
Hum, I see, first time I see such fine grained scheduling, good to
know, thanks !
I still find that
scheduler fill_rate1='100' interval1='1000'
cpu id='0' idle_time='1' fill_rate2='25' interval2='1000'/
/scheduler
would be better than adding the arbitrary param element.
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
