Re: [libvirt] how to pass qemu options?
David Abrahams wrote: I normally launch my kvm VM from the command line with -redir tcp:3389:3389 but have been unable to find a way to set up virt-manager to launch it the same way. Ditto for other qemu options such as -soundhw all. Is there a way? Not directly in the config. Usual trick is to create a wrapper script like this (for a serial console in that case) ... [EMAIL PROTECTED] f8-32]# cat /root/bin/qemu-serial #!/bin/sh exec /usr/bin/qemu-kvm $@ -serial telnet::,server,nowait,nodelay ... then edit the xml config to make the emulator tag point to the wrapper script instead of /usr/bin/qemu-kvm. Hmm, maybe the emulator tag should get a args attribute, so one can do that kind of stuff without wrapper scripts, like this: domain type='kvm' [ ... ] devices emulator args=-redir .../usr/bin/qemu-kvm/emulator [ ... ] The usual ones should be supported by libvirt directly of course. Serial console is in cvs meanwhile, I've seen also sound support patches. But for unusual configurations and debugging purposes it would be quite handy to have the additional args directly in the config and not hidden somewhere in a separate script ... comments? cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Remove use of strcmp, etc
Daniel P. Berrange [EMAIL PROTECTED] wrote:
On Fri, May 09, 2008 at 11:40:39PM +0200, Jim Meyering wrote:
Daniel P. Berrange [EMAIL PROTECTED] wrote:
This patch removes all use of strcmp, strncmp, strcasecmp and strncasecmp
in favour of the equality macros we have defined in internal.h, eg STREQ,
STRNEQ, STRNEQLEN, STREQLEN, etc, etc
Nice. With that, you can remove sc_prohibit_strcmp
from the list of disabled checks in Makefile.cfg.
I have comitted the patch and enabled this check now
You might want to extend the corresponding regexp in Makefile.maint
to prohibit the other completely excluded functions like strncmp.
My grep regex foo isn't upto scratch on this - gimme perl ! Feel free to
add it if you have a chance though.
Yeah, Perl regexps are great, but grep -E is very similar.
The business with '' below doesn't help -- that is solely to
obscure strings that would otherwise trigger a false-positive match.
From fd867ed796a94b32769259db19b8927d9dcd2d16 Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Thu, 15 May 2008 09:07:44 +0200
Subject: [PATCH] * Makefile.maint (sc_prohibit_strcmp): Also prohibit strncmp.
---
Makefile.maint |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Makefile.maint b/Makefile.maint
index 0f79ed7..a593ae2 100644
--- a/Makefile.maint
+++ b/Makefile.maint
@@ -90,8 +90,9 @@ sc_prohibit_atoi_atof:
12; exit 1; } || :
# Use STREQ rather than comparing strcmp == 0, or != 0.
+# Similarly, use STREQLEN or STRPREFIX rather than strncmp.
sc_prohibit_strcmp:
- @grep -nE '! *str''cmp *\(|\str''cmp *\([^)]+\) *==' \
+ @grep -nE '! *str''n?cmp *\(|\str''n?cmp *\([^)]+\) *==' \
$$($(VC_LIST_EXCEPT)) \
{ echo '$(ME): use STREQ in place of the above uses of str''cmp' \
12; exit 1; } || :
--
1.5.5.1.148.gbc1be
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirtd cpu usage
hi there
i'm playing on debian lenny with kvm-66/libvirt-0.4.2 .
if i run top, i see libvirtd is top cpu consumer. if i connect with
strace to libvirtd, i see a thousand times this message:
poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLERR|POLLHUP},
{fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=8, events=POLLIN}, {fd=13,
events=POLLIN|POLLERR|POLLHUP, revents=POLLHUP}, {fd=15,
events=POLLIN|POLLERR|POLLHUP, revents=POLLHUP}, {fd=17,
events=POLLIN|POLLERR|POLLHUP}, {fd=19, events=POLLIN|POLLERR|POLLHUP}],
8, -1) = 2
if i stop libvirtd and start the guest myself on cli, the guest is much
faster.
- Thomas
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirtd cpu usage
On Thu, 15 May 2008, Thomas Mueller wrote:
i'm playing on debian lenny with kvm-66/libvirt-0.4.2 .
if i run top, i see libvirtd is top cpu consumer. if i connect with
strace to libvirtd, i see a thousand times this message:
poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLERR|POLLHUP},
{fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=8, events=POLLIN}, {fd=13,
events=POLLIN|POLLERR|POLLHUP, revents=POLLHUP}, {fd=15,
events=POLLIN|POLLERR|POLLHUP, revents=POLLHUP}, {fd=17,
events=POLLIN|POLLERR|POLLHUP}, {fd=19, events=POLLIN|POLLERR|POLLHUP}],
8, -1) = 2
if i stop libvirtd and start the guest myself on cli, the guest is much
faster.
root 21929 0.0 0.0 62584 4084 pts/2S+ May14 0:00 libvirtd
-l
This is my libvirtd (cvs) nothing happens.
Stefan
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Domain XML format using defined storage volume
I have now a 'netapp'-pool, and lun-0..4. They all have a path. disk type='block' source dev='?path?' target dev='xvda' bus='xen'/ /disk Now I wonder, is it possible to have here somethinglike storage://netapp/lun-0? Or should I use the path that comes out of the vol-list? From the standpoint: we make it easy for the user I would prefer not to provide a Linux specific path. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [BUG] second libvirtd breaks the first
By accident I ran a second instance of libvirtd. This second instance did not terminate the first instance nor did it detect there was already a running instance. By killing the second instance the first did not work anymore. Next to this, why does libvirtd terminate its iSCSI connections upon stop? I saw it cannot gracefully 'reuse' existing sessions, but it is absurd that restarting libvirtd would kill all running VMs on a host using iSCSI, or not able to get a storage pool up because it is already logged in to it. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] how to pass qemu options?
on Thu May 15 2008, Gerd Hoffmann kraxel-AT-redhat.com wrote: David Abrahams wrote: I normally launch my kvm VM from the command line with -redir tcp:3389:3389 but have been unable to find a way to set up virt-manager to launch it the same way. Ditto for other qemu options such as -soundhw all. Is there a way? Not directly in the config. Usual trick is to create a wrapper script like this (for a serial console in that case) ... [EMAIL PROTECTED] f8-32]# cat /root/bin/qemu-serial #!/bin/sh exec /usr/bin/qemu-kvm $@ -serial telnet::,server,nowait,nodelay ... then edit the xml config to make the emulator tag point to the wrapper script instead of /usr/bin/qemu-kvm. I thought of that, but was hoping there was a cleaner approach. Hmm, maybe the emulator tag should get a args attribute, so one can do that kind of stuff without wrapper scripts, like this: domain type='kvm' [ ... ] devices emulator args=-redir .../usr/bin/qemu-kvm/emulator [ ... ] Yes, please. The usual ones should be supported by libvirt directly of course. Serial console is in cvs meanwhile, I've seen also sound support patches. But for unusual configurations and debugging purposes it would be quite handy to have the additional args directly in the config and not hidden somewhere in a separate script ... comments? Yesplease, please. :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] how to pass qemu options?
On Thu, May 15, 2008 at 09:10:31AM +0200, Gerd Hoffmann wrote: David Abrahams wrote: I normally launch my kvm VM from the command line with -redir tcp:3389:3389 but have been unable to find a way to set up virt-manager to launch it the same way. Ditto for other qemu options such as -soundhw all. Is there a way? Not directly in the config. Usual trick is to create a wrapper script like this (for a serial console in that case) ... [EMAIL PROTECTED] f8-32]# cat /root/bin/qemu-serial #!/bin/sh exec /usr/bin/qemu-kvm $@ -serial telnet::,server,nowait,nodelay ... then edit the xml config to make the emulator tag point to the wrapper script instead of /usr/bin/qemu-kvm. Hmm, maybe the emulator tag should get a args attribute, so one can do that kind of stuff without wrapper scripts, like this: domain type='kvm' [ ... ] devices emulator args=-redir .../usr/bin/qemu-kvm/emulator [ ... ] The usual ones should be supported by libvirt directly of course. Serial console is in cvs meanwhile, I've seen also sound support patches. But for unusual configurations and debugging purposes it would be quite handy to have the additional args directly in the config and not hidden somewhere in a separate script ... We explicitly do not support passing arbitrary arguments to QEMU. The libvirt XML format has to be portable have clearly defined semantics. Adding QEMU specifics args clearly violates that requirement. Furthermore we cannot guarentee the behaviour of QEMU when adding extra arguments, since one arg may change / override the behaviour of another. We've hit this problem in the past with -nographics overriding the monitor device setup thus breaking our control of QEMU. There's similar issues with the various ways to specify disks overriding each other While you are free to define a wrapper around QEMU to pass extra args, be aware that this is completely unsupportable we can make no guarentees that your wrapper will continue to run with the same semantics in future libvirt releases. Regards, Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] how to pass qemu options?
Daniel P. Berrange wrote: We explicitly do not support passing arbitrary arguments to QEMU. Supporting and implementing are two different things IMHO. It is pretty clear that *supporting* such a configuration is impossible and that running it on production systems is a really bad idea for the reasons outlined. Nevertheless being able to pass random additional arguments to $emulator is required for any serious development work. I *hate* to having to create a wrapper script each time I need to pass in additional parameters, and I'd *love* to see libvirt being a bit more developer friendly. libvirt tools should make my life easier, not harder. That includes my development work, because using that stuff on a daily base will improve the quality alot. If I stop using libvirt for xenner development because it is easier to get the job done without we all lose. cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] how to pass qemu options?
On Thu, 15 May 2008, Gerd Hoffmann wrote: It is pretty clear that *supporting* such a configuration is impossible and that running it on production systems is a really bad idea for the reasons outlined. Nevertheless being able to pass random additional arguments to $emulator is required for any serious development work. I *hate* to having to create a wrapper script each time I need to pass in additional parameters, and I'd *love* to see libvirt being a bit more developer friendly. libvirt tools should make my life easier, not harder. That includes my development work, because using that stuff on a daily base will improve the quality alot. If I stop using libvirt for xenner development because it is easier to get the job done without we all lose. I support this idea. And also want to point out that as far as I can see now in the documentation, libvirt isn't the holy grail that is semantically correct everywhere from the start (examples: relation between storage pools and the actual domains, statistics of network interfaces by domains, etc.) Adding features that are enabled with #ifdef HAVE_DEVELOPMENT would be a good thing. Also handeling things that are imported in libvirt as 'relative' pointers, and never having to refer to something os/distro specific would be a great starting point. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Bind to ip_addr support.
On Wed, 14 May 2008, Daniel P. Berrange wrote: On Sat, May 10, 2008 at 06:43:11PM +0200, Stefan de Konink wrote: On Sat, 10 May 2008, Daniel P. Berrange wrote: The code all looks good to me, but can you also provide an update for the default configuration file in qemud/libvirtd.conf with a (commented out) example setting. Oops :) That didn't make it in the patch. But was already written. (Please fix my poor English) THanks, I have applied this patch to CVS now. The only change I made was to rename the config parameter from 'ip_addr' to 'listen_addr', since we're likely to have other IP addrs in the future... I see the ip_addr in libvirtd.conf needs updating. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] how to pass qemu options?
on Thu May 15 2008, Gerd Hoffmann kraxel-AT-redhat.com wrote: Daniel P. Berrange wrote: We explicitly do not support passing arbitrary arguments to QEMU. Supporting and implementing are two different things IMHO. It is pretty clear that *supporting* such a configuration is impossible and that running it on production systems is a really bad idea for the reasons outlined. Nevertheless being able to pass random additional arguments to $emulator is required for any serious development work. I *hate* to having to create a wrapper script each time I need to pass in additional parameters, and I'd *love* to see libvirt being a bit more developer friendly. Making it friendlier to those like me who want to transition existing VMs into a libvirt-managed environment would be nice, too. Eventually I might figure out how to do what I need without those extra options, but for now, I just need the system to work. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Bind to ip_addr support.
On Thu, May 15, 2008 at 02:59:52PM +0200, Stefan de Konink wrote: On Wed, 14 May 2008, Daniel P. Berrange wrote: On Sat, May 10, 2008 at 06:43:11PM +0200, Stefan de Konink wrote: On Sat, 10 May 2008, Daniel P. Berrange wrote: The code all looks good to me, but can you also provide an update for the default configuration file in qemud/libvirtd.conf with a (commented out) example setting. Oops :) That didn't make it in the patch. But was already written. (Please fix my poor English) THanks, I have applied this patch to CVS now. The only change I made was to rename the config parameter from 'ip_addr' to 'listen_addr', since we're likely to have other IP addrs in the future... I see the ip_addr in libvirtd.conf needs updating. Opps, yes, done that now Dan -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] Domain XML format using defined storage volume + RFC
On Thu, 15 May 2008, Stefan de Konink wrote: Now I wonder, is it possible to have here somethinglike storage://netapp/lun-0? [snip] From the standpoint: we make it easy for the user I would prefer not to provide a Linux specific path. http://libvirt.org/formatdomain.html#elementsDisks I propose an extension to the current source tag specifying where a disk should come from. In my humble opinion something that is already available inside libvirt should be reused. Therefore: source If the disk type is file, then the file attribute specifies the fully-qualified path to the file holding the disk. If the disk type is block, then the dev attribute specifies the path to the host device to serve as the disk. If the disk type is pool, then the pool attribute and the volume attibute specify what volume should be used for this disk. I'm currently playing with xml.c to get it supported. One thing that would be interesting is a 'start' parameter, so when the pool is defined but not yet started it should start. Any comments to the idea? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Domain XML format using defined storage volume + RFC
On Thu, May 15, 2008 at 03:20:06PM +0200, Stefan de Konink wrote: On Thu, 15 May 2008, Stefan de Konink wrote: Now I wonder, is it possible to have here somethinglike storage://netapp/lun-0? [snip] From the standpoint: we make it easy for the user I would prefer not to provide a Linux specific path. http://libvirt.org/formatdomain.html#elementsDisks I propose an extension to the current source tag specifying where a disk should come from. In my humble opinion something that is already available inside libvirt should be reused. Therefore: source If the disk type is file, then the file attribute specifies the fully-qualified path to the file holding the disk. If the disk type is block, then the dev attribute specifies the path to the host device to serve as the disk. If the disk type is pool, then the pool attribute and the volume attibute specify what volume should be used for this disk. I'd support a syntax like this: disk type=pool source pool=myfiler vol=lun-4/ target dev=xvda/ /disk Since this mirrors the concept we use for mapping virtual networks into the domain interface element. I'm currently playing with xml.c to get it supported. One thing that would be interesting is a 'start' parameter, so when the pool is defined but not yet started it should start. Any comments to the idea? No, lifecycle changes in one object (the domain) should not effect lifecycle changes on another (the storage). We already provide ability for pools to be auto-started at time libvirtd starts. Pools will typically be serving more than one guest anyway, so starting a pool upon starting a domain is a niche use case. Management tools can provide policy such as auto-starting pools in this scenario if desired. Regards, Daniel. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] libvirtd cpu usage
On Thu, May 15, 2008 at 11:47:44AM +0200, Thomas Mueller wrote:
hi there
i'm playing on debian lenny with kvm-66/libvirt-0.4.2 .
if i run top, i see libvirtd is top cpu consumer. if i connect with
strace to libvirtd, i see a thousand times this message:
poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLERR|POLLHUP},
{fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=8, events=POLLIN}, {fd=13,
events=POLLIN|POLLERR|POLLHUP, revents=POLLHUP}, {fd=15,
events=POLLIN|POLLERR|POLLHUP, revents=POLLHUP}, {fd=17,
events=POLLIN|POLLERR|POLLHUP}, {fd=19, events=POLLIN|POLLERR|POLLHUP}],
8, -1) = 2
So this is saying 2 of file descriptors have hit 'end of file' condition
and for some bizarre reason libvirt is not cleaning them up. What do you
do to cause trigger the high CPU usage ? Does it occurr the moment you
start libvirtd ? Or only when you start a VM ? Or only when you shutdown
a VM ? Or something else altogether...
The output of 'lsof -p' on the libvirtd process might be helpful. You
might also try running with --verbose and LIBVIRT_DEBUG=1 envirnoment
variable set and capturing the output
Regards,
Dan.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- 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: [libvirt] Domain XML format using defined storage volume + RFC
On Thu, 15 May 2008, Daniel P. Berrange wrote: On Thu, May 15, 2008 at 03:20:06PM +0200, Stefan de Konink wrote: On Thu, 15 May 2008, Stefan de Konink wrote: Now I wonder, is it possible to have here somethinglike storage://netapp/lun-0? [snip] From the standpoint: we make it easy for the user I would prefer not to provide a Linux specific path. http://libvirt.org/formatdomain.html#elementsDisks I propose an extension to the current source tag specifying where a disk should come from. In my humble opinion something that is already available inside libvirt should be reused. Therefore: source If the disk type is file, then the file attribute specifies the fully-qualified path to the file holding the disk. If the disk type is block, then the dev attribute specifies the path to the host device to serve as the disk. If the disk type is pool, then the pool attribute and the volume attibute specify what volume should be used for this disk. I'd support a syntax like this: disk type=pool source pool=myfiler vol=lun-4/ target dev=xvda/ /disk I understand your point :) Nevermind, I think you are right, making a CD that is backed by a LUN is non-sence anyway. I'm currently playing with xml.c to get it supported. One thing that would be interesting is a 'start' parameter, so when the pool is defined but not yet started it should start. Any comments to the idea? No, lifecycle changes in one object (the domain) should not effect lifecycle changes on another (the storage). We already provide ability for pools to be auto-started at time libvirtd starts. Pools will typically be serving more than one guest anyway, so starting a pool upon starting a domain is a niche use case. Management tools can provide policy such as auto-starting pools in this scenario if desired. Expect a RFC patch soon ;) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Domain XML format using defined storage volume + RFC
On Thu, May 15, 2008 at 03:37:14PM +0200, Stefan de Konink wrote: On Thu, 15 May 2008, Daniel P. Berrange wrote: On Thu, May 15, 2008 at 03:20:06PM +0200, Stefan de Konink wrote: On Thu, 15 May 2008, Stefan de Konink wrote: Now I wonder, is it possible to have here somethinglike storage://netapp/lun-0? [snip] From the standpoint: we make it easy for the user I would prefer not to provide a Linux specific path. http://libvirt.org/formatdomain.html#elementsDisks I propose an extension to the current source tag specifying where a disk should come from. In my humble opinion something that is already available inside libvirt should be reused. Therefore: source If the disk type is file, then the file attribute specifies the fully-qualified path to the file holding the disk. If the disk type is block, then the dev attribute specifies the path to the host device to serve as the disk. If the disk type is pool, then the pool attribute and the volume attibute specify what volume should be used for this disk. I'd support a syntax like this: disk type=pool source pool=myfiler vol=lun-4/ target dev=xvda/ /disk I understand your point :) Nevermind, I think you are right, making a CD that is backed by a LUN is non-sence anyway. A storage pool is not just SCSI. It can be a directory of ISO files, an NFS mount of ISO files, local device nodes (including CDROM). So it is perfectly possible that we'll use a pool to back a virtual CD device. This is dealt with by simply specifying the 'device='cdrom' attribute. This shouldn't impact the implementation since the choice of backend storage is completely independant of the type of disk device emulated in the guest. For a CD you'd just use: disk type=pool device=cdrom source pool=myfiler vol=lun-4/ target dev=hdc/ /disk Regards, Daniel. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] [ANNOUNCE] virt-df 2.1.0 - a 'df' tool for virtual guests
On Tue, May 13, 2008 at 05:42:38PM +0100, Richard W.M. Jones wrote: I'm pleased to announce the most recent release of virt-df (2.1.0). Virt-df is 'df' for virtual guests. Run the program on the host / dom0 to display disk space used and available on all partitions on all guests. You don't need to run any sort of program/agent within the guest. Home page: http://et.redhat.com/~rjones/virt-df/ Source/binaries: http://et.redhat.com/~rjones/virt-df/files/ Developer repository: http://hg.et.redhat.com/virt/applications/virt-df--devel This version supports most common filesystems and partitioning schemes, including: - Linux ext2/3 - DOS FAT32 - Windows NTFS - Linux LVM2 (volume groups and logical volumes) - Primary and extended disk partitions - Linux swap - Linux suspend partition I'm assuming this only works for raw file block devices ? Are you planning to support the funky QCow / VMDK formats too ? The other thing that could be annoying is that Fedora 9 support for encrypting all volumes - might need to prompt for a decryption key for that. Included also is an experimental command line tool called 'diskzip' which intelligently compresses disk images by leaving out the bits which aren't actually used in the filesystems / partitions / volume groups contained within. That's pretty neat. Which file systems does that work for ? VMWare have a funky guest tool which tries to let you get to a similar point. It works by basically openning a file inside the guest VM and filling it with zeros until the entire disk is full. THeir backend can then detect and discard all the sectors with zeros. Understanding the filesystem metdata is a much nicer way todo this :-) Regards, Daniel -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] how to pass qemu options?
On Thu, May 15, 2008 at 02:34:20PM +0200, Gerd Hoffmann wrote: Daniel P. Berrange wrote: We explicitly do not support passing arbitrary arguments to QEMU. Supporting and implementing are two different things IMHO. It is pretty clear that *supporting* such a configuration is impossible and that running it on production systems is a really bad idea for the reasons outlined. We can say that all we like, but the reality is 'we ship it, we support it'. Users are going to file bugs if things break are going to want them fixed In RHEL we ship Xen with SDL support for framebuffer, even though our tools only 'support' VNC. We still have multiple bugs file against SDL and we have to fix them. Users don't distinguish, they just use all the features you provide them and expect them all to work. Nevertheless being able to pass random additional arguments to $emulator is required for any serious development work. I *hate* to having to create a wrapper script each time I need to pass in additional parameters, and I'd *love* to see libvirt being a bit more developer friendly. Historically we've not had very complete coverage of QEMU args, but we've been adding alot of new functionality recently so the need for extra args is reducing all the time. We recently added serial, parallel, sound and drive support. USB is the next on the list at which point we basically have coverage of all the important options we should reasonably expect. Creating wrapper scripts for experimentation is not that difficult. Regards, Daniel. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] [BUG] second libvirtd breaks the first
On Thu, May 15, 2008 at 01:47:05PM +0200, Stefan de Konink wrote: By accident I ran a second instance of libvirtd. This second instance did not terminate the first instance nor did it detect there was already a running instance. By killing the second instance the first did not work anymore. I imagine that the second instance is unlink()ing the UNIX domain socket of the first instance. It should really check the PID file and refuse to start up if another instance is already running. Next to this, why does libvirtd terminate its iSCSI connections upon stop? I saw it cannot gracefully 'reuse' existing sessions, but it is absurd that restarting libvirtd would kill all running VMs on a host using iSCSI, or not able to get a storage pool up because it is already logged in to it. We ought to be able to make it reuse an existing session if that session matches one of the defined libvirt pools. We shouuld also make the auto shutdown behaviour configurable per storage pool. Currently we only configure auto-startup. Regards, Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] Domain XML format using defined storage volume + RFC
On Thu, May 15, 2008 at 03:58:33PM +0200, Stefan de Konink wrote: On Thu, 15 May 2008, Daniel P. Berrange wrote: A storage pool is not just SCSI. It can be a directory of ISO files, an NFS mount of ISO files, local device nodes (including CDROM). So it is perfectly possible that we'll use a pool to back a virtual CD device. This is dealt with by simply specifying the 'device='cdrom' attribute. This shouldn't impact the implementation since the choice of backend storage is completely independant of the type of disk device emulated in the guest. For a CD you'd just use: disk type=pool device=cdrom source pool=myfiler vol=lun-4/ target dev=hdc/ /disk Nevermind, my reading skills are almost as bad as my coding skills. I mixed up the type and device attributed. But implemented it directly in the type attribute and realised the true meaning of your comment too late. The code I produced is still *untested*. It does compile, but I still did not define any normal domain with libvirt, and if this works I hope my problems are all over. I generally like code dealing with XML parsing to have test cases defined in the tests/qemu*test.c files... I don't know if you picked up the message about open-iscsi. The libopen-iscsi idea was accepted. So technically we can use their functions directly never having migrate from one sysfs to another, because 'they' fix it. So if the user has a recent version of open-iscsi, they will automatically have the right lookup algorithm. It might be interesting to 'natively' do the scanning too, without invoking the binary. If you want to do this, I'm happy to put all the functions we need in one binary and update their Makefile. The iscsi dependancy should then check for a recent open-iscsi version. Now is this a good idea? For Linux probably... but I hope you can still make friends with Solaris guys. I hope they can provide some native method too :) The code is such that we can trivially have multiple backend drivers for iSCSI if that becomes neccessary. So I've no problem with us providing one that's based on openiscsi, even if its not (yet) supported on Solaris, because we can easily drop in an alternate Solaris iSCSI driver as needed. Sign-off-by: Stefan de Konink [EMAIL PROTECTED] ps. please update the AUTHORS with the above e-mail adress. I try to migrate all my email from 'personal' to 'work'. I've changed that. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] how to pass qemu options?
on Thu May 15 2008, Daniel P. Berrange berrange-AT-redhat.com wrote: On Thu, May 15, 2008 at 02:34:20PM +0200, Gerd Hoffmann wrote: Daniel P. Berrange wrote: We explicitly do not support passing arbitrary arguments to QEMU. Supporting and implementing are two different things IMHO. It is pretty clear that *supporting* such a configuration is impossible and that running it on production systems is a really bad idea for the reasons outlined. We can say that all we like, but the reality is 'we ship it, we support it'. Users are going to file bugs if things break are going to want them fixed In RHEL we ship Xen with SDL support for framebuffer, even though our tools only 'support' VNC. We still have multiple bugs file against SDL and we have to fix them. Users don't distinguish, they just use all the features you provide them and expect them all to work. Nevertheless being able to pass random additional arguments to $emulator is required for any serious development work. I *hate* to having to create a wrapper script each time I need to pass in additional parameters, and I'd *love* to see libvirt being a bit more developer friendly. Historically we've not had very complete coverage of QEMU args, but we've been adding alot of new functionality recently so the need for extra args is reducing all the time. We recently added serial, parallel, sound and drive support. USB is the next on the list at which point we basically have coverage of all the important options we should reasonably expect. Creating wrapper scripts for experimentation is not that difficult. I'm using the TCP redirection option -redir ... to do seamless RDP securely. Unimportant? -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] avoid using STREQLEN with a literal; use STRPREFIX instead
The goal of this change is to remove the error-prone duplication
between literal strings and corresponding literal length.
This was almost 100% mechanical:
# Do this:
# -STRNEQLEN((const char *)target, hd, 2)
# +!STRPREFIX((const char *)target, hd)
git grep -l '\STRNEQLEN *('| f | xargs \
perl -pi -e 's/\bSTRNEQLEN( *\(.*?, *.*?), \d+\)/!STRPREFIX$1)/'
# Do this:
# -} else if (STREQLEN(key, vnclisten=, 10)) {
# +} else if (STRPREFIX(key, vnclisten=)) {
git grep -l '\STREQLEN *('| f | xargs \
perl -pi -e 's/\bSTREQLEN( *\(.*?, *.*?), \d+\)/STRPREFIX$1)/'
# Two missed by the above
# src/qemu_conf.c: if (STREQLEN(vnet, (const char*)ifname, 4)) {
# src/xm_internal.c: if (STREQLEN(ent-d_name, QEMU_IF_SCRIPT,
strlen(QEMU_IF_SCRIPT)))
# Since there are 3 more like the latter, do them automatically:
git grep -l '\STREQLEN *('| f | xargs \
perl -pi -e 's/\bSTREQLEN( *\(.*?, *(\w+)), strlen\(\2\)\)/STRPREFIX$1)/'
I manually reversed the two args with the vnet use in qemu_conf.c,
so that the perl code would transform that one, too.
From b043c2d627a7133d75664c01a3fe813b760502e9 Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Thu, 15 May 2008 15:58:23 +0200
Subject: [PATCH] avoid using STREQLEN with a literal; use STRPREFIX instead
Likewise for STRNEQLEN - !STRPREFIX.
* src/nodeinfo.c (linuxNodeInfoCPUPopulate):
* src/qemu_conf.c (qemudNetworkIfaceConnect):
(qemudParseInterfaceXML):
* src/qemu_driver.c (qemudDomainBlockStats):
* src/remote_internal.c (call):
* src/stats_linux.c (xenLinuxDomainDeviceID):
* src/xend_internal.c (xend_parse_sexp_desc):
(xend_get, sexpr_to_xend_topology):
* src/xm_internal.c (xenXMConfigCacheRefresh)
(xenXMDomainFormatXML):
---
src/nodeinfo.c|6 +++---
src/qemu_conf.c |6 +++---
src/qemu_driver.c | 14 +++---
src/remote_internal.c |2 +-
src/stats_linux.c |8
src/xend_internal.c |6 +++---
src/xm_internal.c | 14 +++---
7 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/src/nodeinfo.c b/src/nodeinfo.c
index e227c69..b2ef6ee 100644
--- a/src/nodeinfo.c
+++ b/src/nodeinfo.c
@@ -57,7 +57,7 @@ int linuxNodeInfoCPUPopulate(virConnectPtr conn, FILE
*cpuinfo, virNodeInfoPtr n
/* XXX hyperthreads */
while (fgets(line, sizeof(line), cpuinfo) != NULL) {
char *buf = line;
-if (STREQLEN(buf, processor, 9)) { /* aka a single logical CPU */
+if (STRPREFIX(buf, processor)) { /* aka a single logical CPU */
buf += 9;
while (*buf c_isspace(*buf))
buf++;
@@ -68,7 +68,7 @@ int linuxNodeInfoCPUPopulate(virConnectPtr conn, FILE
*cpuinfo, virNodeInfoPtr n
return -1;
}
nodeinfo-cpus++;
-} else if (STREQLEN(buf, cpu MHz, 7)) {
+} else if (STRPREFIX(buf, cpu MHz)) {
char *p;
unsigned int ui;
buf += 9;
@@ -84,7 +84,7 @@ int linuxNodeInfoCPUPopulate(virConnectPtr conn, FILE
*cpuinfo, virNodeInfoPtr n
/* Accept trailing fractional part. */
(*p == '\0' || *p == '.' || c_isspace(*p)))
nodeinfo-mhz = ui;
-} else if (STREQLEN(buf, cpu cores, 9)) { /* aka cores */
+} else if (STRPREFIX(buf, cpu cores)) { /* aka cores */
char *p;
unsigned int id;
buf += 9;
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index f31b33a..8ae0960 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -816,7 +816,7 @@ static int qemudParseInterfaceXML(virConnectPtr conn,
(net-type == QEMUD_NET_BRIDGE))
xmlStrEqual(cur-name, BAD_CAST target)) {
ifname = xmlGetProp(cur, BAD_CAST dev);
-if (STREQLEN(vnet, (const char*)ifname, 4)) {
+if (STRPREFIX((const char*)ifname, vnet)) {
/* An auto-generated target name, blank it out */
xmlFree(ifname);
ifname = NULL;
@@ -2130,7 +2130,7 @@ qemudNetworkIfaceConnect(virConnectPtr conn,
}
brname = network-bridge;
if (net-dst.network.ifname[0] == '\0' ||
-STREQLEN(net-dst.network.ifname, vnet, 4) ||
+STRPREFIX(net-dst.network.ifname, vnet) ||
strchr(net-dst.network.ifname, '%')) {
strcpy(net-dst.network.ifname, vnet%d);
}
@@ -2138,7 +2138,7 @@ qemudNetworkIfaceConnect(virConnectPtr conn,
} else if (net-type == QEMUD_NET_BRIDGE) {
brname = net-dst.bridge.brname;
if (net-dst.bridge.ifname[0] == '\0' ||
-STREQLEN(net-dst.bridge.ifname, vnet, 4) ||
+STRPREFIX(net-dst.bridge.ifname, vnet) ||
strchr(net-dst.bridge.ifname, '%')) {
strcpy(net-dst.bridge.ifname, vnet%d);
}
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 7d52798..6ba6179
Re: [libvirt] [PATCH] avoid using STREQLEN with a literal; use STRPREFIX instead
Daniel P. Berrange [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 04:13:14PM +0200, Jim Meyering wrote: The goal of this change is to remove the error-prone duplication between literal strings and corresponding literal length. This was almost 100% mechanical: I manually reversed the two args with the vnet use in qemu_conf.c, so that the perl code would transform that one, too. Yes, this looks good to me. I've scanned the changes and all appear correct. Thanks for the quick review. Committed. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] listen_tls not enabling libvirtd to listen for tls
On Tue, May 13, 2008 at 05:04:43PM +0300, Kenneth Nagin wrote: Kenneth Nagin wrote: libvirtd is not listening for TLS connection by default. Setting 'listen_tls = 1' in /etc/libvirt/libvirtd.conf does not help either. However, starting 'libvirtd --listen' does work. I'm running Fedora 8. I prefer to use the configuration file since it is automatically started when the system reboots. Does anyone know how to configure libvirtd to listen for tls? Yes. As you found out, there are 2 things you need to do, the first of which is to instruct libvirtd to listen, and the second of which is to make it listen for TLS. You can accomplish the first on Fedora by editing /etc/sysconfig/libvirtd and uncommenting the LIBVIRTD_ARGS=--listen line. You can accomplish the second by edit /etc/libvirt/libvirtd.conf by uncommenting the listen_tls = 1 line. Then service libvirtd restart, and you should be good to go(this will also preserve the configuration across reboots). Chris Lalancette Thanks for the quick response. That solved the problem. I suggest updating the web document on remote support. Even better, send us a patch with your suggested documentation udate :-) The web site is a checkout of the libvirt CVS docs subdirectory. Do a CVS checkout, edit remote.html.in and send us the diff, it's not hard and may help others ! thanks in advance, 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: [libvirt] listen_tls not enabling libvirtd to listen for tls
On Thu, May 15, 2008 at 10:21:46AM -0400, Daniel Veillard wrote: On Tue, May 13, 2008 at 05:04:43PM +0300, Kenneth Nagin wrote: Kenneth Nagin wrote: libvirtd is not listening for TLS connection by default. Setting 'listen_tls = 1' in /etc/libvirt/libvirtd.conf does not help either. However, starting 'libvirtd --listen' does work. I'm running Fedora 8. I prefer to use the configuration file since it is automatically started when the system reboots. Does anyone know how to configure libvirtd to listen for tls? Yes. As you found out, there are 2 things you need to do, the first of which is to instruct libvirtd to listen, and the second of which is to make it listen for TLS. You can accomplish the first on Fedora by editing /etc/sysconfig/libvirtd and uncommenting the LIBVIRTD_ARGS=--listen line. You can accomplish the second by edit /etc/libvirt/libvirtd.conf by uncommenting the listen_tls = 1 line. Then service libvirtd restart, and you should be good to go(this will also preserve the configuration across reboots). Chris Lalancette Thanks for the quick response. That solved the problem. I suggest updating the web document on remote support. Even better, send us a patch with your suggested documentation udate :-) The web site is a checkout of the libvirt CVS docs subdirectory. Do a CVS checkout, edit remote.html.in and send us the diff, it's not hard and may help others ! Since 0.4.1 the default configuration file has comments right next to the 'listen_tls' and 'listen_tcp' options explicitly saying you need to add the --listen flag. Regards, Daniel. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] PATCH: Pass -name argument to QEMU
On Tue, May 13, 2008 at 12:21:02AM +0100, Daniel P. Berrange wrote: This patch makes libvirt pass the -name argumet to QEMU it if it supported by the QEMU binary in question. THis allows QEMU to set the VNC title and allows Xenner to set the Xen guest name in xenstore. Fine by me, +1 @@ -2348,6 +2350,7 @@ len = 1 + /* qemu */ 2 + /* machine type */ disableKQEMU + /* Disable kqemu */ +(vm-qemuCmdFlags QEMUD_CMD_FLAG_NAME ? 2 : 0) + /* -name XXX */ 2 * vm-def-ndisks + /* disks*/ (vm-def-nnets 0 ? (4 * vm-def-nnets) : 2) + /* networks */ 1 + /* usb */ @@ -2394,6 +2397,12 @@ I just start to find that arg length computation a bit long and messy. As we add the args maybe it's time to do that a bit more dynamically, no ? 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: [libvirt] PATCH: Pass -name argument to QEMU
On Thu, May 15, 2008 at 10:36:18AM -0400, Daniel Veillard wrote: On Tue, May 13, 2008 at 12:21:02AM +0100, Daniel P. Berrange wrote: This patch makes libvirt pass the -name argumet to QEMU it if it supported by the QEMU binary in question. THis allows QEMU to set the VNC title and allows Xenner to set the Xen guest name in xenstore. Fine by me, +1 @@ -2348,6 +2350,7 @@ len = 1 + /* qemu */ 2 + /* machine type */ disableKQEMU + /* Disable kqemu */ +(vm-qemuCmdFlags QEMUD_CMD_FLAG_NAME ? 2 : 0) + /* -name XXX */ 2 * vm-def-ndisks + /* disks*/ (vm-def-nnets 0 ? (4 * vm-def-nnets) : 2) + /* networks */ 1 + /* usb */ @@ -2394,6 +2397,12 @@ I just start to find that arg length computation a bit long and messy. As we add the args maybe it's time to do that a bit more dynamically, no ? Yes it is getting a little messy. Its probably worth dynamically expanding the array as we add each arg. If we define a simple macro to handle the realloc of argv, and the strdup of the actual arg in one go, it should make the code fairly clear. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] [RFC] Comfortable lookup functions interface/block stats
On Mon, May 12, 2008 at 01:35:33AM +0200, Stefan de Konink wrote: Hi, Wouldn't it be much nicer for Joe Programmer if the API facilitated the functions: char ** virDomainInterfacePaths(virDomainPtr dom); char ** virDomainBlockPaths(virDomainPtr dom); I really don't get why XML parsing should be done for something that is almost too trivial to export. Any reasons why not to do implement this? Hum, how would you use the paths out of their context ? I doubt Joe Programmer would have much use for a list of paths without knowing what they are used for. But maybe I didn't understood your APIs suggestions... 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: [libvirt] PATCH: Allow Xen bus type for input devices in QEMU driver
On Tue, May 13, 2008 at 12:25:26AM +0100, Daniel P. Berrange wrote: The Xenner virtual machine supportes a bus type of 'xen' for input devices, corresponding to the paravirtualized mouse device. QEMU currently rejects any bus type which isn't ps2 or usb. This patch makes it allow 'xen' as a valid bus type for Xenner guests. Fine by me, +1 Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirtd cpu usage
hi daniel
i'm playing on debian lenny with kvm-66/libvirt-0.4.2 .
if i run top, i see libvirtd is top cpu consumer. if i connect with
strace to libvirtd, i see a thousand times this message:
poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLERR|POLLHUP},
{fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=8, events=POLLIN}, {fd=13,
events=POLLIN|POLLERR|POLLHUP, revents=POLLHUP}, {fd=15,
events=POLLIN|POLLERR|POLLHUP, revents=POLLHUP}, {fd=17,
events=POLLIN|POLLERR|POLLHUP}, {fd=19, events=POLLIN|POLLERR|POLLHUP}],
8, -1) = 2
So this is saying 2 of file descriptors have hit 'end of file' condition
and for some bizarre reason libvirt is not cleaning them up. What do you
do to cause trigger the high CPU usage ? Does it occurr the moment you
start libvirtd ? Or only when you start a VM ? Or only when you shutdown
a VM ? Or something else altogether...
The output of 'lsof -p' on the libvirtd process might be helpful. You
might also try running with --verbose and LIBVIRT_DEBUG=1 envirnoment
variable set and capturing the output
hmm.. ok, i can't reproduce it anymore. :/ but i found a second libvirtd
process in defunct state. maybe this was the cause for this bizzare
reason libvirt not cleaning them up.
after rebooting i tested again and libvirtd was not consuming all of the
cpu...
sorry for disturbing.
- Thomas
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Comfortable lookup functions interface/block stats
On Thu, 15 May 2008, Daniel Veillard wrote: On Mon, May 12, 2008 at 01:35:33AM +0200, Stefan de Konink wrote: Hi, Wouldn't it be much nicer for Joe Programmer if the API facilitated the functions: char ** virDomainInterfacePaths(virDomainPtr dom); char ** virDomainBlockPaths(virDomainPtr dom); I really don't get why XML parsing should be done for something that is almost too trivial to export. Any reasons why not to do implement this? Hum, how would you use the paths out of their context ? I doubt Joe Programmer would have much use for a list of paths without knowing what they are used for. But maybe I didn't understood your APIs suggestions... If Joe Programmer needs to parse the XML file to fetch 'hda', 'hdb' why not get them directly from the api? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirtd cpu usage
On Thu, May 15, 2008 at 05:03:37PM +0200, Thomas Mueller wrote:
hi daniel
i'm playing on debian lenny with kvm-66/libvirt-0.4.2 .
if i run top, i see libvirtd is top cpu consumer. if i connect with
strace to libvirtd, i see a thousand times this message:
poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLERR|POLLHUP},
{fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=8, events=POLLIN}, {fd=13,
events=POLLIN|POLLERR|POLLHUP, revents=POLLHUP}, {fd=15,
events=POLLIN|POLLERR|POLLHUP, revents=POLLHUP}, {fd=17,
events=POLLIN|POLLERR|POLLHUP}, {fd=19, events=POLLIN|POLLERR|POLLHUP}],
8, -1) = 2
So this is saying 2 of file descriptors have hit 'end of file' condition
and for some bizarre reason libvirt is not cleaning them up. What do you
do to cause trigger the high CPU usage ? Does it occurr the moment you
start libvirtd ? Or only when you start a VM ? Or only when you shutdown
a VM ? Or something else altogether...
The output of 'lsof -p' on the libvirtd process might be helpful. You
might also try running with --verbose and LIBVIRT_DEBUG=1 envirnoment
variable set and capturing the output
hmm.. ok, i can't reproduce it anymore. :/ but i found a second libvirtd
process in defunct state. maybe this was the cause for this bizzare
reason libvirt not cleaning them up.
after rebooting i tested again and libvirtd was not consuming all of the
cpu...
Well if it hits you again let us know, because it sounds like there's a
wierd edge case bug hiding in there somewhere...
Dan.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- 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: [libvirt] PATCH: Support bootloaders in QEMU driver
On Tue, May 13, 2008 at 12:31:36AM +0100, Daniel P. Berrange wrote:
The QEMU driver supports booting Xen guests via the Xenner hypervisor. For
such paravirtualized guests there is no regular BIOS, so the bootloader has
to be run on the host. Xenner defaults to pygrub, but since libvirt has a
generic syntax for bootloaders, we should use it. So this patch adds support
for the bootloader syntax in the QEMU drive, and passes this to Xenner via
the -bootloader arg.
The patch is overly large, because when we have a bootloader we need to skip
the kernel/initrd/cmdline/boot elements thus caused alot of intrusive code
re-indentation .
[...]
+/* Extract bootloader */
+obj = xmlXPathEval(BAD_CAST string(/domain/bootloader), ctxt);
+if ((obj != NULL) (obj-type == XPATH_STRING)
+(obj-stringval != NULL) (obj-stringval[0] != 0)) {
+strncpy(def-os.bootloader, (const char*)obj-stringval,
sizeof(def-os.bootloader));
+NUL_TERMINATE(def-os.bootloader);
+xmlXPathFreeObject(obj);
+
+/* Set a default OS type, since type is optional with bootloader */
+strcpy(def-os.type, xen);
+}
+
/* Extract OS type info */
obj = xmlXPathEval(BAD_CAST string(/domain/os/type[1]), ctxt);
if ((obj == NULL) || (obj-type != XPATH_STRING) ||
(obj-stringval == NULL) || (obj-stringval[0] == 0)) {
+if (!def-os.type[0]) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_OS_TYPE,
+ %s, _(no OS type));
+goto error;
+}
+} else {
+strcpy(def-os.type, (const char *)obj-stringval);
+xmlXPathFreeObject(obj);
+}
Argh, that part of the code has not been cleaned up, using virXPathString
there would make this way easier to read and check.
The big indentation block change inflated the patch size a bit. it still
look fine.
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: [libvirt] [RFC] Comfortable lookup functions interface/block stats
On Thu, May 15, 2008 at 05:04:38PM +0200, Stefan de Konink wrote: On Thu, 15 May 2008, Daniel Veillard wrote: On Mon, May 12, 2008 at 01:35:33AM +0200, Stefan de Konink wrote: Hi, Wouldn't it be much nicer for Joe Programmer if the API facilitated the functions: char ** virDomainInterfacePaths(virDomainPtr dom); char ** virDomainBlockPaths(virDomainPtr dom); I really don't get why XML parsing should be done for something that is almost too trivial to export. Any reasons why not to do implement this? Hum, how would you use the paths out of their context ? I doubt Joe Programmer would have much use for a list of paths without knowing what they are used for. But maybe I didn't understood your APIs suggestions... If Joe Programmer needs to parse the XML file to fetch 'hda', 'hdb' why not get them directly from the api? Because they might want more information than just 'hda', 'hdb' and we don't want to expose an every increasing set of APIs to get each individual piece of metadata associated with disks. As you can see from the XML there is alot of metadata and we add more surprisingly often. This is why we use the easily extendable XML format for providing all this metdata. As for parsing the XML - if you really only need that one attribute, then don't parse iterate over the Dom. Use an XML lbirary suppporting XPath with an expresion like /domain/devices/disk/target/@dev which will give you all the disk device names in a single go. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] Domain XML format using defined storage volume + RFC
On Thu, 15 May 2008, Stefan de Konink wrote: I almost started crying why it didn't work. But it is fixed, and it works as a charm :) See updated patch! I guess I need to write the 'check' tool and documentation update too? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] start using c-ctype functions
On Thu, May 15, 2008 at 05:56:57PM +0200, Jim Meyering wrote: From db0ed598dfc045f3937a3629a432d2d703449f50 Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Wed, 14 May 2008 23:06:15 +0200 Subject: [PATCH] start using c-ctype functions Up to now, we've been avoiding ctype functions like isspace, isdigit, etc. Now that we have the c-ctype functions, we can start using them to make the code more readable with changes like these: I must have missed the previous discussion of c-ctype functions... What are the c-ctype functions and where do they come from ? I'm guessing from the description, they're variants of ctype functions which are guarenteed to operate in the C/USASCII locale, regardless of LANG setting. Are they from gnulib ? Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] [PATCH] start using c-ctype functions
Daniel P. Berrange [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 05:56:57PM +0200, Jim Meyering wrote: From db0ed598dfc045f3937a3629a432d2d703449f50 Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Wed, 14 May 2008 23:06:15 +0200 Subject: [PATCH] start using c-ctype functions Up to now, we've been avoiding ctype functions like isspace, isdigit, etc. Now that we have the c-ctype functions, we can start using them to make the code more readable with changes like these: I must have missed the previous discussion of c-ctype functions... The first patch was discussed here: http://thread.gmane.org/gmane.comp.emulators.libvirt/6353 What are the c-ctype functions and where do they come from ? I'm guessing from the description, they're variants of ctype functions which are guarenteed to operate in the C/USASCII locale, regardless of LANG setting. Are they from gnulib ? That's right. It's the c-ctype module. http://www.gnu.org/software/gnulib/MODULES.html#module=c-ctype -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Pass -name argument to QEMU
On Thu, May 15, 2008 at 10:36:18AM -0400, Daniel Veillard wrote: On Tue, May 13, 2008 at 12:21:02AM +0100, Daniel P. Berrange wrote: This patch makes libvirt pass the -name argumet to QEMU it if it supported by the QEMU binary in question. THis allows QEMU to set the VNC title and allows Xenner to set the Xen guest name in xenstore. Fine by me, +1 Thanks, this is applied now. Dan -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] PATCH: Allow Xen bus type for input devices in QEMU driver
On Thu, May 15, 2008 at 11:02:20AM -0400, Daniel Veillard wrote: On Tue, May 13, 2008 at 12:25:26AM +0100, Daniel P. Berrange wrote: The Xenner virtual machine supportes a bus type of 'xen' for input devices, corresponding to the paravirtualized mouse device. QEMU currently rejects any bus type which isn't ps2 or usb. This patch makes it allow 'xen' as a valid bus type for Xenner guests. Fine by me, +1 This is applied, with the changes Jim suggested too. Dan -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] PATCH: Allow xen bus type for disks in QEMU driver
On Thu, May 15, 2008 at 11:04:18AM -0400, Daniel Veillard wrote: On Tue, May 13, 2008 at 12:27:46AM +0100, Daniel P. Berrange wrote: With the recent work to support -drive arg, the QEMU driver now supports many types of bus for disks attached to VMs - ide, scsi, virtio. This patches adds another type 'xen' for the Xen blkfront driver. Fine by me too, +1 Applied, with the changes Jim suggested Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] PATCH: Support bootloaders in QEMU driver
On Thu, May 15, 2008 at 11:09:13AM -0400, Daniel Veillard wrote:
On Tue, May 13, 2008 at 12:31:36AM +0100, Daniel P. Berrange wrote:
The QEMU driver supports booting Xen guests via the Xenner hypervisor. For
such paravirtualized guests there is no regular BIOS, so the bootloader has
to be run on the host. Xenner defaults to pygrub, but since libvirt has a
generic syntax for bootloaders, we should use it. So this patch adds support
for the bootloader syntax in the QEMU drive, and passes this to Xenner via
the -bootloader arg.
The patch is overly large, because when we have a bootloader we need to skip
the kernel/initrd/cmdline/boot elements thus caused alot of intrusive code
re-indentation .
[...]
/* Extract OS type info */
obj = xmlXPathEval(BAD_CAST string(/domain/os/type[1]), ctxt);
if ((obj == NULL) || (obj-type != XPATH_STRING) ||
(obj-stringval == NULL) || (obj-stringval[0] == 0)) {
+if (!def-os.type[0]) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_OS_TYPE,
+ %s, _(no OS type));
+goto error;
+}
+} else {
+strcpy(def-os.type, (const char *)obj-stringval);
+xmlXPathFreeObject(obj);
+}
Argh, that part of the code has not been cleaned up, using virXPathString
there would make this way easier to read and check.
Yes, that's something that needs to be sorted out.
The big indentation block change inflated the patch size a bit. it still
look fine.
This is applied too now.
Regards,
Dan
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- 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: [libvirt] Question about more finer access control permission on libvirt
On Fri, May 09, 2008 at 09:49:19AM +0900, Atsushi SAKAI wrote: I have a question of libvirt with Polkit. Currently, the libvirt w/ Polkit has 2 access control permissions. (Read Only and Read Write) Have you planned to expand the access control more finer? In my use case, Policy should define by domain, operation, operator. Of course, operator is already considered on current libvirt w/ Polkit. So at this point, it needs to add domain and operation policy. The use case is for many(about 100 or more) domain operation. I just want to know how to minimize granting access control permission of each user on libvirt in future. PolicyKit at this time is only used to authenticate local access from applications running in the host's desktop session. While it allows you to make up many fine grained permissions, it doesn't let you dynamicaly associate the permissions with individual objects. eg there is a policykit check to determine whether a user is allowed to mount removable disks - that applies to all removal disks - you can say disk A, but not disk B. While we could add lots more privileges that just read-write and read-only this would only get us part way to where we really need to be. The ideal goal is that we can have fine grained privileges applied to individual virtual machines, storage pools, networks, etc. The only framework that really comes close to this level of flexibility is SELinux, so one of the long term TODO items is to investigate whether we can integrate with SELinux for fine grained access control. As an example DBus uses SELinux to control who can access services on the system bus, and what actisons they can perform. Another example is SEPostgresql which uses SELinux to control accesss to individual tuples colums in the database. So it is clearly able to provide the flexibility we need and scales to huge performance critical applications such as databases. This doesn't make it a quick or easy task to use in libvirt though. It'll involve alot of thought, design development. In the mean time, it is possible that PolicyKit might actually gain the ability to apply authorizaation to individual objects, and also gain ability to use SELinux as its underlying policy engine. So we have to watch what happens there too. There's not really any firm timeline for any of this work, but its stuff we definitely want to get into libvirt Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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
[libvirt] [PATCH] Extract kvm version from qemu-kvm
The patch below provides a way to check the kvm version by parsing
the output of qemu-kvm, similar to how the qemu version is parsed.
The qemu-kvm binary help info starts with the line:
QEMU PC emulator version major.minor.micro (KVM-ver)
The patch is kind of ugly, with renamed functions and code
movement. The gist of it is:
- Moved the general run-a-command-and-grab-output into its own
function qemudExtractCommandOutput
- Created qemudExtract{Qemu,KVM}VersionInfo which call the above
function and scrape the output
- Use qemudExtractVersion to find the default binaries and call
the *VersionInfo functions
If there is a parsing error, or kvm support isn't found, the new
kvmVersion in the qemud_driver struct is just set to zero. I also
added a call to fill in the qemu and kvm versions on driver init.
The patch also fills in the previously discussed max vcpus piece,
which is dependent on the kvm version.
Any comments appreciated.
Thanks,
Cole
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index b17d0c8..3d45669 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -428,13 +428,16 @@ virCapsPtr qemudCapsInit(void) {
return NULL;
}
-
-static int qemudExtractVersionInfo(const char *qemu, int *version, int *flags)
{
+static int qemudExtractCommandOutput(const char *app, char *buf, size_t size) {
pid_t child;
int newstdout[2];
+struct stat sb;
-*flags = 0;
-*version = 0;
+if (stat(app, sb) 0) {
+qemudLog(QEMUD_ERR, _(Cannot find binary %s: %s), app,
+ strerror(errno));
+return -1;
+}
if (pipe(newstdout) 0) {
return -1;
@@ -458,21 +461,19 @@ static int qemudExtractVersionInfo(const char *qemu, int
*version, int *flags) {
/* Just in case QEMU is translated someday.. */
setenv(LANG, C, 1);
-execl(qemu, qemu, (char*)NULL);
+execl(app, app, (char *) NULL);
cleanup1:
_exit(-1); /* Just in case */
} else { /* Parent */
-char help[8192]; /* Ought to be enough to hold QEMU help screen */
-int got = 0, ret = -1;
-int major, minor, micro;
+int got = 0, ret = -1;
if (close(newstdout[1]) 0)
goto cleanup2;
-while (got (sizeof(help)-1)) {
+while (got size-1) {
int len;
-if ((len = read(newstdout[0], help+got, sizeof(help)-got-1)) = 0)
{
+if ((len = read(newstdout[0], buf+got, size-got-1)) = 0) {
if (!len)
break;
if (errno == EINTR)
@@ -481,30 +482,9 @@ static int qemudExtractVersionInfo(const char *qemu, int
*version, int *flags) {
}
got += len;
}
-help[got] = '\0';
-
-if (sscanf(help, QEMU PC emulator version %d.%d.%d, major,minor,
micro) != 3) {
-goto cleanup2;
-}
-
-*version = (major * 1000 * 1000) + (minor * 1000) + micro;
-if (strstr(help, -no-kqemu))
-*flags |= QEMUD_CMD_FLAG_KQEMU;
-if (strstr(help, -no-reboot))
-*flags |= QEMUD_CMD_FLAG_NO_REBOOT;
-if (strstr(help, -name))
-*flags |= QEMUD_CMD_FLAG_NAME;
-if (strstr(help, -drive))
-*flags |= QEMUD_CMD_FLAG_DRIVE;
-if (strstr(help, boot=on))
-*flags |= QEMUD_CMD_FLAG_DRIVE_BOOT;
-if (*version = 9000)
-*flags |= QEMUD_CMD_FLAG_VNC_COLON;
+buf[got] = '\0';
ret = 0;
-qemudDebug(Version %d %d %d Cooked version: %d, with flags ? %d,
- major, minor, micro, *version, *flags);
-
cleanup2:
if (close(newstdout[0]) 0)
ret = -1;
@@ -515,8 +495,8 @@ static int qemudExtractVersionInfo(const char *qemu, int
*version, int *flags) {
goto rewait;
}
qemudLog(QEMUD_ERR,
- _(Unexpected exit status from qemu %d pid %lu),
- got, (unsigned long)child);
+ _(Unexpected exit status from app %s, exit %d: pid %lu),
+ app, got, (unsigned long)child);
ret = -1;
}
/* Check log unexpected exit status, but don't fail,
@@ -524,38 +504,119 @@ static int qemudExtractVersionInfo(const char *qemu, int
*version, int *flags) {
* actually read a valid version number above */
if (WEXITSTATUS(got) != 1) {
qemudLog(QEMUD_WARN,
- _(Unexpected exit status '%d', qemu probably failed),
- got);
+ _(Unexpected exit status '%d', app '%s' probably
failed),
+ got, app);
}
return ret;
}
}
-int qemudExtractVersion(virConnectPtr conn,
-struct qemud_driver *driver) {
+static int qemudExtractQemuVersionInfo(const char *app, int *version,
+ int *flags) {
+
+char
Re: [libvirt] [ANNOUNCE] virt-df 2.1.0 - a 'df' tool for virtual guests
On Thu, May 15, 2008 at 02:54:53PM +0100, Daniel P. Berrange wrote: This version supports most common filesystems and partitioning schemes, including: - Linux ext2/3 - DOS FAT32 - Windows NTFS - Linux LVM2 (volume groups and logical volumes) - Primary and extended disk partitions - Linux swap - Linux suspend partition I'm assuming this only works for raw file block devices ? Are you planning to support the funky QCow / VMDK formats too ? Yes, interesting point. Since I always use flat files or straight partitions for my guests I admit I hadn't given this much thought :-) However support for these formats is just a matter of decoding enough of the structure to enable the same mappings to be made in the 'virt-df' library, same as for LVM2 or indeed MBR partitions now. I'll take a look at it. IIRC there are several different undocumented variations on the QCow format? The other thing that could be annoying is that Fedora 9 support for encrypting all volumes - might need to prompt for a decryption key for that. Yes -- any encrypted volumes aren't going to work at the moment, and couldn't work unless there was a way to access the passphrase. Included also is an experimental command line tool called 'diskzip' which intelligently compresses disk images by leaving out the bits which aren't actually used in the filesystems / partitions / volume groups contained within. That's pretty neat. Which file systems does that work for ? VMWare have a funky guest tool which tries to let you get to a similar point. It works by basically openning a file inside the guest VM and filling it with zeros until the entire disk is full. THeir backend can then detect and discard all the sectors with zeros. Understanding the filesystem metdata is a much nicer way todo this :-) It works with most of the formats supported by virt-df. For MBR LVM once you've parsed the partition tables / LVM metadata, then the information you need just falls out naturally. For NTFS DOS FAT (you won't believe it but ...) you need to find the allocation bitmaps/tables in both cases in order to calculate blocks used/free for df anyway. For ext2 it's a little bit more tricky because one needs to additionally parse the group block free bitmaps [this bit doesn't work at the moment, but is in principle very simple to add]. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] how to pass qemu options?
On Thu, 15 May 2008, Gerd Hoffmann wrote: Stefan de Konink wrote: Adding features that are enabled with #ifdef HAVE_DEVELOPMENT would be a good thing. No. Compile time options are evil, most of the time. I wanna use the standard fedora libvirt package for my work (except when hacking libvirt itself, obviously). Oh, you can do foo, but you have to recompile with --enable-foo first. is a non-starter. If you are a developer and want to develop something, I think it a great thing to have a developement package or distro. If you want to have the same features as others, you are no more than a user and want something stable. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] how to pass qemu options?
Stefan de Konink wrote: On Thu, 15 May 2008, Gerd Hoffmann wrote: Stefan de Konink wrote: Adding features that are enabled with #ifdef HAVE_DEVELOPMENT would be a good thing. No. Compile time options are evil, most of the time. I wanna use the standard fedora libvirt package for my work (except when hacking libvirt itself, obviously). Oh, you can do foo, but you have to recompile with --enable-foo first. is a non-starter. If you are a developer and want to develop something, I think it a great thing to have a developement package or distro. If you want to have the same features as others, you are no more than a user and want something stable. Rubbish. Just because I'm a developer it doesn't mean I want unstable software. And that users don't need debugging features is wrong too. Think bug reports: Asking some user which reports a bug to flip some config bit to enable debug logging usually works fine. Asking them to rebuild the app to compile in debug logging usually doesn't fly. cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] how to pass qemu options?
On Thu, 15 May 2008, Gerd Hoffmann wrote: If you are a developer and want to develop something, I think it a great thing to have a developement package or distro. If you want to have the same features as others, you are no more than a user and want something stable. Rubbish. Just because I'm a developer it doesn't mean I want unstable software. Daniel doesn't seem to want to go in to a direction that the semantics of XML go away for userland code. That sounds acceptable for me as end user code. If the features you propose are in this package it is basically ignoring the semantics, what is fine probably but not as out of the box behavior. Compile switches or startup switches it is all the same ballpark to me: it is not exposed by default. And that users don't need debugging features is wrong too. Think bug reports: Asking some user which reports a bug to flip some config bit to enable debug logging usually works fine. Asking them to rebuild the app to compile in debug logging usually doesn't fly. What has debugging todo with enabling config parameters? In my humble opinion, what we both want is easy prototyping without hacking in C straight away right? Now I must admit that for the last three hacks resulted in two pretty decent pieces of code, but I was satisfied before with the great dynamic ability of Xen and its 'scripts' directory. Proposed that here, and that was a big no-no. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] PATCH: Add NUMA info to QEMU driver
This patch includes NUMA topology info in the QEMU driver capabilities
XML output. It also implements the free memory driver APIs. This is done
with the LGPL'd numactl library. The configure script probes for it and
only enables this functionality if it is found. The numactl library has
been around for quite a while - RHEL-3 vintage at least
configure.in | 39 ++
libvirt.spec.in |3 ++
src/Makefile.am |2 +
src/qemu_conf.c | 69 ++
src/qemu_driver.c | 65 ++
5 files changed, 178 insertions(+)
Regards,
Daniel
Index: src/qemu_conf.c
===
RCS file: /data/cvs/libvirt/src/qemu_conf.c,v
retrieving revision 1.64
diff -u -p -r1.64 qemu_conf.c
--- src/qemu_conf.c 15 May 2008 20:07:34 - 1.64
+++ src/qemu_conf.c 15 May 2008 21:07:42 -
@@ -42,6 +42,10 @@
#include libxml/xpath.h
#include libxml/uri.h
+#if HAVE_NUMACTL
+#include numa.h
+#endif
+
#include libvirt/virterror.h
#include qemu_conf.h
@@ -49,6 +53,7 @@
#include buf.h
#include conf.h
#include util.h
+#include memory.h
#include verify.h
#define qemudLog(level, msg...) fprintf(stderr, msg)
@@ -389,6 +394,67 @@ qemudCapsInitGuest(virCapsPtr caps,
return 0;
}
+#if HAVE_NUMACTL
+#define MAX_CPUS 4096
+#define MAX_CPUS_MASK_SIZE (sizeof(unsigned long))
+#define MAX_CPUS_MASK_LEN (MAX_CPUS / MAX_CPUS_MASK_SIZE)
+#define MAX_CPUS_MASK_BYTES (MAX_CPUS / 8)
+static int
+qemudCapsInitNUMA(virCapsPtr caps)
+{
+int n, i;
+unsigned long *mask = NULL;
+int ncpus;
+int *cpus = NULL;
+int ret = -1;
+
+fprintf(stderr, Add numa\n);
+
+if (numa_available() 0)
+return 0;
+
+fprintf(stderr, Start\n);
+if (VIR_ALLOC_N(mask, MAX_CPUS_MASK_LEN) 0)
+goto cleanup;
+
+for (n = 0 ; n = numa_max_node() ; n++) {
+fprintf(stderr, Do node %d\n, n);
+
+if (numa_node_to_cpus(n, mask, MAX_CPUS_MASK_BYTES) 0)
+goto cleanup;
+
+for (ncpus = 0, i = 0 ; i MAX_CPUS ; i++)
+if ((mask[(i / MAX_CPUS_MASK_SIZE)] (i % MAX_CPUS_MASK_SIZE))
1)
+ncpus++;
+
+if (VIR_ALLOC_N(cpus, ncpus) 0)
+goto cleanup;
+
+for (ncpus = 0, i = 0 ; i MAX_CPUS ; i++)
+if ((mask[(i / MAX_CPUS_MASK_SIZE)] (i % MAX_CPUS_MASK_SIZE))
1)
+cpus[ncpus++] = i;
+
+fprintf(stderr, Do node %d %d\n, n, ncpus);
+if (virCapabilitiesAddHostNUMACell(caps,
+ n,
+ ncpus,
+ cpus) 0)
+goto cleanup;
+
+VIR_FREE(cpus);
+}
+
+ret = 0;
+
+cleanup:
+VIR_FREE(cpus);
+VIR_FREE(mask);
+return ret;
+}
+#else
+static int qemudCapsInitNUMA(virCapsPtr caps ATTRIBUTE_UNUSED) { return 0; }
+#endif
+
virCapsPtr qemudCapsInit(void) {
struct utsname utsname;
virCapsPtr caps;
@@ -401,6 +467,9 @@ virCapsPtr qemudCapsInit(void) {
0, 0)) == NULL)
goto no_memory;
+if (qemudCapsInitNUMA(caps) 0)
+goto no_memory;
+
for (i = 0 ; i (sizeof(arch_info_hvm)/sizeof(arch_info_hvm[0])) ; i++)
if (qemudCapsInitGuest(caps,
utsname.machine,
Index: src/qemu_driver.c
===
RCS file: /data/cvs/libvirt/src/qemu_driver.c,v
retrieving revision 1.74
diff -u -p -r1.74 qemu_driver.c
--- src/qemu_driver.c 15 May 2008 16:11:40 - 1.74
+++ src/qemu_driver.c 15 May 2008 21:07:50 -
@@ -47,6 +47,10 @@
#include sys/wait.h
#include libxml/uri.h
+#if HAVE_NUMACTL
+#include numa.h
+#endif
+
#include libvirt/virterror.h
#include event.h
@@ -1605,6 +1609,62 @@ static char *qemudGetCapabilities(virCon
}
+#if HAVE_NUMACTL
+static int
+qemudNodeGetCellsFreeMemory(virConnectPtr conn,
+unsigned long long *freeMems,
+int startCell,
+int maxCells)
+{
+int n, lastCell, numCells;
+fprintf(stderr, Foo %d %d\n, startCell, maxCells);
+if (numa_available() 0) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_NO_SUPPORT,
+ %s, _(NUMA not supported on this host));
+return -1;
+}
+lastCell = startCell + maxCells - 1;
+if (lastCell numa_max_node())
+lastCell = numa_max_node();
+
+for (numCells = 0, n = startCell ; n = lastCell ; n++) {
+long long mem;
+if (numa_node_size64(n, mem) 0) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
+ %s, _(Failed to query NUMA free memory));
+return -1;
+}
+fprintf(stderr, baro %d %llu\n, n, mem);
+
Re: [libvirt] PATCH: Pass -name argument to QEMU
On Tue, May 13, 2008 at 12:21:02AM +0100, Daniel P. Berrange wrote: -if (strstr(help, \n-drive)) -*flags |= QEMUD_CMD_FLAG_DRIVE_OPT; [...] +if (strstr(help, -drive)) +*flags |= QEMUD_CMD_FLAG_DRIVE; Why this change? I put the \n in front to prevent something like disk-drive in a descriptive text making libvirt think that -drive was a valid option. -- Soren Hansen | Virtualisation specialist | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/ signature.asc Description: Digital signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Pass -name argument to QEMU
On Thu, May 15, 2008 at 11:20:50PM +0200, Soren Hansen wrote: On Tue, May 13, 2008 at 12:21:02AM +0100, Daniel P. Berrange wrote: -if (strstr(help, \n-drive)) -*flags |= QEMUD_CMD_FLAG_DRIVE_OPT; [...] +if (strstr(help, -drive)) +*flags |= QEMUD_CMD_FLAG_DRIVE; Why this change? I put the \n in front to prevent something like disk-drive in a descriptive text making libvirt think that -drive was a valid option. Xenner doesn't start its help output right at the start of line, and there isn't any other output there that causes ambiguity in current qemu help output: # qemu-kvm | grep -- -drive -drive [file=file][,if=type][,bus=n][,unit=m][,media=d][index=i] If one happens to be added in the future, that's fine because -drive will be enabled anyway for future releases. Regards, Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] PATCH: Pass -name argument to QEMU
On Thu, May 15, 2008 at 09:14:12PM +0200, Gerd Hoffmann wrote: Daniel P. Berrange wrote: This patch makes libvirt pass the -name argumet to QEMU it if it supported by the QEMU binary in question. THis allows QEMU to set the VNC title and allows Xenner to set the Xen guest name in xenstore. xenner also has -uuid and -domid switches, passing those too would be great because they will also show up correctly in xenstore then. Good idea, I'll make a patch for this too Dan -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] Domain XML format using defined storage volume + RFC
On Thu, 15 May 2008, Stefan de Konink wrote:
On Thu, 15 May 2008, Stefan de Konink wrote:
I almost started crying why it didn't work. But it is fixed, and it works
as a charm :) See updated patch!
I guess I need to write the 'check' tool and documentation update too?
Since there is currently no check build for pools in that directory, I'm
passing this to someother person.
Patch incorporates now a documentation update.
Sign-off-by: Stefan de Konink [EMAIL PROTECTED]
Stefan
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 02ca509..8e2a7b6 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -344,7 +344,7 @@
dl
dtcodedisk/code/dt
ddThe codedisk/code element is the main container for describing
- disks. The codetype/code attribute is either file or block
+ disks. The codetype/code attribute is either file, block or
pool
and refers to the underlying source for the disk. The optional
codedevice/code attribute indicates how the disk is to be exposed
to the guest OS. Possible values for this attribute are floppy, disk
@@ -354,7 +354,11 @@
ddIf the disk codetype/code is file, then the codefile/code
attribute
specifies the fully-qualified path to the file holding the disk. If the
disk
codetype/code is block, then the codedev/code attribute
specifies
- the path to the host device to serve as the disk. span
class=sinceSince 0.0.3/span/dd
+ the path to the host device to serve as the disk. If the disk
codetype/code
+is pool, then the codepool/code and codevolume/code specify the
+virtual location of the disk, the path is automatically resolved if the
pool
+and the volume exist.
+span class=sinceSince 0.0.3/span/dd
dtcodetarget/code/dt
ddThe codetarget/code element controls the bus / device under
which the
disk is exposed to the guest OS. The codedev/code attribute
indicates
diff --git a/src/xml.c b/src/xml.c
index 22dc211..9fd093e 100644
--- a/src/xml.c
+++ b/src/xml.c
@@ -1300,6 +1300,8 @@ virDomainParseXMLDiskDesc(virConnectPtr conn, xmlNodePtr
node,
typ = 0;
else if (xmlStrEqual(type, BAD_CAST block))
typ = 1;
+else if (xmlStrEqual(type, BAD_CAST pool))
+typ = 2;
xmlFree(type);
}
device = xmlGetProp(node, BAD_CAST device);
@@ -1309,11 +1311,24 @@ virDomainParseXMLDiskDesc(virConnectPtr conn,
xmlNodePtr node,
if (cur-type == XML_ELEMENT_NODE) {
if ((source == NULL)
(xmlStrEqual(cur-name, BAD_CAST source))) {
-
if (typ == 0)
source = xmlGetProp(cur, BAD_CAST file);
-else
+else if (typ == 1)
source = xmlGetProp(cur, BAD_CAST dev);
+else if (typ == 2) {
+xmlChar *pool = xmlGetProp(cur, BAD_CAST pool);
+xmlChar *volume = xmlGetProp(cur, BAD_CAST volume);
+if (pool != NULL volume != NULL) {
+virStoragePoolPtr virPool;
+virPool = virStoragePoolLookupByName(conn, (const char
*) pool);
+if (virPool != NULL) {
+virStorageVolPtr virVol;
+virVol = virStorageVolLookupByName(virPool, (const
char *) volume);
+if (virVol != NULL)
+source = BAD_CAST virStorageVolGetPath(virVol);
+}
+}
+}
} else if ((target == NULL)
(xmlStrEqual(cur-name, BAD_CAST target))) {
target = xmlGetProp(cur, BAD_CAST dev);
@@ -1411,7 +1426,8 @@ virDomainParseXMLDiskDesc(virConnectPtr conn, xmlNodePtr
node,
virBufferVSprintf(buf, (uname 'phy:%s'), source);
else
virBufferVSprintf(buf, (uname 'phy:/dev/%s'), source);
-}
+} else if (typ == 2)
+virBufferVSprintf(buf, (uname 'phy:%s'), source);
}
if (ro == 1)
virBufferAddLit(buf, (mode 'r'));
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFC] API vs XML
Hi, In my previous email Daniel made clear that for many functions it is preferable to have access to the XML output. I would like to know what the general opinion is about defining a domain. I can understand that people don't mind to define a domain manually or with tools and pump it inside libvirt with the virDomainDefineXML call. But why are the XML tree manipulating features not incorporated into the API? Slightly more 'semantics based' than Attach/Detach Device. Allowing to specify the information that is going into the XML. So for example: domainptr = virDomainDefine(name) virDomainSetName(domainptr, name) virDomainSetBootloader(domainptr, path) virDomainSetOS(domainptr, type) virDomainSetMemory(domainptr, amount, live) virDomainSetVCPU(domainptr, amount, live) virDomainAttachDisk(domainptr, type, sourceptr, targetptr, live) virDomainDetachDevice(domainptr, deviceptr, live) I know there are people that love XML here, but can someone give a reasonable statement why not to support the above? (More clean, less parsing) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] API vs XML
On Fri, May 16, 2008 at 01:26:07AM +0200, Stefan de Konink wrote: But why are the XML tree manipulating features not incorporated into the API? Slightly more 'semantics based' than Attach/Detach Device. Allowing to specify the information that is going into the XML. So for example: domainptr = virDomainDefine(name) virDomainSetName(domainptr, name) virDomainSetBootloader(domainptr, path) virDomainSetOS(domainptr, type) virDomainSetMemory(domainptr, amount, live) virDomainSetVCPU(domainptr, amount, live) virDomainAttachDisk(domainptr, type, sourceptr, targetptr, live) virDomainDetachDevice(domainptr, deviceptr, live) I know there are people that love XML here, but can someone give a reasonable statement why not to support the above? (More clean, less parsing) Less easily extendable, while maintaining ABI compatability. For nearly every functional aspect of the XML, we have had to add new attributes or elements as we've learned more about usage scenario, and ported to other hypervisors. If we exposed everything via the API we'd be adding new APIs, deprecating old APIs. Take your 'virDomainAttachDisk' example, we just lsat week added a 'bus' attribute to disk, so we'd now need to add a virDomainAttachDiskWithBus method. Then we need to also provide the disk format type (qcow, vmdk, raw, etc), so we'll need another API virDomainAttachDiskWithBusFormat. This is non scalable. Other alternatives are to create a big pile of structs for all the data, but then we need to be able to add new struct elements, so we'll be passing around piles of flags, or sizeof() on the structs. All this stuff has to be replicated in all the language bindings for the API (Perl, Python, Java, Ruby, OCaml, etc). Maintaining stable ABIs is very hard work, and even for our existing APIs we have made mistakes in the past which we have to live with - eg we now have 3 virConnectOpen() methods. The migration ABI for the remote protocol was very carefully planed designed to be extendable, but we discovered we couldn't quite manage to make it work for QEMU. Maintaining stable XML format is also pretty non-trivial, and we've made mistakes here too, but it is easier to add attributes and elements to the document describing a VM without risking the ABI compatability. Most of our mistakes have been todo with poor choice of naming for concepts and some illogical structure in areas. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] [ANNOUNCE] virt-df 2.1.0 - a 'df' tool for virtual guests
On Thu, May 15, 2008 at 07:53:55PM +0100, Richard W.M. Jones wrote: On Thu, May 15, 2008 at 02:54:53PM +0100, Daniel P. Berrange wrote: This version supports most common filesystems and partitioning schemes, including: - Linux ext2/3 - DOS FAT32 - Windows NTFS - Linux LVM2 (volume groups and logical volumes) - Primary and extended disk partitions - Linux swap - Linux suspend partition I'm assuming this only works for raw file block devices ? Are you planning to support the funky QCow / VMDK formats too ? Yes, interesting point. Since I always use flat files or straight partitions for my guests I admit I hadn't given this much thought :-) However support for these formats is just a matter of decoding enough of the structure to enable the same mappings to be made in the 'virt-df' library, same as for LVM2 or indeed MBR partitions now. I'll take a look at it. IIRC there are several different undocumented variations on the QCow format? There's version 1, and version 2. And then the incompatible version 2 inflicted by Xen :-( The other thing that could be annoying is that Fedora 9 support for encrypting all volumes - might need to prompt for a decryption key for that. Yes -- any encrypted volumes aren't going to work at the moment, and couldn't work unless there was a way to access the passphrase. The passphrase is in the user's brain. THe OS prompts for it at boot time, so virt-df would need todo similar if it wanted to support decryption. Perhaps its just not a important use case. In the ISP model, guest admins won't trust the host admin so you won't have the keys anyway. If the guest admin does trust the host admin, would they really be using encryption in the guest ? Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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: [libvirt] Question about more finer access control permission on libvirt
Hi, Dan Thank you for commenting this. I am eased to hear this. I also agrees this issue has many task. p.s. I want to know the possibility of fine grained access control in libvirt, since our young guy is investigating the access control in Dom0-Xen. Thanks Atsushi SAKAI Daniel P. Berrange [EMAIL PROTECTED] wrote: On Fri, May 09, 2008 at 09:49:19AM +0900, Atsushi SAKAI wrote: I have a question of libvirt with Polkit. Currently, the libvirt w/ Polkit has 2 access control permissions. (Read Only and Read Write) Have you planned to expand the access control more finer? In my use case, Policy should define by domain, operation, operator. Of course, operator is already considered on current libvirt w/ Polkit. So at this point, it needs to add domain and operation policy. The use case is for many(about 100 or more) domain operation. I just want to know how to minimize granting access control permission of each user on libvirt in future. PolicyKit at this time is only used to authenticate local access from applications running in the host's desktop session. While it allows you to make up many fine grained permissions, it doesn't let you dynamicaly associate the permissions with individual objects. eg there is a policykit check to determine whether a user is allowed to mount removable disks - that applies to all removal disks - you can say disk A, but not disk B. While we could add lots more privileges that just read-write and read-only this would only get us part way to where we really need to be. The ideal goal is that we can have fine grained privileges applied to individual virtual machines, storage pools, networks, etc. The only framework that really comes close to this level of flexibility is SELinux, so one of the long term TODO items is to investigate whether we can integrate with SELinux for fine grained access control. As an example DBus uses SELinux to control who can access services on the system bus, and what actisons they can perform. Another example is SEPostgresql which uses SELinux to control accesss to individual tuples colums in the database. So it is clearly able to provide the flexibility we need and scales to huge performance critical applications such as databases. This doesn't make it a quick or easy task to use in libvirt though. It'll involve alot of thought, design development. In the mean time, it is possible that PolicyKit might actually gain the ability to apply authorizaation to individual objects, and also gain ability to use SELinux as its underlying policy engine. So we have to watch what happens there too. There's not really any firm timeline for any of this work, but its stuff we definitely want to get into libvirt Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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
