[Libvir] virDomainLookupByID problem when Root
by Daniele Sgandurra
Hi all!
I've tried to compile and execute info1.c both as user and as root. As user I have no problem, but as root I get:
Failed to find Domain 0
I've traced back the problem to the function:
virDomainLookupByID(virConnectPtr conn, int id)
at the line:
path = xs_get_domain_path(conn->xshandle, (unsigned int) id);
When root I get path != NULL, otherwise path==NULL;
if path==NULL then the block after it is executed and everything is ok, otherwise at the end of the function name=null. (I manually changed path to NULL so that I can run it when root and it works even if info.maxMem it's different from when the program is run as a normal user: it shows -4 instead of 464896).
It could be a configuration problem of mine (of Xen Store for example)?
Thanks!
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
17 years, 10 months
[Libvir] announce: gnome-applet-vm-0.1.0rc1
by Karel Zak
I have just pushed out a new version of the VM Applet. The
changes/features are:
- D-BUS support and integration with virt-manager
- console helper support for privileged operations
- fixed a lot of bugs
- new icons
- better GUI
- the applet internally supports multiple libvirt connection (in
future it will be useful for monitoring remote virtual machines)
Web page (with screenshot of course:-):
http://people.redhat.com/kzak/gnome-applet-vm/
Please, help me found bugs and improve this application.
Karel
--
Karel Zak <kzak(a)redhat.com>
17 years, 10 months
[Libvir] Patch: Fix for UUIDs in XML parser
by Peter Vetere
Hi all. Here's a pretty straightforward patch that fixes a bug I found
where, if <uuid>...</uuid> is specified in the XML on the call
createLinux, it is not propagated down to Xend. The result is an
instance with a different UUID than the one requested.
Pete
17 years, 10 months
[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net
I imagined that each Libvirt user could choose its own MAX number of CPU.
If it is not possible, at least can we reserve the extended cpumap for
future development (TODO, same as NULL domain pointer) ?
Veuillez répondre à veillard(a)redhat.com
Pour : michel.ponceau(a)bull.net
cc : libvir-list(a)redhat.com
Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
On Thu, Jul 13, 2006 at 01:12:47PM +0200, michel.ponceau(a)bull.net wrote:
> I don't understand. Libvirt users must of course compile API and
> application with the same libvirt.h, after updating the value of
> VIR_MAX_CPUS when necessary. And go from first info element to next one
by
> (info+1), which adds sizeof(virVcpuInfo) to address, including correct
> length of cpumap according to:
> unsigned char cpumap[(VIR_MAX_CPUS + 7) / 8]; /* Bit map of usable
> real CPUs.
> For alignment constraints, compiler rounds up the
sizeof(virVcpuInfo)when
> needed.
Well if you need to recompile the library to use a larger set of
CPU you don't garantee API and ABI, by definition. And you will need
to recompile the library because the structures passed between the
app and the library change size, this will also likely affect the
proxy since I expect vCPU informations to be provided (so communication
between the library and proxy must change).
There is certainly solutions to the scalability problem, but suggesting
a change of header and recompilation of the whole software stack is really
not one I would like to propose, it breaks basically all expectations an
enterprise customer would have w.r.t. using the library.
Unless I really misunderstood what you were suggesting, which is
possible
in that case reformulating it might be a good idea, because I really
understood
you want to make the MAX number of CPU a compile time setting.
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
17 years, 10 months
[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net
I don't understand. Libvirt users must of course compile API and
application with the same libvirt.h, after updating the value of
VIR_MAX_CPUS when necessary. And go from first info element to next one by
(info+1), which adds sizeof(virVcpuInfo) to address, including correct
length of cpumap according to:
unsigned char cpumap[(VIR_MAX_CPUS + 7) / 8]; /* Bit map of usable
real CPUs.
For alignment constraints, compiler rounds up the sizeof(virVcpuInfo)when
needed.
Veuillez répondre à veillard(a)redhat.com
Pour : michel.ponceau(a)bull.net
cc : libvir-list(a)redhat.com
Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
On Tue, Jul 11, 2006 at 05:29:52PM +0200, michel.ponceau(a)bull.net wrote:
> 2) CPU map cut into standard + extension : It would be more simple to
let
> each Libvirt user modify the value of VIR_MAX_CPUS in private libvirt.h.
> It could be similar to the version number update, from libvirt.h.in to
> libvirt.h :
> #define LIBVIR_VERSION_NUMBER @LIBVIRT_VERSION_NUMBER@
No, I do think it is instead very hard. You start to get into very
annoying
problems from an API point of view. How do you go from the first element
in the info array to the next one ? in the client it's already not nice,
you must do pointer arithmetic (and I really don't want to push an API
which
forces that to most users), it expose potential serious problem like
alignment
and packing, problems between versions of compilers and tools.
In a nutshell I don't want an API where one need to access an array of
structure where the size of the structure is not defined by the API
itself.
What I suggested did that in both case, either low number of CPUs and
fixed size records like you initial solutions, or high number of CPUs and
you work on a two dimentional array of bytes.
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
17 years, 10 months
[Libvir] Connecting to remote hypervisors?
by Nick Devito
I might be overlooking something, but, I don't see anything on the
libvirt site about it. Does libvirt support connecting to a remote
hypervisor, if so, how?
Thanks,
Nick Devito
17 years, 10 months
[Libvir] Updated snapshot of virt-manager GUI application
by Daniel P. Berrange
I have just pushed out RPM / tar.gz of a new development (alpha) snapshot
of the virt-manager GUI application. The changes in this snapshot are:
* Fixed DBus service activation & general brokeness
* Added a display of virtual CPU count in summary view
* Fixed alignment of status label in details page
* Make hardware config panel resizeable
* Switch detailed graph rendering to use sparkline code instead of
matplotlib, removing a huge RPM dependancy chain
* Switch to use filled sparkline graphs instead of outline
Although I didn't increment the RPM dependancy, I strongly recommend using
libvirt 0.1.3 if your host is running > 5 guest domains. This reduces the
number of HTTP GETs made by an order of magnitude, improving the response
time / scalability of the virt-manager refresh.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
17 years, 10 months
[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net
1) PinVcpu : I consider the size of CPU map in bytes, that is (max_nb_CPUs
+ 7) / 8 .
2) CPU map cut into standard + extension : It would be more simple to let
each Libvirt user modify the value of VIR_MAX_CPUS in private libvirt.h.
It could be similar to the version number update, from libvirt.h.in to
libvirt.h :
#define LIBVIR_VERSION_NUMBER @LIBVIRT_VERSION_NUMBER@
Veuillez répondre à veillard(a)redhat.com
Pour : michel.ponceau(a)bull.net
cc : libvir-list(a)redhat.com
Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
On Tue, Jul 11, 2006 at 04:14:12PM +0200, michel.ponceau(a)bull.net wrote:
> Corrections on proposal:
> 1) PinVcpus
> Replace:
> * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo)
> * @maplen: length of cpumap, in 8-bit bytes
> by:
> * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes).
> * Each bit set to 1 means that corresponding CPU is usable.
> * Bytes are stored in little-endian order: CPU0-7, 8-15...
> * In each byte, lowest CPU number is least significant bit.
> * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in
> * underlying virtualization system (Xen...).
> * If maplen < size, missing bytes are set to zero.
> * If maplen > size, failure code is returned.
Okay, that's sensible I guess except for maplen it can go from
1 to size + 7 div 8 not up to size , right ?
> 2) GetVcpu
> Add 4rth argument:
> * @maplen: number of bytes in cpumap field of virVcpuInfo
> virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo,
> int maplen)
>
> 3) Structure VcpuInfo
> Suppress: #define VIR_MAX_CPUS 256
> Replace:
> unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real
CPUs.
> by:
> unsigned char cpumap[]; /* Bit map of usable real CPUs.
> Variable length: it may be less or greater than size of CPU map
in
> underlying virtualization system (Xen...).
Hum, I could see compilers righteously complaining about
unsigned char cpumap[];
in a structure. Maybe we should default to 256 / 8 but allow at the API
level
to grow over that value. What we could do is define a default of 256
available
in the structure and allow an extra parameter which could point to a
larger
array like the following:
- restore VIR_MAX_CPUS as VIR_STD_MAX_CPUS 256
- virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int
maxinfo,
char *lcpumap, int lmaplen);
lcpumap and lmaplen being extra arguments for very large arrays
for most use case, we will fit in 256 processors, those will be
respectively
NULL and 0, but assuming we have more than 256 processors:
+ maxinfo > VIR_STD_MAX_CPUS
+ lcpumap points to a array of bytes, they are interpreted as an
array of cpumap of ((maxinfo + 7) div 8) bytes each. So
if lmaplen != ((maxinfo + 7) div 8) * maxinfo then there is an
error.
in that case the cpumap structures of info are not filled on return.
We still have a relatively simple API for the common case, and for
special
cases we have an extension capability with relatively clear definitions.
it's
a bitstrange but I think that should cover most case as best as possible
> 4) Accessor macros: to be defined later.
okay,
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
17 years, 10 months
[Libvir] Release of libvirt-0.1.2
by Daniel Veillard
Available at ftp://libvirt.org/libvirt/
This release includes only a couple of things:
- fix the header include problem reported last week
- add a proxy based driver for read only access from non-root users
In a nutshell the proxy goal is to allow monitoring from unpriviledged users
by running a proxy which is a small binary running as root accepting
connections from libvirt instances and implementing then using either
xend RPCs or hypervisor calls. Only read-only operations are implemented
i.e. it is useful for monitoring. This requires the (xend-unix-server yes)
option to be set in /etc/xen/xend-config.sxp since the proxy connects to
xend with the httpdu local socket, that done one can disable the
xend-http-server .
The proxy itself is started and stopped automatically by the library on-demand.
The communication between libvirt instances and the proxy is custom, currently
only synchronous operations are implemented but it should be possible to
add asynchronous event passing if libvirt is extended this way.
The next things I will focuse on are: the 4 unimplemented yet APIs for
defined but non-running domains, the CPU extensions which have been
proposed last week and the HVM (fully virtualized) Xen domain support
sent by Jim Fehlig.
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
17 years, 10 months
[Libvir] Updated patch for hvm guests
by Jim Fehlig
Attached is an updated patch providing some support for HVM guests. I
have tested listing info on running guests and creating guests. cdrom
support for HVM guests still needs some work, as does graphics options.
Guests using graphics type 'sdl' still need some work. Using type 'vnc'
is functional, but you must then manually use e.g. "vncviewer
localhost:<dom_id>" to view.
I've also included a patch that backs out some optimizations done
xend_internal.c. There is a bug in xend (from testing - I think Anthony
fixed it and patch got applied to unstable) that does not close the
connection after initial create op causing libvirt to block
indefinitely. Backing out the optimizations allowed me to use the hvm
patch on _testing branch of xen. I've included it for anyone else that
may want to experiment with the hvm patch on _testing xen.
Finally, the attached archive contains: 1. a sample xml input file for
hvm guest, 2. corresponding s-expr sent to xend, and 3. s-expr returned
from xend when getting info on the running guest.
I will be on vacation and not have access to network until July 9. I
will improve this work after returning.
Enjoy,
Jim
17 years, 10 months
