[libvirt] Reminder: entering freeze for 0.8.8 Wed
As suggested previously we should enter the freeze phase for 0.8.8 soon to target a release around the 15th. I suggest to keep the window open 2 more days, and start the freeze on Wed 9 to have a release on the 15th or 16th, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] fork of php-libvirt
On 01/02/2011, at 12:19 AM, Michal Novotny wrote: > in fact I did a fork of PHP libvirt and I informed Radek as well, my fork can > be found on github at my profile page: > > https://github.com/MigNov/php-libvirt > > Also, sorry for having the root in some commits but I used wrong user-name > with git unset to merge it. I've been testing it in my spare time on Fedora > 14 and php-5.3.4-1.fc14.1.i686 . > On 01/27/2011 03:05 AM, Lyre wrote: >> Hi all: >> >> I've added the documentation for the new APIs several days ago, but I've >> been busy these days and forget to inform Radek. >> >> So Radek, you may need to rebuild the documents. Hey guys, What's the best way of working with this from the libvirt project point of view? Should we update the php-libvirt URL to point somewhere new, or should we add new entries, or ? (bearing in mind, it's better to have stable URL's where possible. The URL's on the libvirt website get frozen into each release tarball) Regards and best wishes, Justin Clift -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] docs/index.html.in: update KVM url
On 06/02/2011, at 5:22 AM, Niels de Vos wrote: > Signed-off-by: Niels de Vos > --- > docs/index.html.in |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/docs/index.html.in b/docs/index.html.in > index 30cc9d7..d40f652 100644 > --- a/docs/index.html.in > +++ b/docs/index.html.in > @@ -41,7 +41,7 @@ > The http://wiki.qemu.org/Index.html";>QEMU emulator > > > -The http://kvm.qumranet.com/kvmwiki";>KVM Linux > hypervisor > +The http://www.linux-kvm.org/";>KVM Linux hypervisor > > > The http://lxc.sourceforge.net/";>LXC Linux container > system > -- > 1.7.4 ACK. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] draft ~ l10n/i18n
On 07/02/2011, at 6:00 AM, Zdenek Styblik wrote: > We are glad you've decided to help with > localization/internationalization of libvirt. Before you do anything > else, stop! Good intention, but the wording of "Before you do anything else, stop!" could put some people off. I'd just remove that phrase, as the next one "Please, pay attention ..." gives the warning of "this stuff is important to read" anyway. > Please, pay attention to following lines to save yourself from eventual > pitfalls. > > '.po' files located in this directory are synchronized from Fedora > Project[https://translate.fedoraproject.org/projects/p/libvirt/], thus > it makes little sense to start translating them. It's not bad, but still not 100% clear. Probably slightly clarify it to mention ".po" files in the *libvirt po/ source code directory* (etc) just so there's no doubt at all. Also with the wording "... little sense to start translating them." it probably needs the word "directly" just after the "them". > Here are two ways how you can translate and contribute: > > ## Optimal way > > 1st step: Become translator "Become a translator" > It's pointless to copy-paste how-to from Fedora Project. "... from the Fedora Project". (the "the" is needed) > How to become translator is described here - "How to become a translator ..." > http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Translation_Quick_Start_Guide/index.html > > This might take some time not only to read, but to get processed. "get processed" is kind of unclear, because in English it has a few potential meanings, including "for the person reading to understand". (hard to describe) Might be better to say something like: "This might take some time to read, and then to complete all of the instructions." > 4th step: Upload translated file > > !!! This point is still a mystery !!! > Upload modified file via web interface. Same here. We need advice from someone who's done it. :) The rest of the draft from "Alternate way" onwards sounds workable as it is. :) Regards and best wishes, Justin Clift -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] fork of php-libvirt
On 02/07/2011 11:16 AM, Justin Clift wrote: On 01/02/2011, at 12:19 AM, Michal Novotny wrote: in fact I did a fork of PHP libvirt and I informed Radek as well, my fork can be found on github at my profile page: https://github.com/MigNov/php-libvirt Also, sorry for having the root in some commits but I used wrong user-name with git unset to merge it. I've been testing it in my spare time on Fedora 14 and php-5.3.4-1.fc14.1.i686 . On 01/27/2011 03:05 AM, Lyre wrote: Hi all: I've added the documentation for the new APIs several days ago, but I've been busy these days and forget to inform Radek. So Radek, you may need to rebuild the documents. Hey guys, What's the best way of working with this from the libvirt project point of view? Should we update the php-libvirt URL to point somewhere new, or should we add new entries, or ? (bearing in mind, it's better to have stable URL's where possible. The URL's on the libvirt website get frozen into each release tarball) Regards and best wishes, Justin Clift Hi Justin, I have no objections against this but I'm not in the libvirt team and I'd like to contribute to this one at least in my spare time. Also, I'm CCing Radek too since he was/is working on the project as well so he deserves to know this and have a word there as well. However we've been writing several e-mail with Radek using the private e-mail about PHP libvirt project and I guess he'd be glad for anybody managing the php-libvirt project since he was participating in the project only because of need to add some features that were not supported there yet. I also switched the project to use autotools like I'm having on my github account (the patch has been sent to Radek but I don't know whether it's merged to his tree already but I know it was not at the time I created my github account) and it was working fine for me so I'm responsible for this and if anybody have issues with autotools stuff there and new features I have implemented (can be checked using commit log there on my github but please note that I accidentally wrote some parts as root so commits from root are my commits as well) feel free to contact me using this e-mail (preferable way although I'm daily checking my personal e-mail as well so you can pick one you need). Thanks, Michal -- Michal Novotny, RHCE Virtualization Team (xen userspace), Red Hat -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] fork of php-libvirt
On 07/02/2011, at 10:13 PM, Michal Novotny wrote: > I have no objections against this but I'm not in the libvirt team and I'd > like to contribute to this one at least in my spare time. Also, I'm CCing > Radek too since he was/is working on the project as well so he deserves to > know this and have a word there as well. However we've been writing several > e-mail with Radek using the private e-mail about PHP libvirt project and I > guess he'd be glad for anybody managing the php-libvirt project since he was > participating in the project only because of need to add some features that > were not supported there yet. > > I also switched the project to use autotools like I'm having on my github > account (the patch has been sent to Radek but I don't know whether it's > merged to his tree already but I know it was not at the time I created my > github account) and it was working fine for me so I'm responsible for this > and if anybody have issues with autotools stuff there and new features I have > implemented (can be checked using commit log there on my github but please > note that I accidentally wrote some parts as root so commits from root are my > commits as well) feel free to contact me using this e-mail (preferable way > although I'm daily checking my personal e-mail as well so you can pick one > you need). Ahhh, no worries. It sounds like you're taking on the "primary maintainer" role for php-libvirt. :) That being the case, would it be useful to move Radek's php-libvirt web page: http://phplibvirt.cybersales.cz/ ... to the libvirt.org site or something? Regards and best wishes, Justin Clift -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] fork of php-libvirt
On 02/07/2011 12:24 PM, Justin Clift wrote: On 07/02/2011, at 10:13 PM, Michal Novotny wrote: I have no objections against this but I'm not in the libvirt team and I'd like to contribute to this one at least in my spare time. Also, I'm CCing Radek too since he was/is working on the project as well so he deserves to know this and have a word there as well. However we've been writing several e-mail with Radek using the private e-mail about PHP libvirt project and I guess he'd be glad for anybody managing the php-libvirt project since he was participating in the project only because of need to add some features that were not supported there yet. I also switched the project to use autotools like I'm having on my github account (the patch has been sent to Radek but I don't know whether it's merged to his tree already but I know it was not at the time I created my github account) and it was working fine for me so I'm responsible for this and if anybody have issues with autotools stuff there and new features I have implemented (can be checked using commit log there on my github but please note that I accidentally wrote some parts as root so commits from root are my commits as well) feel free to contact me using this e-mail (preferable way although I'm daily checking my personal e-mail as well so you can pick one you need). Ahhh, no worries. It sounds like you're taking on the "primary maintainer" role for php-libvirt. :) That being the case, would it be useful to move Radek's php-libvirt web page: http://phplibvirt.cybersales.cz/ ... to the libvirt.org site or something? Regards and best wishes, Justin Clift Well then, I'd be glad to do so in either spare time or even if I could do it with Xen (I'm in the platform BU and libvirt is in the cloud so it could be hard to work on both - I've been asking about this some time ago since I was interested in working on both libvirt and Xen and therefore to spend my time on both divided 70% on Xen and 30% on libvirt or something like that) it would be nice :) Nevertheless we should wait for Radek's reply as well since he's hosting this on cybersales.cz site now. I guess hosting this on libvirt.org as one "subproject" of libvirt makes a pretty good sense. Thanks, Michal -- Michal Novotny, RHCE Virtualization Team (xen userspace), Red Hat -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] fork of php-libvirt
On 07/02/2011, at 10:28 PM, Michal Novotny wrote: > Well then, I'd be glad to do so in either spare time or even if I could do it > with Xen (I'm in the platform BU and libvirt is in the cloud so it could be > hard to work on both - I've been asking about this some time ago since I was > interested in working on both libvirt and Xen and therefore to spend my time > on both divided 70% on Xen and 30% on libvirt or something like that) it > would be nice :) > > Nevertheless we should wait for Radek's reply as well since he's hosting this > on cybersales.cz site now. I guess hosting this on libvirt.org as one > "subproject" of libvirt makes a pretty good sense. Yep, lets wait for Radek and see what he says. If he's of the same opinion then we can figure out the best way from there. :) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] fork of php-libvirt
On Mon, Feb 07, 2011 at 10:24:37PM +1100, Justin Clift wrote: > > Ahhh, no worries. It sounds like you're taking on the "primary maintainer" > role for php-libvirt. :) > > That being the case, would it be useful to move Radek's php-libvirt web page: > > http://phplibvirt.cybersales.cz/ > > ... to the libvirt.org site or something? Yes, it would be preferrable to have the PHP bindings site / GIT hosted on libvirt.org, so that it is more obvious that contributions are open for any libvirt developer with an interest in PHP. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] fork of php-libvirt
On 02/07/2011 12:33 PM, Daniel P. Berrange wrote: On Mon, Feb 07, 2011 at 10:24:37PM +1100, Justin Clift wrote: Ahhh, no worries. It sounds like you're taking on the "primary maintainer" role for php-libvirt. :) That being the case, would it be useful to move Radek's php-libvirt web page: http://phplibvirt.cybersales.cz/ ... to the libvirt.org site or something? Yes, it would be preferrable to have the PHP bindings site / GIT hosted on libvirt.org, so that it is more obvious that contributions are open for any libvirt developer with an interest in PHP. Daniel In fact I found the project interesting so that's why I studied how writing PHP modules in C a little and I'd like to continue working this one since this is basically what I'm doing in my spare time (when I have time) already since I like studying new things and doing things that I think may be useful so I thing this is reasonable to have it GIT hosted on libvirt.org also with some page to the libvirt.org design documenting the API and compilation/installation of the module etc. Michal -- Michal Novotny, RHCE Virtualization Team (xen userspace), Red Hat -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] draft ~ l10n/i18n
Justin, On 02/07/2011 11:59 AM, Justin Clift wrote: [...] comments are great, still - why haven't you implemented all of them then? :) Shouldn't be README/page created at this point, or not until "upload" thing is cleared out? Anyway, I'm going to merge these later on, still I don't know where-to except sending v3 to the list. So any of you better think of more comments, before we get at "spam" level with this drafting ... and before I do send another version :) 4th step: Upload translated file !!! This point is still a mystery !!! Upload modified file via web interface. Same here. We need advice from someone who's done it. :) Well, I'm a bit surprised no one from this list has experience with this one. From FP how-to: ~~~ SNIP ~~~ Submit Use the up-arrow icon labeled Send a translation for po/ja.po in the option area of each project, and click the browse button to locate your translated file. Click the Send button to commit your translated file. Interface displays the message File submitted successfully. If you receive an error or some other message, please post it to the Fedora Localization Project mailing list so it can be addressed. ~~~ SNIP ~~~ So, I would assume "upload via web interface" is valid, and I would avoid exact description how, since web interface can change and it's in how-to. Z. -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: sty...@turnovfree.net jabber: sty...@jabber.turnovfree.net -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Reserve PCI addresses 3 and 4 on qemu-system-ppc
On Sat, Feb 05, 2011 at 04:45:15PM +, Niels de Vos wrote:
> On PPC emulated by recent versions of qemu, PCI-bus 0 already has a
> macio connected in slot 3 and OHCI on slot 4.
>
> Reference:
> - https://bugzilla.redhat.com/show_bug.cgi?id=667345
>
> Signed-off-by: Niels de Vos
> ---
> Imho this patch is relatively ugly. Unfortunately I did not find a better
> way of changing the reserved PCI-addresses on a per architecture basis. It
> can well be that qemuAssignDevicePCISlots() needs to be updated for other
> architectures as well. A more modular/dynamic approach might be more
> suitable.
>
> Feel free to suggest an alternative way to solve this. Thanks,
> Niels
>
>
> src/qemu/qemu_command.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index f78ce71..50e3ad7 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -983,6 +983,14 @@ qemuAssignDevicePCISlots(virDomainDefPtr def,
> qemuDomainPCIAddressSetPtr addrs)
> goto error;
> }
>
> +/* qemu-system-ppc has macio on slot 3 and ohci on slot 4 */
> +if (STREQ(def->os.arch, "ppc")) {
> +if (qemuDomainPCIAddressReserveSlot(addrs, 3) < 0)
> +goto error;
> +if (qemuDomainPCIAddressReserveSlot(addrs, 4) < 0)
> +goto error;
> +}
> +
> /* Network interfaces */
> for (i = 0; i < def->nnets ; i++) {
> if (def->nets[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE)
Oh fun, it is actually worse than this. On PPC slot 1 is occupied by the
VGA adapter, while slot 2 is the IDE controller, so we'll need to make
some more complex changes here.
We're gonna need to change this for every other arch too, in fact it looks
like it probably differs for each '-M' arg value too :-(
I'm wondering whether we should just have a separate method for each combo
rather than trying to make one method do everything.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] if you use user namespaces
Please let me know. lxc does not use them right now. Libvirt uses them for lxc containers f they are available, but I hope we can essentially have it stop for awhile. In addition, there's tons of software out there that I don't know about, and fear of breaking their use of current user namespaces has been keeping me from pushing further userns patches. I've outlined how I see user namespaces developing at https://wiki.ubuntu.com/UserNamespace . Note there is nothing new in there - some of it goes a year back, much of it more than two years. Nothing actually new. Currently user namespaces are not very useful, but they do provide separate uid accounting, and simply tossing CLONE_NEWUSER in with CLONE_NEWNS and friends has until now been safe to do. As you can see, that is going to change. So if that would cause you pain that you can't work around, please get back to me. Otherwise, I'd like to get serious soon about expanding upon, and pushing upstream, the patches to make CLONE_NEWUSER more useful for sandboxing. thanks, -serge -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Vietnamese Translation for libvirt
The only and biggest problem is that I can not access all the feature (because of limited ability) in libvirt so I can not see the whole context for all string. 2011/2/7 Justin Clift > On 07/02/2011, at 11:36 PM, Hero Phương wrote: > > It's good to do the translation work. So if I can do anything, I will do > my best to complete it. > > Then, I am very happy to hear the instruction from you. > > Cool. :) > > The Fedora Translation team have a "Quick Start Guide" here, with > instructions > in it: > > > http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Translation_Quick_Start_Guide/index.html > > By the way, did you mean to reply to only me, rather than the two > translation > team guys CC'd on the previous email? They would be useful for you to be > in contact with. :) > > Regards and best wishes, > > Justin Clift > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Vietnamese Translation for libvirt
>Is it ok with you, if we ask the other translation people how >they get around this problem? :) Because I use Ubuntu and I don't use the libvirt package very often (because I like the GUI of VirtualBox more). If there's any luck that I can see a wrong translation string, I'll fix it immediately. Other than that I can't do anything else. :( 2011/2/7 Justin Clift > On 08/02/2011, at 12:26 AM, Hero Phương wrote: > > The only and biggest problem is that I can not access all the > > feature (because of limited ability) in libvirt so I can not > > see the whole context for all string. > > Yeah, I can see how that would be a problem. > > Is it ok with you, if we ask the other translation people how > they get around this problem? :) > > Regards and best wishes, > > Justin Clift > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Vietnamese Translation for libvirt
On 08/02/2011, at 12:57 AM, Hero Phương wrote: >Is it ok with you, if we ask the other translation people how > >they get around this problem? :) > Because I use Ubuntu and I don't use the libvirt package very often (because > I like the GUI of VirtualBox more). If there's any luck that I can see a > wrong translation string, I'll fix it immediately. Other than that I can't do > anything else. :( Yeah, I understand completely. Btw, I use VirtualBox a reasonable amount too (on a Mac desktop), because its GUI is decent. For server stuff I use libvirt and KVM though (of course). Mainly through the command line though. :) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH 00/16] usb-ccid (v18)
[adding libvir-list as well] On 02/07/2011 08:44 AM, Alon Levy wrote: >>> I guess I'll wait a little longer for more feedback? Should I split >>> the enum property separately? it's only used by ccid-card-emualted atm. >> >> The only non-cosmetic concern I have about your series is the enum >> property so I would strongly suggest splitting it. If you did that >> for v19, it will be pretty close to merge ready. >> > > Eric, > > How does this affect libvirt? could you assume a default set of backends > if "-device ccid-card-emulated,?" returns "backend=string" instead of > "backend=A/B" ? Hmm. At the moment, libvirt only looks for "ccid-card-emulated" in the -device ? list, and hasn't yet tried inspecting -device ccid-card-emulated,? output. In short, libvirt assumes that the presence of ccid-card-emulated implies that both modes are available (libvirt's => backend=nss-emulated; backend=certificates). Is it possible for qemu to have support for one, but not both, of those modes? If that's the case, then supporting "backend=nss-emulated/certificates" in -device ccid-card-emulated,? would be handy for libvirt (for example, it would be just "backend=certificates" if nss-emulated is not available). But if it's an all-or-none approach (all backends are available if ccid-card-emulated is present), then libvirt's current code won't be impacted by changing the string to the simpler "backend=string". -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] Restructure domain struct interface "driver" data for easier expansion
On 02/04/2011 02:00 PM, Laine Stump wrote: > When the element (and its "name" attribute) was added to the > domain XML's interface element, a "backend" enum was simply added to > the toplevel of the virDomainNetDef struct. > > This patch changes virDomainNetDef in two ways: s/two/three/, given: > > 1) Rename the item in the struct from "backend" to "name", so that >it's the same in the XML and in the struct, hopefully avoiding >confusion for someone unfamiliar with the function of the >attribute. > > 2) Create a "driver" union within virDomainNetDef, and a "virtio" >struct in that struct, which contains the "name" enum value. > > 3) Move around the virDomainNetParse and virDomainNetFormat functions >to allow for simple plugin of new attributes without disturbing >existing code. (you'll note that this results in a seemingly >redundant if() in the format function, but that will no longer be >the case as soon as a 2nd attribute is added). ...all nice changes. ACK to this half of the series. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Only initialize/cleanup libpciaccess once
libpciaccess has many bugs in its pci_system_init/cleanup
functions that makes calling them multiple times unwise.
eg it will double close() FDs, and leak other FDs.
* src/node_device/node_device_udev.c: Only initialize
libpciaccess once
---
src/node_device/node_device_udev.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/src/node_device/node_device_udev.c
b/src/node_device/node_device_udev.c
index 379af86..2da5529 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -363,18 +363,10 @@ static int udevTranslatePCIIds(unsigned int vendor,
char **vendor_string,
char **product_string)
{
-int ret = -1, pciret;
+int ret = -1;
struct pci_id_match m;
const char *vendor_name = NULL, *device_name = NULL;
-if ((pciret = pci_system_init()) != 0) {
-char ebuf[256];
-VIR_INFO("Failed to initialize libpciaccess: %s",
- virStrerror(pciret, ebuf, sizeof ebuf));
-ret = 0;
-goto out;
-}
-
m.vendor_id = vendor;
m.device_id = product;
m.subvendor_id = PCI_MATCH_ANY;
@@ -406,9 +398,6 @@ static int udevTranslatePCIIds(unsigned int vendor,
}
}
-/* pci_system_cleanup returns void */
-pci_system_cleanup();
-
ret = 0;
out:
@@ -1426,6 +1415,9 @@ static int udevDeviceMonitorShutdown(void)
ret = -1;
}
+/* pci_system_cleanup returns void */
+pci_system_cleanup();
+
return ret;
}
@@ -1593,6 +1585,15 @@ static int udevDeviceMonitorStartup(int privileged
ATTRIBUTE_UNUSED)
udevPrivate *priv = NULL;
struct udev *udev = NULL;
int ret = 0;
+int pciret;
+
+if ((pciret = pci_system_init()) != 0) {
+char ebuf[256];
+VIR_INFO("Failed to initialize libpciaccess: %s",
+ virStrerror(pciret, ebuf, sizeof ebuf));
+ret = -1;
+goto out;
+}
if (VIR_ALLOC(priv) < 0) {
virReportOOMError();
--
1.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] Add tx_alg attribute to interface XML for virtio backend
On 02/04/2011 02:00 PM, Laine Stump wrote:
> qemu's virtio-net-pci driver allows setting the algorithm used for tx
> packets to either "bh" or "timer". I don't know exactly how these
> algorithms differ, but someone has requested the ability to choose
> between them in libvirt's domain XML. See:
>
>https://bugzilla.redhat.com/show_bug.cgi?id=629662
Same as qemu aio - we don't have to know exactly what the difference is,
to know that someone else who does know the difference wants to be able
to choose :)
>
> ...
>
>
> ...
>
>
> I chose to put this setting as an attribute to rather than as
> a sub-element to because it is specific to the virtio-net
> driver, not something that is generally usable by all network drivers.
> (note that this is the same placement as the "driver name=..."
> attribute used to choose kernel vs. userland backend for the
> virtio-net driver.)
I take it that tx_alg applies to both options of driver name=... when
using a virtio interface, right?
> This is a bit troublesome to me, because I can see
> lots of new virtio options that could potentially be requested (just
> run "qemu-kvm -device virtio-net-pci,?" on a qemu that's version
> 0.13.0 or newer, and compare that output to potential tunable items in
> "-device e1000,?" or "-net tap,..."), so the attribute list could
> potentially get quite long (which is something I was concerned about
> when I first added the option to select kernel vs. userland backend,
> but didn't realize just how many virtio-specific options there were).
I'd like feedback from danpb or DV, since this might be a long-term XML
commitment. Maybe it makes sense to introduce sub-elements of ,
according to the driver chosen?
...
bh
But I'm not sure if that is any better.
> If the option isn't listed there, the config item is ignored (should
> it instead generate a warning log? error out and prevent the domain
> from starting?)
I would lean towards erroring out, the same way that we error out if:
is explicitly requested when the kernel module is not present.
> @@ -6808,12 +6828,16 @@ virDomainNetDefFormat(virBufferPtr buf,
> virBufferEscapeString(buf, " \n",
>def->model);
> if (STREQ(def->model, "virtio") &&
> -def->driver.virtio.name) {
> +(def->driver.virtio.name || def->driver.virtio.tx_alg)) {
> virBufferAddLit(buf, "if (def->driver.virtio.name) {
> virBufferVSprintf(buf, " name='%s'",
>
> virDomainNetBackendTypeToString(def->driver.virtio.name));
> }
> +if (def->driver.virtio.tx_alg) {
> +virBufferVSprintf(buf, " tx_alg='%s'",
> +
> virDomainNetVirtioTxAlgTypeToString(def->driver.virtio.tx_alg));
> +}
> virBufferAddLit(buf, "/>\n");
Obviously, this would change if we settle on a different XML representation.
> +++ b/src/qemu/qemu_capabilities.c
> @@ -1063,6 +1063,7 @@ qemuCapsExtractDeviceStr(const char *qemu,
> "-device", "?",
> "-device", "pci-assign,?",
> "-device", "virtio-blk-pci,?",
> + "-device", "virtio-net-pci,?",
> NULL);
> virCommandAddEnvPassCommon(cmd);
> /* qemu -help goes to stdout, but qemu -device ? goes to stderr. */
> @@ -1104,6 +1105,8 @@ qemuCapsParseDeviceStr(const char *str, unsigned long
> long *flags)
> if (strstr(str, "pci-assign.bootindex"))
> *flags |= QEMUD_CMD_FLAG_PCI_BOOTINDEX;
> }
> +if (strstr(str, "virtio-net-pci.tx="))
> +*flags |= QEMUD_CMD_FLAG_VIRTIO_TX_ALG;
That is just so slick for detecting the new bit! I'm glad I added that
improvement in -device string parsing.
> +++ b/src/qemu/qemu_capabilities.h
> @@ -92,6 +92,7 @@ enum qemuCapsFlags {
> QEMUD_CMD_FLAG_CCID_PASSTHRU = (1LL << 55), /* -device
> ccid-card-passthru */
> QEMUD_CMD_FLAG_CHARDEV_SPICEVMC = (1LL << 56), /* newer -chardev
> spicevmc */
> QEMUD_CMD_FLAG_DEVICE_SPICEVMC = (1LL << 57), /* older -device spicevmc*/
> +QEMUD_CMD_FLAG_VIRTIO_TX_ALG = (1LL << 58), /* -device
> virtio-net-pci,tx=string */
5 more bits left. Get your patches in now, before we run out of space.
Last one in has to rewrite this to be a bitset :)
> virBufferAdd(&buf, nic, strlen(nic));
> +if (usingVirtio && net->driver.virtio.tx_alg) {
> +if (qemuCmdFlags & QEMUD_CMD_FLAG_VIRTIO_TX_ALG) {
> +virBufferVSprintf(&buf, ",tx=%s",
> +
> virDomainNetVirtioTxAlgTypeToString(net->driver.virtio.tx_alg));
> +} else {
> +/* What should we do if the option isn't available? log a
> + * warning? prevent the domain from starting? Ignor
Re: [libvirt] [PATCH] Reserve PCI addresses 3 and 4 on qemu-system-ppc
On 02/07/2011 05:13 AM, Daniel P. Berrange wrote: > Oh fun, it is actually worse than this. On PPC slot 1 is occupied by the > VGA adapter, while slot 2 is the IDE controller, so we'll need to make > some more complex changes here. > > We're gonna need to change this for every other arch too, in fact it looks > like it probably differs for each '-M' arg value too :-( > > I'm wondering whether we should just have a separate method for each combo > rather than trying to make one method do everything. Definitely sounds like the sort of thing where we need an arch-specific callback function that can report the correct reservation information for that architecture (similar to how we already have arch-specific callbacks for computing cpu features). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Only initialize/cleanup libpciaccess once
On 02/07/2011 10:05 AM, Daniel P. Berrange wrote: > libpciaccess has many bugs in its pci_system_init/cleanup > functions that makes calling them multiple times unwise. > eg it will double close() FDs, and leak other FDs. > > * src/node_device/node_device_udev.c: Only initialize > libpciaccess once > --- > src/node_device/node_device_udev.c | 25 + > 1 files changed, 13 insertions(+), 12 deletions(-) ACK. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Support SCSI RAID type & lower log level for unknown types
The Linux kernel headers don't have a value for SCSI type 12,
but HAL source code shows this to be a 'raid'. Add workaround
for this type. Lower log level for unknown types since
this is not a fatal error condition. Include the device sysfs
path in the log output to allow identification of which device
has problems.
* src/node_device/node_device_udev.c: Add SCSI RAID type
---
src/node_device/node_device_udev.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/node_device/node_device_udev.c
b/src/node_device/node_device_udev.c
index 2da5529..93390af 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -41,6 +41,10 @@
#define VIR_FROM_THIS VIR_FROM_NODEDEV
+#ifndef TYPE_RAID
+# define TYPE_RAID 12
+#endif
+
struct _udevPrivate {
struct udev_monitor *udev_monitor;
int watch;
@@ -693,7 +697,8 @@ out:
}
-static int udevGetSCSIType(unsigned int type, char **typestring)
+static int udevGetSCSIType(virNodeDeviceDefPtr def,
+ unsigned int type, char **typestring)
{
int ret = 0;
int foundtype = 1;
@@ -728,6 +733,9 @@ static int udevGetSCSIType(unsigned int type, char
**typestring)
case TYPE_ENCLOSURE:
*typestring = strdup("enclosure");
break;
+case TYPE_RAID:
+*typestring = strdup("raid");
+break;
case TYPE_NO_LUN:
default:
foundtype = 0;
@@ -739,7 +747,8 @@ static int udevGetSCSIType(unsigned int type, char
**typestring)
ret = -1;
virReportOOMError();
} else {
-VIR_ERROR(_("Failed to find SCSI device type %d"), type);
+VIR_DEBUG("Failed to find SCSI device type %d for %s",
+ type, def->sysfs_path);
}
}
@@ -784,7 +793,7 @@ static int udevProcessSCSIDevice(struct udev_device *device
ATTRIBUTE_UNUSED,
switch (udevGetUintSysfsAttr(device, "type", &tmp, 0)) {
case PROPERTY_FOUND:
-if (udevGetSCSIType(tmp, &data->scsi.type) == -1) {
+if (udevGetSCSIType(def, tmp, &data->scsi.type) == -1) {
goto out;
}
break;
--
1.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Support SCSI RAID type & lower log level for unknown types
On 02/07/2011 10:41 AM, Daniel P. Berrange wrote: > The Linux kernel headers don't have a value for SCSI type 12, > but HAL source code shows this to be a 'raid'. Add workaround > for this type. Lower log level for unknown types since > this is not a fatal error condition. Include the device sysfs > path in the log output to allow identification of which device > has problems. > > * src/node_device/node_device_udev.c: Add SCSI RAID type > --- > src/node_device/node_device_udev.c | 15 --- > 1 files changed, 12 insertions(+), 3 deletions(-) ACK. > > diff --git a/src/node_device/node_device_udev.c > b/src/node_device/node_device_udev.c > index 2da5529..93390af 100644 > --- a/src/node_device/node_device_udev.c > +++ b/src/node_device/node_device_udev.c > @@ -41,6 +41,10 @@ > > #define VIR_FROM_THIS VIR_FROM_NODEDEV > > +#ifndef TYPE_RAID > +# define TYPE_RAID 12 > +#endif Is there a bug open against the kernel-headers to eventually get this into the correct place for everyone else to use? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH 00/16] usb-ccid (v18)
On Mon, Feb 07, 2011 at 08:56:30AM -0700, Eric Blake wrote: > [adding libvir-list as well] > > On 02/07/2011 08:44 AM, Alon Levy wrote: > >>> I guess I'll wait a little longer for more feedback? Should I split > >>> the enum property separately? it's only used by ccid-card-emualted atm. > >> > >> The only non-cosmetic concern I have about your series is the enum > >> property so I would strongly suggest splitting it. If you did that > >> for v19, it will be pretty close to merge ready. > >> > > > > Eric, > > > > How does this affect libvirt? could you assume a default set of backends > > if "-device ccid-card-emulated,?" returns "backend=string" instead of > > "backend=A/B" ? > > Hmm. At the moment, libvirt only looks for "ccid-card-emulated" in the > -device ? list, and hasn't yet tried inspecting -device > ccid-card-emulated,? output. In short, libvirt assumes that the > presence of ccid-card-emulated implies that both modes are available > (libvirt's => backend=nss-emulated; mode='host-certificates' => backend=certificates). Is it possible for > qemu to have support for one, but not both, of those modes? If that's > the case, then supporting "backend=nss-emulated/certificates" in -device > ccid-card-emulated,? would be handy for libvirt (for example, it would > be just "backend=certificates" if nss-emulated is not available). But > if it's an all-or-none approach (all backends are available if > ccid-card-emulated is present), then libvirt's current code won't be > impacted by changing the string to the simpler "backend=string". > So turns out this was not actually required (except as a measure to spart a discussion on enums). Since right now it is all or nothing as you say, there is no immediate need for this, so I'll just drop it, and when a QMP solution materialized I can use it. > -- > Eric Blake ebl...@redhat.com+1-801-349-2682 > Libvirt virtualization library http://libvirt.org > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] docs/index.html.in: update KVM url
On 02/07/2011 03:20 AM, Justin Clift wrote: >> -The http://kvm.qumranet.com/kvmwiki";>KVM Linux >> hypervisor >> +The http://www.linux-kvm.org/";>KVM Linux hypervisor >> >> >> The http://lxc.sourceforge.net/";>LXC Linux container >> system >> -- >> 1.7.4 > > ACK. Pushed. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] draft ~ l10n/i18n
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 v3 with comments and fixes from Justin. Justin, please, check it. On 02/06/11 20:00, Zdenek Styblik wrote: [...] ~~~ DRAFTv2 ~~~ # How-to libvirt l10n/i18n We are glad you've decided to help with localization/internationalization of libvirt. Please, pay attention to following lines to save yourself from eventual pitfalls. '.po' files located in '/po' directory are synchronized from Fedora Project[https://translate.fedoraproject.org/projects/p/libvirt/], thus there is little sense to start translating them directly. Here are two ways how you can translate and contribute: ## Optimal way 1st step: Become a translator It's pointless to copy-paste how-to from Fedora Project. How to become a translator is described here - http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Translation_Quick_Start_Guide/index.html Reading the guide, completing all instructions and getting an approval to translate libvirt is going to take some time. Be prepared for it! In a short: * register with Fedora Project * create page about yourself and introduce yourself around * ask to be a translator * and you should be done 2nd step: Download '.po' file '.po' file can be downloaded at https://translate.fedoraproject.org/projects/p/libvirt/ 3rd step: Translate See translator's tools section. 4th step: Upload translated file Upload modified file via web interface at Fedora Project site. Exactly how to upload modified .po file is described in Quick Start Guide mentioned above. ## Alternate way If for some reason you don't want to or can't register at Fedora Project, you still can translate and contribute to libvirt. 1st step: Get '.po' file Download '.po' file from https://translate.fedoraproject.org/projects/p/libvirt/ with language you're going to translate to. Make a backup copy of it 2nd step: Translate See translator's tools section. 3rd step: Make a diff Make a % diff; of the original file and the one you've translated. eg. % diff -urN lang.po.org lang.po > lang.po.patch; Send patch file back to mailing-list and somebody from the team is going to push it at Fedora Project. Why diff? Because it's easier to validate the work you've done, solve eventual conflicts etc. However, this approach has its downsides. First is it brings more workload to libvirt team, second is '.po' file can change in the meantime, because you are not able to "lock it" while you're working at translations. Also, be prepared for rejection doing things this way. ## Translator's tools * KAider KDE4 ~ seems to be dead * gtranslator ~ http://projects.gnome.org/gtranslator/ * poedit ~ http://www.poedit.net/ In case '.po' file in upstream got changed and you need to sync your current work with upstream, you can try your luck with tool written in Perl > http://www.zeratul.org/git/?p=scripts/perl/po-sync/.git;a=summary ~~~ DRAFT ~~~ Mistakes/ideas: ~~~ 1st step: Become a translator *with Fedora Project* ? ~~~ well, it's translator with FPj after all getting an approval ? ~~~ an ? Exactly how to upload modified .po file is described in Quick Start Guide mentioned above. ~~~ better wording is required? ~~~ Implement/fix these without issuing another version of this draft :) Regards, Zdenek - -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: sty...@turnovfree.net jabber: sty...@jabber.turnovfree.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1QSDMACgkQ8MreUbSH7ikWbwCeIvYt0qpbn9IpmIg8y6gdja3s o4wAmgIaH8JacXPism4lFpyz1G389lf/ =AxmZ -END PGP SIGNATURE- -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH 00/16] usb-ccid (v18)
On 02/07/2011 09:56 AM, Eric Blake wrote: [adding libvir-list as well] On 02/07/2011 08:44 AM, Alon Levy wrote: I guess I'll wait a little longer for more feedback? Should I split the enum property separately? it's only used by ccid-card-emualted atm. The only non-cosmetic concern I have about your series is the enum property so I would strongly suggest splitting it. If you did that for v19, it will be pretty close to merge ready. Eric, How does this affect libvirt? could you assume a default set of backends if "-device ccid-card-emulated,?" returns "backend=string" instead of "backend=A/B" ? Hmm. At the moment, libvirt only looks for "ccid-card-emulated" in the -device ? list, and hasn't yet tried inspecting -device ccid-card-emulated,? output. In short, libvirt assumes that the presence of ccid-card-emulated implies that both modes are available (libvirt's => backend=nss-emulated; backend=certificates). Why is libvirt assuming anything about a feature that isn't in upstream QEMU? Regards, Anthony Liguori Is it possible for qemu to have support for one, but not both, of those modes? If that's the case, then supporting "backend=nss-emulated/certificates" in -device ccid-card-emulated,? would be handy for libvirt (for example, it would be just "backend=certificates" if nss-emulated is not available). But if it's an all-or-none approach (all backends are available if ccid-card-emulated is present), then libvirt's current code won't be impacted by changing the string to the simpler "backend=string". -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] Add tx_alg attribute to interface XML for virtio backend
On 02/07/2011 12:06 PM, Eric Blake wrote:
On 02/04/2011 02:00 PM, Laine Stump wrote:
qemu's virtio-net-pci driver allows setting the algorithm used for tx
packets to either "bh" or "timer". I don't know exactly how these
algorithms differ, but someone has requested the ability to choose
between them in libvirt's domain XML. See:
https://bugzilla.redhat.com/show_bug.cgi?id=629662
Same as qemu aio - we don't have to know exactly what the difference is,
to know that someone else who does know the difference wants to be able
to choose :)
...
...
I chose to put this setting as an attribute to rather than as
a sub-element to because it is specific to the virtio-net
driver, not something that is generally usable by all network drivers.
(note that this is the same placement as the "driver name=..."
attribute used to choose kernel vs. userland backend for the
virtio-net driver.)
I take it that tx_alg applies to both options of driver name=... when
using a virtio interface, right?
I assume so, but know little beyond the name of the option :-)
This is a bit troublesome to me, because I can see
lots of new virtio options that could potentially be requested (just
run "qemu-kvm -device virtio-net-pci,?" on a qemu that's version
0.13.0 or newer, and compare that output to potential tunable items in
"-device e1000,?" or "-net tap,..."), so the attribute list could
potentially get quite long (which is something I was concerned about
when I first added the option to select kernel vs. userland backend,
but didn't realize just how many virtio-specific options there were).
I'd like feedback from danpb or DV, since this might be a long-term XML
commitment.
Me too! :-)
Maybe it makes sense to introduce sub-elements of,
according to the driver chosen?
...
bh
But I'm not sure if that is any better.
Well, there is already a element inside that works
similar to and :
0
100
...
One alternative would be to place tx_alg there, and ignore it when model
type != 'virtio'. That seems a bit cheesy, though. Another alternative
would be to put a " element inside that looks just like
memtune, cputune, and interface/tune.
Again, the issue here is concern over the attribute list of
getting excessively long. If that's not an issue, then leaving tx_alg as
a simple attribute will probably be fine.
If the option isn't listed there, the config item is ignored (should
it instead generate a warning log? error out and prevent the domain
from starting?)
I would lean towards erroring out, the same way that we error out if:
is explicitly requested when the kernel module is not present.
Okay. I'll make it that way in the next revision.
[...]
+virBufferVSprintf(&buf, ",tx=%s",
+
virDomainNetVirtioTxAlgTypeToString(net->driver.virtio.tx_alg));
+} else {
+/* What should we do if the option isn't available? log a
+ * warning? prevent the domain from starting? Ignore it?
+ * Right now we're ignoring it.
+ */
This would be the perfect place to error out with
VIR_ERR_CONFIG_UNSUPPORTED.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/6] sysinfo: expose host data from virsh
First requested here: https://www.redhat.com/archives/libvir-list/2011-January/msg00889.html and useful enough that I coded it in one day, hopefully to be in time for the 0.8.8 feature freeze :) Food for thought - right now, only qemu supports this. Should I do a followup patch that moves hostsysinfo out of qemu_conf.h and into src/datatypes.h virConnect instead, as well as some utility routines that make it easier for all hypervisors to choose to cache sysinfo data (if privileged)? Compare to how many (but not all) hypervisors share util.c virGetHostname rather than duplicating the work. Eric Blake (6): sysinfo: expose new API sysinfo: define internal driver API sysinfo: implement the public API sysinfo: implement the remote protocol sysinfo: implement virsh support sysinfo: implement qemu support daemon/remote.c | 25 +++- daemon/remote_dispatch_args.h |1 + daemon/remote_dispatch_prototypes.h |8 ++ daemon/remote_dispatch_ret.h|1 + daemon/remote_dispatch_table.h |5 ++ docs/formatdomain.html.in |4 +- include/libvirt/libvirt.h.in|4 +- src/conf/domain_conf.c | 71 +--- src/driver.h|4 + src/esx/esx_driver.c|3 +- src/libvirt.c | 42 +++- src/libvirt_private.syms|1 + src/libvirt_public.syms |5 ++ src/lxc/lxc_driver.c|1 + src/opennebula/one_driver.c |3 +- src/openvz/openvz_driver.c |3 +- src/phyp/phyp_driver.c |3 +- src/qemu/qemu_driver.c | 17 + src/remote/remote_driver.c | 28 - src/remote/remote_protocol.c| 18 + src/remote/remote_protocol.h| 15 src/remote/remote_protocol.x| 13 +++- src/remote_protocol-structs |6 ++ src/test/test_driver.c |3 +- src/uml/uml_driver.c|1 + src/util/sysinfo.c | 125 ++- src/util/sysinfo.h |5 +- src/vbox/vbox_tmpl.c|1 + src/vmware/vmware_driver.c |5 +- src/xen/xen_driver.c|1 + src/xenapi/xenapi_driver.c |2 + tools/virsh.c | 33 +- tools/virsh.pod |5 ++ 33 files changed, 377 insertions(+), 85 deletions(-) -- 1.7.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 5/6] sysinfo: implement virsh support
* tools/virsh.c (cmdSysinfo): New function.
(hostAndHypervisorCmds): Add it.
* tools/virsh.pod: Document it.
---
Implementing this before qemu support let me test the fallback cases.
tools/virsh.c | 33 -
tools/virsh.pod |5 +
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 1f820e8..be2cd67 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -8223,7 +8223,7 @@ cmdNodeDeviceReset (vshControl *ctl, const vshCmd *cmd)
}
/*
- * "hostkey" command
+ * "hostname" command
*/
static const vshCmdInfo info_hostname[] = {
{"help", N_("print the hypervisor hostname")},
@@ -8281,6 +8281,36 @@ cmdURI (vshControl *ctl, const vshCmd *cmd
ATTRIBUTE_UNUSED)
}
/*
+ * "sysinfo" command
+ */
+static const vshCmdInfo info_sysinfo[] = {
+{"help", N_("print the hypervisor sysinfo")},
+{"desc",
+ N_("output an XML string for the hypervisor sysinfo, if available")},
+{NULL, NULL}
+};
+
+static int
+cmdSysinfo (vshControl *ctl, const vshCmd *cmd ATTRIBUTE_UNUSED)
+{
+char *sysinfo;
+
+if (!vshConnectionUsability(ctl, ctl->conn))
+return FALSE;
+
+sysinfo = virConnectGetSysinfo (ctl->conn, 0);
+if (sysinfo == NULL) {
+vshError(ctl, "%s", _("failed to get sysinfo"));
+return FALSE;
+}
+
+vshPrint (ctl, "%s", sysinfo);
+VIR_FREE(sysinfo);
+
+return TRUE;
+}
+
+/*
* "vncdisplay" command
*/
static const vshCmdInfo info_vncdisplay[] = {
@@ -10417,6 +10447,7 @@ static const vshCmdDef hostAndHypervisorCmds[] = {
{"hostname", cmdHostname, NULL, info_hostname},
{"nodeinfo", cmdNodeinfo, NULL, info_nodeinfo},
{"qemu-monitor-command", cmdQemuMonitorCommand, opts_qemu_monitor_command,
info_qemu_monitor_command},
+{"sysinfo", cmdSysinfo, NULL, info_sysinfo},
{"uri", cmdURI, NULL, info_uri},
{NULL, NULL, NULL, NULL}
};
diff --git a/tools/virsh.pod b/tools/virsh.pod
index bfaa67e..a2ca384 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -132,6 +132,7 @@ group as an option. For example:
freecell NUMA free memory
hostname print the hypervisor hostname
qemu-monitor-command Qemu Monitor Command
+ sysinfoprint the hypervisor sysinfo
uriprint the hypervisor canonical URI
To display detailed information for a specific command, give its name as the
@@ -227,6 +228,10 @@ Prints the hypervisor canonical URI, can be useful in
shell mode.
Print the hypervisor hostname.
+=item B
+
+Print the XML representation of the hypervisor sysinfo, if available.
+
=item B
Returns basic information about the node, like number and type of CPU,
--
1.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/6] sysinfo: implement the public API
* src/libvirt.c (virConnectGetSysinfo): New function.
* docs/formatdomain.html.in: Mention it.
---
Is my cross-page link in formatdomain correct? I didn't see any
other examples of XML documentation linking to an API call.
docs/formatdomain.html.in |4 +++-
src/libvirt.c | 42 +-
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 43c78fc..dd91de7 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -125,7 +125,9 @@
The mode attribute must be specified, and is either
"emulate" (let the hypervisor generate all values), "host" (copy
all of Block 0 and Block 1, except for the UUID, from the host's
- SMBIOS values), or "sysinfo" (use the values in
+ SMBIOS values; the
+ virConnectGetSysinfo call can be
+ used to see what values are copied), or "sysinfo" (use the values in
the sysinfo element). If not
specified, the hypervisor default is used.
Since 0.8.7
diff --git a/src/libvirt.c b/src/libvirt.c
index c65b1e5..479a9b5 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -776,7 +776,7 @@ virRegisterStateDriver(virStateDriverPtr driver)
/**
* virStateInitialize:
- * @privileged: set to 1 if running with root priviledge, 0 otherwise
+ * @privileged: set to 1 if running with root privilege, 0 otherwise
*
* Initialize all virtualization drivers.
*
@@ -1594,6 +1594,46 @@ error:
}
/**
+ * virConnectGetSysinfo:
+ * @conn: pointer to a hypervisor connection
+ * @flags: callers should always pass 0
+ *
+ * This returns the XML description of the sysinfo details for the
+ * host on which the hypervisor is running, in the same format as the
+ * element of a domain XML. This information is generally
+ * available only for hypervisors running with root privileges.
+ *
+ * Returns the XML string which must be freed by the caller, or
+ * NULL if there was an error.
+ */
+char *
+virConnectGetSysinfo (virConnectPtr conn, unsigned int flags)
+{
+DEBUG("conn=%p", conn);
+
+virResetLastError();
+
+if (!VIR_IS_CONNECT(conn)) {
+virLibConnError(VIR_ERR_INVALID_CONN, __FUNCTION__);
+virDispatchError(NULL);
+return NULL;
+}
+
+if (conn->driver->getSysinfo) {
+char *ret = conn->driver->getSysinfo (conn, flags);
+if (!ret)
+goto error;
+return ret;
+}
+
+virLibConnError(VIR_ERR_NO_SUPPORT, __FUNCTION__);
+
+error:
+virDispatchError(conn);
+return NULL;
+}
+
+/**
* virConnectGetMaxVcpus:
* @conn: pointer to the hypervisor connection
* @type: value of the 'type' attribute in the element
--
1.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/6] sysinfo: expose new API
* include/libvirt/libvirt.h.in (virConnectGetSysinfo): Declare.
* src/libvirt_public.syms: Export new symbol.
---
I don't know how the flags argument might be used, if ever, but
better safe than sorry :)
include/libvirt/libvirt.h.in |4 +++-
src/libvirt_public.syms |5 +
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index 7ecbeb6..3913a28 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -4,7 +4,7 @@
* Description: Provides the interfaces of the libvirt library to handle
* virtualized domains
*
- * Copy: Copyright (C) 2005,2006,2010 Red Hat, Inc.
+ * Copy: Copyright (C) 2005-2006 2010-2011 Red Hat, Inc.
*
* See COPYING.LIB for the License of this software
*
@@ -575,6 +575,8 @@ int virConnectGetLibVersion
(virConnectPtr conn,
unsigned long *libVer);
char * virConnectGetHostname (virConnectPtr conn);
char * virConnectGetURI(virConnectPtr conn);
+char * virConnectGetSysinfo(virConnectPtr conn,
+ unsigned int flags);
/*
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 96084ff..1a45be1 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -419,4 +419,9 @@ LIBVIRT_0.8.6 {
virDomainIsUpdated;
} LIBVIRT_0.8.5;
+LIBVIRT_0.8.8 {
+global:
+virConnectGetSysinfo;
+} LIBVIRT_0.8.6;
+
# define new API here using predicted next version number
--
1.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/6] sysinfo: define internal driver API
* src/driver.h (virDrvGetSysinfo): New typedef.
(_virDriver): New callback member.
* src/esx/esx_driver.c (esxDriver): Add stub for driver.
* src/lxc/lxc_driver.c (lxcDriver): Likewise.
* src/opennebula/one_driver.c (oneDriver): Likewise.
* src/openvz/openvz_driver.c (openvzDriver): Likewise.
* src/phyp/phyp_driver.c (phypDriver): Likewise.
* src/qemu/qemu_driver.c (qemuDriver): Likewise.
* src/remote/remote_driver.c (remote_driver): Likewise.
* src/test/test_driver.c (testDriver): Likewise.
* src/uml/uml_driver.c (umlDriver): Likewise.
* src/vbox/vbox_tmpl.c (Driver): Likewise.
* src/vmware/vmware_driver.c (vmwareDriver): Likewise.
* src/xen/xen_driver.c (xenUnifiedDriver): Likewise.
* src/xenapi/xenapi_driver.c (xenapiDriver): Likewise.
---
src/driver.h|4
src/esx/esx_driver.c|3 ++-
src/lxc/lxc_driver.c|1 +
src/opennebula/one_driver.c |3 ++-
src/openvz/openvz_driver.c |3 ++-
src/phyp/phyp_driver.c |3 ++-
src/qemu/qemu_driver.c |1 +
src/remote/remote_driver.c |3 ++-
src/test/test_driver.c |3 ++-
src/uml/uml_driver.c|1 +
src/vbox/vbox_tmpl.c|1 +
src/vmware/vmware_driver.c |5 -
src/xen/xen_driver.c|1 +
src/xenapi/xenapi_driver.c |2 ++
14 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/src/driver.h b/src/driver.h
index 114002d..7451004 100644
--- a/src/driver.h
+++ b/src/driver.h
@@ -83,6 +83,9 @@ typedef char *
(*virDrvGetHostname)(virConnectPtr conn);
typedef char *
(*virDrvGetURI) (virConnectPtr conn);
+typedef char *
+(*virDrvGetSysinfo) (virConnectPtr conn,
+ unsigned int flags);
typedef int
(*virDrvGetMaxVcpus) (virConnectPtr conn,
const char *type);
@@ -515,6 +518,7 @@ struct _virDriver {
virDrvGetVersion version;
virDrvGetLibVersionlibvirtVersion;
virDrvGetHostname getHostname;
+virDrvGetSysinfogetSysinfo;
virDrvGetMaxVcpus getMaxVcpus;
virDrvNodeGetInfo nodeGetInfo;
virDrvGetCapabilities getCapabilities;
diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
index c66df0e..97f3dbe 100644
--- a/src/esx/esx_driver.c
+++ b/src/esx/esx_driver.c
@@ -2,7 +2,7 @@
/*
* esx_driver.c: core driver functions for managing VMware ESX hosts
*
- * Copyright (C) 2010 Red Hat, Inc.
+ * Copyright (C) 2010-2011 Red Hat, Inc.
* Copyright (C) 2009-2010 Matthias Bolte
* Copyright (C) 2009 Maximilian Wilhelm
*
@@ -4557,6 +4557,7 @@ static virDriver esxDriver = {
esxGetVersion, /* version */
NULL,/* libvirtVersion (impl. in libvirt.c) */
esxGetHostname, /* hostname */
+NULL,/* getSysinfo */
NULL,/* getMaxVcpus */
esxNodeGetInfo, /* nodeGetInfo */
esxGetCapabilities, /* getCapabilities */
diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c
index 2e8a845..0f78579 100644
--- a/src/lxc/lxc_driver.c
+++ b/src/lxc/lxc_driver.c
@@ -2833,6 +2833,7 @@ static virDriver lxcDriver = {
lxcVersion, /* version */
NULL, /* libvirtVersion (impl. in libvirt.c) */
virGetHostname, /* getHostname */
+NULL, /* getSysinfo */
NULL, /* getMaxVcpus */
nodeGetInfo, /* nodeGetInfo */
lxcGetCapabilities, /* getCapabilities */
diff --git a/src/opennebula/one_driver.c b/src/opennebula/one_driver.c
index 6945f91..75d7b9a 100644
--- a/src/opennebula/one_driver.c
+++ b/src/opennebula/one_driver.c
@@ -1,6 +1,6 @@
/*---*/
/*
- * Copyright (C) 2010 Red Hat, Inc.
+ * Copyright (C) 2010-2011 Red Hat, Inc.
* Copyright 2002-2009, Distributed Systems Architecture Group, Universidad
* Complutense de Madrid (dsa-research.org)
*
@@ -732,6 +732,7 @@ static virDriver oneDriver = {
oneVersion, /* version */
NULL, /* libvirtVersion (impl. in libvirt.c) */
NULL, /* getHostname */
+NULL, /* getSysinfo */
NULL, /* getMaxVcpus */
NULL, /* nodeGetInfo */
oneGetCapabilities, /* getCapabilities */
diff --git a/src/openvz/openvz_driver.c b/src/openvz/openvz_driver.c
index 1dde004..00d378a 100644
--- a/src/openvz/openvz_driver.c
+++ b/src/openvz/openvz_driver.c
@@ -1,7 +1,7 @@
/*
* openvz_driver.c: core driver methods for managing OpenVZ VEs
*
- * Copyright (C) 2010 Red Hat, Inc.
+ * Copyright (C) 2010-2011 Red Hat, Inc.
* Copyright (C) 2006, 2007 Binary Karma
* Copyright (C) 2006 Shuveb Hussain
* Copyright (C) 2007 Anoop Joe Cyriac
@@ -1572,6 +1572,7 @@ static virDriver openvzDriver = {
openvzGetVersion, /* version */
NULL, /* libvirtVersion (impl. in libvirt.c) */
NULL, /* getHostname */
+NULL, /* getSysinfo */
[libvirt] [PATCH 4/6] sysinfo: implement the remote protocol
Done by editing the first three files, then running
'make -C src rpcgen', then editing src/remote_protocol-structs
to match.
* daemon/remote.c (remoteDispatchGetSysinfo): New function.
* src/remote/remote_driver.c (remoteGetSysinfo, remote_driver):
Client side serialization.
* src/remote/remote_protocol.x (remote_get_sysinfo_args)
(remote_get_sysinfo_ret): New types.
(REMOTE_PROC_GET_SYSINFO): New enum value.
* daemon/remote_dispatch_args.h: Regenerate.
* daemon/remote_dispatch_prototypes.h: Likewise.
* daemon/remote_dispatch_ret.h: Likewise.
* daemon/remote_dispatch_table.h: Likewise.
* src/remote/remote_protocol.c: Likewise.
* src/remote/remote_protocol.h: Likewise.
* src/remote_protocol-structs: Likewise.
---
daemon/remote.c | 25 -
daemon/remote_dispatch_args.h |1 +
daemon/remote_dispatch_prototypes.h |8
daemon/remote_dispatch_ret.h|1 +
daemon/remote_dispatch_table.h |5 +
src/remote/remote_driver.c | 27 ++-
src/remote/remote_protocol.c| 18 ++
src/remote/remote_protocol.h| 15 +++
src/remote/remote_protocol.x| 13 +++--
src/remote_protocol-structs |6 ++
10 files changed, 115 insertions(+), 4 deletions(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index aa6a1a4..de45ff9 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -1,7 +1,7 @@
/*
* remote.c: handlers for RPC method calls
*
- * Copyright (C) 2007-2010 Red Hat, Inc.
+ * Copyright (C) 2007-2011 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -585,6 +585,29 @@ remoteDispatchGetUri (struct qemud_server *server
ATTRIBUTE_UNUSED,
}
static int
+remoteDispatchGetSysinfo (struct qemud_server *server ATTRIBUTE_UNUSED,
+ struct qemud_client *client ATTRIBUTE_UNUSED,
+ virConnectPtr conn,
+ remote_message_header *hdr ATTRIBUTE_UNUSED,
+ remote_error *rerr,
+ remote_get_sysinfo_args *args,
+ remote_get_sysinfo_ret *ret)
+{
+unsigned int flags;
+char *sysinfo;
+
+flags = args->flags;
+sysinfo = virConnectGetSysinfo (conn, flags);
+if (sysinfo == NULL) {
+remoteDispatchConnError(rerr, conn);
+return -1;
+}
+
+ret->sysinfo = sysinfo;
+return 0;
+}
+
+static int
remoteDispatchGetMaxVcpus (struct qemud_server *server ATTRIBUTE_UNUSED,
struct qemud_client *client ATTRIBUTE_UNUSED,
virConnectPtr conn,
diff --git a/daemon/remote_dispatch_args.h b/daemon/remote_dispatch_args.h
index 221af88..57962d1 100644
--- a/daemon/remote_dispatch_args.h
+++ b/daemon/remote_dispatch_args.h
@@ -171,3 +171,4 @@
remote_domain_get_vcpus_flags_args val_remote_domain_get_vcpus_flags_args;
remote_domain_open_console_args val_remote_domain_open_console_args;
remote_domain_is_updated_args val_remote_domain_is_updated_args;
+remote_get_sysinfo_args val_remote_get_sysinfo_args;
diff --git a/daemon/remote_dispatch_prototypes.h
b/daemon/remote_dispatch_prototypes.h
index 4a5246f..e59701a 100644
--- a/daemon/remote_dispatch_prototypes.h
+++ b/daemon/remote_dispatch_prototypes.h
@@ -730,6 +730,14 @@ static int remoteDispatchGetMaxVcpus(
remote_error *err,
remote_get_max_vcpus_args *args,
remote_get_max_vcpus_ret *ret);
+static int remoteDispatchGetSysinfo(
+struct qemud_server *server,
+struct qemud_client *client,
+virConnectPtr conn,
+remote_message_header *hdr,
+remote_error *err,
+remote_get_sysinfo_args *args,
+remote_get_sysinfo_ret *ret);
static int remoteDispatchGetType(
struct qemud_server *server,
struct qemud_client *client,
diff --git a/daemon/remote_dispatch_ret.h b/daemon/remote_dispatch_ret.h
index c01f3ba..78e5469 100644
--- a/daemon/remote_dispatch_ret.h
+++ b/daemon/remote_dispatch_ret.h
@@ -138,3 +138,4 @@
remote_domain_get_memory_parameters_ret
val_remote_domain_get_memory_parameters_ret;
remote_domain_get_vcpus_flags_ret val_remote_domain_get_vcpus_flags_ret;
remote_domain_is_updated_ret val_remote_domain_is_updated_ret;
+remote_get_sysinfo_ret val_remote_get_sysinfo_ret;
diff --git a/daemon/remote_dispatch_table.h b/daemon/remote_dispatch_table.h
index 3e55424..5d27390 100644
--- a/daemon/remote_dispatch_table.h
+++ b/daemon/remote_dispatch_table.h
@@ -1017,3 +1017,8 @@
.args_filter = (xdrproc_t) xdr_remote_domain_is_updated_args,
.ret_filter = (xdrproc_t) xdr_remote_domain_is_updated_ret,
},
+{ /* GetSysinfo => 203 */
+.fn = (dispatch_fn) remoteDispatchGetSysinfo,
+.args_filter = (xdrproc_t) xdr_remote_get_sysinfo_args,
+.ret_filter = (xdrproc_t) xdr_remote_get_sysinfo_ret,
+}
[libvirt] [PATCH 6/6] sysinfo: implement qemu support
* src/util/sysinfo.h (virSysinfoFormat): New prototype.
* src/conf/domain_conf.c (virDomainSysinfoDefFormat): Move guts...
* src/util/sysinfo.c (virSysinfoFormat): ...into new function.
* src/libvirt_private.syms: Export it.
* src/qemu/qemu_driver.c (qemuGetSysinfo): New function.
(qemuDriver): Install it.
---
Tested both with qemu:///system (works!) and qemu:///session
(error: unsupported configuration: Host SMBIOS information is not available)
The prefix hack is necessary so that I can use "" or " " as
the leading indentation, depending on host sysinfo vs. domain,
so it's not quite straight code motion.
src/conf/domain_conf.c | 71 ++
src/libvirt_private.syms |1 +
src/qemu/qemu_driver.c | 18 ++-
src/util/sysinfo.c | 125 -
src/util/sysinfo.h |5 ++-
5 files changed, 148 insertions(+), 72 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 9369ed4..401aee7 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -7143,75 +7143,12 @@ static int
virDomainSysinfoDefFormat(virBufferPtr buf,
virSysinfoDefPtr def)
{
-const char *type = virDomainSysinfoTypeToString(def->type);
+char *format = virSysinfoFormat(def, " ");
-if (!type) {
-virDomainReportError(VIR_ERR_INTERNAL_ERROR,
- _("unexpected sysinfo type model %d"),
- def->type);
+if (!format)
return -1;
-}
-
-virBufferVSprintf(buf, " \n", type);
-if ((def->bios_vendor != NULL) || (def->bios_version != NULL) ||
-(def->bios_date != NULL) || (def->bios_release != NULL)) {
-virBufferAddLit(buf, "\n");
-if (def->bios_vendor != NULL)
-virBufferEscapeString(buf,
- " %s\n",
- def->bios_vendor);
-if (def->bios_version != NULL)
-virBufferEscapeString(buf,
- " %s\n",
- def->bios_version);
-if (def->bios_date != NULL)
-virBufferEscapeString(buf,
- " %s\n",
- def->bios_date);
-if (def->bios_release != NULL)
-virBufferEscapeString(buf,
- " %s\n",
- def->bios_release);
-virBufferAddLit(buf, "\n");
-}
-if ((def->system_manufacturer != NULL) || (def->system_product != NULL) ||
-(def->system_version != NULL) || (def->system_serial != NULL) ||
-(def->system_uuid != NULL) || (def->system_sku != NULL) ||
-(def->system_family != NULL)) {
-virBufferAddLit(buf, "\n");
-if (def->system_manufacturer != NULL)
-virBufferEscapeString(buf,
- " %s\n",
- def->system_manufacturer);
-if (def->system_product != NULL)
-virBufferEscapeString(buf,
- " %s\n",
- def->system_product);
-if (def->system_version != NULL)
-virBufferEscapeString(buf,
- " %s\n",
- def->system_version);
-if (def->system_serial != NULL)
-virBufferEscapeString(buf,
- " %s\n",
- def->system_serial);
-if (def->system_uuid != NULL)
-virBufferEscapeString(buf,
- " %s\n",
- def->system_uuid);
-if (def->system_sku != NULL)
-virBufferEscapeString(buf,
- " %s\n",
- def->system_sku);
-if (def->system_family != NULL)
-virBufferEscapeString(buf,
- " %s\n",
- def->system_family);
-virBufferAddLit(buf, "\n");
-}
-
-virBufferAddLit(buf, " \n");
-
+virBufferAdd(buf, format, strlen(format));
+VIR_FREE(format);
return 0;
}
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 88e270c..6348e0d 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -798,6 +798,7 @@ virStorageFileProbeFormatFromFD;
# sysinfo.h
virSysinfoDefFree;
+virSysinfoFormat;
virSysinfoRead;
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 87d228b..52ea98e 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3275,6 +3275,22 @@ static int kvmGetMaxVCPUs(void) {
}
+static char *
+qemuGetSysinfo(virConnectPtr conn, unsigned int flags)
+{
+struct qemud_driver *driver = conn->privateData;
+
+virCheckFlags(0, NULL);
+
+if (!driver-
[libvirt] [PATCH 0/6 v3] Add blkio cgroup support
Hi This patchset adds blkio cgroup support for qemu and lxc. [PATCH 1/6] cgroup: Enable cgroup hierarchy for blkio cgroup [PATCH 2/6 v3] cgroup: Implement blkio.weight tuning API. [PATCH 3/6] Update XML Schema for new entries. [PATCH 4/6 v3] qemu: Implement blkio tunable XML configuration and parsing. [PATCH 5/6 v3] LXC: LXC Blkio weight configuration support. [PATCH 6/6] Add documentation for blkiotune elements. Will post a patchset to implement virsh command "blkiotune" to tune blkio cgroup parameter later on. v2 -> v3 Changes: o Remove an unused local variable o Rename virCgroup(Set/Get)Weight to virCgroup(Set/Get)BlkioWeight o Add documentation in docs/formatdomain.html.in o Update XML Schema for new entries. docs/formatdomain.html.in | 10 ++ docs/schemas/domain.rng | 20 src/conf/domain_conf.c| 13 + src/conf/domain_conf.h|4 src/libvirt_private.syms |2 ++ src/lxc/lxc_controller.c | 10 ++ src/qemu/qemu_cgroup.c| 16 +++- src/qemu/qemu_conf.c |3 ++- src/util/cgroup.c | 41 - src/util/cgroup.h |4 10 files changed, 120 insertions(+), 3 deletions(-) Thanks Gui -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/6] cgroup: Enable cgroup hierarchy for blkio cgroup
Enable cgroup hierarchy for blkio cgroup
Acked-by: Daniel P. Berrange
Signed-off-by: Gui Jianfeng
---
src/util/cgroup.c |2 +-
src/util/cgroup.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/util/cgroup.c b/src/util/cgroup.c
index cd9caba..309f4e9 100644
--- a/src/util/cgroup.c
+++ b/src/util/cgroup.c
@@ -37,7 +37,7 @@
VIR_ENUM_IMPL(virCgroupController, VIR_CGROUP_CONTROLLER_LAST,
"cpu", "cpuacct", "cpuset", "memory", "devices",
- "freezer");
+ "freezer", "blkio");
struct virCgroupController {
int type;
diff --git a/src/util/cgroup.h b/src/util/cgroup.h
index 964da7a..67b1299 100644
--- a/src/util/cgroup.h
+++ b/src/util/cgroup.h
@@ -22,6 +22,7 @@ enum {
VIR_CGROUP_CONTROLLER_MEMORY,
VIR_CGROUP_CONTROLLER_DEVICES,
VIR_CGROUP_CONTROLLER_FREEZER,
+VIR_CGROUP_CONTROLLER_BLKIO,
VIR_CGROUP_CONTROLLER_LAST
};
--
1.7.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/6 v3] cgroup: Implement blkio.weight tuning API.
Implement blkio.weight tuning API.
Acked-by: Daniel P. Berrange
Signed-off-by: Gui Jianfeng
---
src/libvirt_private.syms |2 ++
src/util/cgroup.c| 39 +++
src/util/cgroup.h|3 +++
3 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 88e270c..490901e 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -77,6 +77,8 @@ virCgroupMounted;
virCgroupRemove;
virCgroupSetCpuShares;
virCgroupSetFreezerState;
+virCgroupSetBlkioWeight;
+virCgroupGetBlkioWeight;
virCgroupSetMemory;
virCgroupSetMemoryHardLimit;
virCgroupSetMemorySoftLimit;
diff --git a/src/util/cgroup.c b/src/util/cgroup.c
index 309f4e9..bb3f334 100644
--- a/src/util/cgroup.c
+++ b/src/util/cgroup.c
@@ -851,6 +851,45 @@ int virCgroupForDomain(virCgroupPtr driver
ATTRIBUTE_UNUSED,
#endif
/**
+ * virCgroupSetBlkioWeight:
+ *
+ * @group: The cgroup to change io weight for
+ * @weight: The Weight for this cgroup
+ *
+ * Returns: 0 on success
+ */
+int virCgroupSetBlkioWeight(virCgroupPtr group, unsigned long weight)
+{
+if (weight > 1000 || weight < 100)
+return -EINVAL;
+
+return virCgroupSetValueU64(group,
+VIR_CGROUP_CONTROLLER_BLKIO,
+"blkio.weight",
+weight);
+}
+
+/**
+ * virCgroupGetBlkioWeight:
+ *
+ * @group: The cgroup to get weight for
+ * @Weight: Pointer to returned weight
+ *
+ * Returns: 0 on success
+ */
+int virCgroupGetBlkioWeight(virCgroupPtr group, unsigned long *weight)
+{
+long long unsigned int __weight;
+int ret;
+ret = virCgroupGetValueU64(group,
+ VIR_CGROUP_CONTROLLER_BLKIO,
+ "blkio.weight", &__weight);
+if (ret == 0)
+*weight = (unsigned long) __weight;
+return ret;
+}
+
+/**
* virCgroupSetMemory:
*
* @group: The cgroup to change memory for
diff --git a/src/util/cgroup.h b/src/util/cgroup.h
index 67b1299..f1a47dc 100644
--- a/src/util/cgroup.h
+++ b/src/util/cgroup.h
@@ -41,6 +41,9 @@ int virCgroupForDomain(virCgroupPtr driver,
int virCgroupAddTask(virCgroupPtr group, pid_t pid);
+int virCgroupSetBlkioWeight(virCgroupPtr group, unsigned long weight);
+int virCgroupGetBlkioWeight(virCgroupPtr group, unsigned long *weight);
+
int virCgroupSetMemory(virCgroupPtr group, unsigned long long kb);
int virCgroupGetMemoryUsage(virCgroupPtr group, unsigned long *kb);
--
1.7.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/6] Update XML Schema for new entries.
Update XML Schema for new entries. Signed-off-by: Gui Jianfeng --- docs/schemas/domain.rng | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index 53c07fd..a9391d3 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -306,6 +306,18 @@ + + + + + + + + + + + + @@ -2150,6 +2162,7 @@ A domain name shoul be made of ascii, numbers, _-+ and is non-empty UUID currently allows only the 32 characters strict syntax memoryKB request at least 4Mbytes though Xen will grow bigger if too low + WEIGHT currently is in range [100, 1000] --> @@ -2182,6 +2195,13 @@ -1 + + + [0-9]+ + 100 + 1000 + + [0-9]+ -- 1.7.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 4/6 v3] qemu: Implement blkio tunable XML configuration and parsing.
Implement blkio tunable XML configuration and parsing.
Reviewed-by: "Nikunj A. Dadhania"
Signed-off-by: Gui Jianfeng
---
src/conf/domain_conf.c | 13 +
src/conf/domain_conf.h |4
src/qemu/qemu_cgroup.c | 16 +++-
src/qemu/qemu_conf.c |3 ++-
4 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 9369ed4..94369e2 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -5149,6 +5149,11 @@ static virDomainDefPtr virDomainDefParseXML(virCapsPtr
caps,
if (node)
def->mem.hugepage_backed = 1;
+/* Extract blkio cgroup tunables */
+if (virXPathULong("string(./blkiotune/weight)", ctxt,
+ &def->blkio.weight) < 0)
+def->blkio.weight = 0;
+
/* Extract other memory tunables */
if (virXPathULong("string(./memtune/hard_limit)", ctxt,
&def->mem.hard_limit) < 0)
@@ -7682,6 +7687,14 @@ char *virDomainDefFormat(virDomainDefPtr def,
virBufferVSprintf(&buf, " %lu\n",
def->mem.cur_balloon);
+/* add blkiotune only if there are any */
+if (def->blkio.weight) {
+virBufferVSprintf(&buf, " \n");
+virBufferVSprintf(&buf, "%lu\n",
+ def->blkio.weight);
+virBufferVSprintf(&buf, " \n");
+}
+
/* add memtune only if there are any */
if (def->mem.hard_limit || def->mem.soft_limit || def->mem.min_guarantee ||
def->mem.swap_hard_limit)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 5d35e43..80d58a0 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1029,6 +1029,10 @@ struct _virDomainDef {
char *description;
struct {
+unsigned long weight;
+} blkio;
+
+struct {
unsigned long max_balloon;
unsigned long cur_balloon;
unsigned long hugepage_backed;
diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c
index 82d3695..0622c9e 100644
--- a/src/qemu/qemu_cgroup.c
+++ b/src/qemu/qemu_cgroup.c
@@ -54,7 +54,6 @@ int qemuCgroupControllerActive(struct qemud_driver *driver,
return 0;
}
-
int qemuSetupDiskPathAllow(virDomainDiskDefPtr disk ATTRIBUTE_UNUSED,
const char *path,
size_t depth ATTRIBUTE_UNUSED,
@@ -270,6 +269,21 @@ int qemuSetupCgroup(struct qemud_driver *driver,
}
}
+if (qemuCgroupControllerActive(driver, VIR_CGROUP_CONTROLLER_BLKIO)) {
+if (vm->def->blkio.weight != 0) {
+rc = virCgroupSetBlkioWeight(cgroup, vm->def->blkio.weight);
+if(rc != 0) {
+virReportSystemError(-rc,
+ _("Unable to set io weight for domain
%s"),
+ vm->def->name);
+goto cleanup;
+}
+}
+} else {
+qemuReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+_("Block I/O tuning is not available on this host"));
+}
+
if ((rc = qemuCgroupControllerActive(driver,
VIR_CGROUP_CONTROLLER_MEMORY))) {
if (vm->def->mem.hard_limit != 0) {
rc = virCgroupSetMemoryHardLimit(cgroup, vm->def->mem.hard_limit);
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 9f9e99e..9ba60b1 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -303,7 +303,8 @@ int qemudLoadDriverConfig(struct qemud_driver *driver,
driver->cgroupControllers =
(1 << VIR_CGROUP_CONTROLLER_CPU) |
(1 << VIR_CGROUP_CONTROLLER_DEVICES) |
-(1 << VIR_CGROUP_CONTROLLER_MEMORY);
+(1 << VIR_CGROUP_CONTROLLER_MEMORY) |
+(1 << VIR_CGROUP_CONTROLLER_BLKIO);
}
for (i = 0 ; i < VIR_CGROUP_CONTROLLER_LAST ; i++) {
if (driver->cgroupControllers & (1 << i)) {
--
1.7.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 5/6 v3] LXC: LXC Blkio weight configuration support.
LXC Blkio weight configuration support.
Reviewed-by: "Nikunj A. Dadhania"
Signed-off-by: Gui Jianfeng
---
src/lxc/lxc_controller.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c
index af0b70c..0db6673 100644
--- a/src/lxc/lxc_controller.c
+++ b/src/lxc/lxc_controller.c
@@ -104,6 +104,16 @@ static int lxcSetContainerResources(virDomainDefPtr def)
goto cleanup;
}
+if (def->blkio.weight) {
+rc = virCgroupSetBlkioWeight(cgroup, def->blkio.weight);
+if (rc != 0) {
+virReportSystemError(-rc,
+ _("Unable to set Blkio weight for domain %s"),
+ def->name);
+goto cleanup;
+}
+}
+
rc = virCgroupSetMemory(cgroup, def->mem.max_balloon);
if (rc != 0) {
virReportSystemError(-rc,
--
1.7.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 6/6] Add documentation for blkiotune elements.
Add documentation for blkiotune elements. Signed-off-by: Gui Jianfeng --- docs/formatdomain.html.in | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 43c78fc..407e5f4 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -275,6 +275,9 @@+ + 800 +1048576 131072 @@ -298,6 +301,13 @@ hugepages element set within it. This tells the hypervisor that the guest should have its memory allocated using hugepages instead of the normal native page size. + blkiotune + The optional blkiotune element provides the ability + to tune Blkio cgroup tuneable parameters for the domain. If this is + omitted, OS will provides the default values. + weight + The optional weight element is the I/O weight of the + guest. The value should be in range [100, 1000]. memtune The optional memtune element provides details regarding the memory tuneable parameters for the domain. If this is -- 1.7.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
