[Libvir] unsigned long
by John Levon
I just saw an email about unsigned long and max memory fly by along with
a comment like "32-bit will never have more than 'X' Gb" ...
This raises an obvious question: is libvirt explictly not 32/64 clean?
On Solaris we build everything 32-bit by default unless there is a
reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit
kernel, then we have a problem.
IMO an API should *always* use explicitly-sized integers when they
contain range or size values (or use size_t etc.). Not doing so is both
dangerous and confusing...
(Xen does indeed have this problem, so we run all their tools with
native word size. Currently we always use a 32-bit libvirt for
'virt-install', and it does seem to work fine. It would be a pity for
this to change).
cheers
john
17 years, 2 months
[Libvir] [PATCH] Remove warning when dumping XML from an inactive domain with Xen < 3.1
by Richard W.M. Jones
# virsh dumpxml solaris32fv
libvir: Xen Daemon error : failed Xen syscall xenDaemonDomainDumpXML
domain ID < 0 and xendConfigVersion < 3 0
[ and dump proceeds as normal ]
The patch just removes the false error message and makes a note that
this still needs a real fix later.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
17 years, 2 months
[Libvir] [PATCH] Fix enum virDrvOpenRemoteFlags
by Richard W.M. Jones
(Thanks Eduardo for pointing this one out ...)
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
17 years, 2 months
[Libvir] Removing virDomainRestart typedef
by Richard W.M. Jones
virDomainReboot takes a flag argument which is documented as:
* @flags: extra flags for the reboot operation, not used yet
In fact, the test driver (alone) allows a virDomainRestart typedef to be
passed as a flag, although it's not clear to me that anything actually
does pass it. Certainly removing virDomainRestart typedef from
<libvirt.h> doesn't break the build, and 'make check' is also OK.
The attached patch moves virDomainRestart typedef into the test driver,
which is the only thing using it. Another possibility would be to go
further and remove the parts of the test driver which "test" this
undocumented feature.
(Thanks to Tóth István for pointing out that this typedef is unused).
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
17 years, 2 months
[Libvir] PATCH: Fix KVM / QEMU pxe boot config
by Daniel P. Berrange
The XML config for PXE boot is being parsed/formatted incorrectly by the
KVM tools. It is using 'net' instead of 'network' for the <boot> tag. I
had even made this mistake in the test suite :-) Patch is simple - also
fixed a flaw in the test suite code
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, 2 months
[Libvir] Start NUMA work
by Daniel Veillard
Okay enclosed is a first patch to add the new entry point for getting
the available memeory in the NUMA cells:
/**
* virNodeGetCellFreeMemory:
* @conn: pointer to the hypervisor connection
* @freeMems: pointer to the array of unsigned long
* @nbCells: number of entries available in freeMems
*
* This call allows to ask the amount of free memory in each NUMA cell.
* The @freeMems array must be allocated by the caller and will be filled
* with the amounts of free memory in kilobytes for each cell starting
* from cell #0 and up to @nbCells -1 or the number of cell in the Node
* (which can be found using virNodeGetInfo() see the nodes entry in the
* structure).
*
* Returns the number of entries filled in freeMems, or -1 in case of error.
*/
int
virNodeGetCellsFreeMemory(virConnectPtr conn, unsigned long *freeMems,
int nbCells)
based on the feedback, it seems it's better to provide an API checking
a range of cells. This version suggest to always start at cell 0, it could be
extended to start at a base cell number, not a big change, is it needed ?
The patch adds it to the driver interfaces and put the entry point
needed in the xen_internal.c module xenHypervisorNodeGetCellsFreeMemory() .
From there it needs a new function (or set of functions) actually doing
one hypercall to get the free mem for a NUMA cell, and the loop to fill
the array @freeMems. The hard part is of course to set the definitions
and code doing the hypercall:
We will need to check the current hypercall version since this was added
recently, see how xenHypervisorGetSchedulerType() does the versionning,
we will have to write a similar routine , extend xen_op_v2_sys to
add support for the availheap call structures, add the define for
the availheap system call, glue the whole and call the new function
from the loop in xenHypervisorNodeGetCellsFreeMemory() ... this can be
a little fun to debug.
Now for extending virConnectGetCapabilities() it is a bit messy not not
that much. First it's implemented on Xen using xenHypervisorGetCapabilities,
unfortunately it seems the easiest way to get the NUMA capabilities is by
asking though xend. Calling xend_internals.c from xen_internals.c is not
nice, but xenHypervisorGetCapabilities() is actually noty using any
hypervisor call as far as I can see, it's all about opening/parsing
files from /proc and /sys and returning the result as XML, so this could
as well be done in the xend_internals (or xen_unified.c) module.
so we will have a bit of surgery to do, but for the first steps of
writing the patch I would not be too concerned by calling a function
in xend_internal.c from xenHypervisorGetCapabilities (or
xenHypervisorMakeCapabilitiesXML) we will just move those 2 in the end
(only problem may be the access to hv_version variable).
Hope this helps, I will not be online most of the week but I will try
to help when possible :-)
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
17 years, 2 months
[Libvir] can't start windows guest domains
by Thomas Antony
Hi.
I'm running F7 x86_64 with kernel 2.6.20-2931.fc7xen and
libvirt-0.3.2-1.fc7. Since i updated to the latest versions i can't
start any windows domains anymore. I thought undefine and reinstall the
domains could resolve the problem, but i get the exact same error message.
There is also a F7 x86_64 guest domain runnning fine on the same host.
Why i can't start any windows domains anymore?
[thomas@srv1 ~]$ sudo virt-install -d -n sbs -r 512 --vcpus=1 -f
/dev/VolGroup01/sbs -w bridge:virbr0 --vnc -k DE -v --arch=i386
--os-type=windows --os-variant=win2k3 -c
/var/www/html/install/SBS2003R2DE_DVD.iso
Mon, 10 Sep 2007 20:38:28 DEBUG Path is block file: Assuming Block
disk type.
Disk /dev/VolGroup01/sbs is already in use by another guest! Do you
really want to use the disk (yes or no)? y
Starting install...
libvir: Xen Daemon error : GET operation failed:
libvir: Xen Daemon error : GET operation failed:
Mon, 10 Sep 2007 20:38:31 DEBUG Creating guest from '<domain type='xen'>
<name>sbs</name>
<currentMemory>524288</currentMemory>
<memory>524288</memory>
<uuid>5f73764f-897c-401c-e9e5-17cb21333334</uuid>
<os>
<type arch='i386'>hvm</type>
<loader>/usr/lib/xen/boot/hvmloader</loader>
<boot dev='cdrom'/>
</os>
<features>
<apic/><acpi/><pae/>
</features>
<on_poweroff>destroy</on_poweroff>
<on_reboot>destroy</on_reboot>
<on_crash>destroy</on_crash>
<vcpu>1</vcpu>
<devices>
<emulator>/usr/lib64/xen/bin/qemu-dm</emulator>
<console device='pty'/>
<disk type='block' device='disk'>
<source dev='/dev/VolGroup01/sbs'/>
<target dev='hda'/>
</disk>
<disk type='file' device='cdrom'>
<source file='/var/www/html/install/SBS2003R2DE_DVD.iso'/>
<target dev='hdc'/>
<readonly/>
</disk>
<interface type='bridge'>
<source bridge='virbr0'/>
<mac address='00:16:3e:33:eb:7b'/>
</interface>
<graphics type='vnc' port='-1' keymap='DE' />
</devices>
</domain>
'
libvir: Xen Daemon error : POST operation failed: (xend.err "Error
creating domain: (12, 'Cannot allocate memory')")
virDomainCreateLinux() failed POST operation failed: (xend.err "Error
creating domain: (12, 'Cannot allocate memory')")
Domain installation may not have been
successful. If it was, you can restart your domain
by running 'virsh start sbs'; otherwise, please
restart your installation.
Mon, 10 Sep 2007 20:38:31 ERROR virDomainCreateLinux() failed POST
operation failed: (xend.err "Error creating domain: (12, 'Cannot
allocate memory')")
Traceback (most recent call last):
File "/usr/bin/virt-install", line 474, in <module>
main()
File "/usr/bin/virt-install", line 438, in main
dom = guest.start_install(conscb,progresscb)
File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 710,
in start_install
return self._do_install(consolecb, meter)
File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 727,
in _do_install
self.domain = self.conn.createLinux(install_xml, 0)
File "/usr/lib64/python2.5/site-packages/libvirt.py", line 563, in
createLinux
if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: virDomainCreateLinux() failed POST operation failed:
(xend.err "Error creating domain: (12, 'Cannot allocate memory')")
[thomas@srv1 ~]$ free
total used free shared buffers cached
Mem: 6154240 1312276 4841964 0 144660 600632
-/+ buffers/cache: 566984 5587256
Swap: 8323064 0 8323064
kind regards,
Thomas
17 years, 2 months
[Libvir] Extending libvirt to probe NUMA topology
by Ryan Harper
Hello all,
I wanted to start a discussion on how we might get libvirt to be able to
probe the NUMA topology of Xen and Linux (for QEMU/KVM). In Xen, I've
recently posted patches for exporting topology into the [1]physinfo
hypercall, as well adding a [2]hypercall to probe the Xen heap. I
believe the topology and memory info is already available in Linux.
With these, we have enough information to be able to write some simple
policy above libvirt that can create guests in a NUMA-aware fashion.
I'd like to suggest the following for discussion:
(1) A function to discover topology
(2) A function to check available memory
(3) Specifying which cpus to use prior to domain start
Thoughts?
1. http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00298.html
2. http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00299.html
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh(a)us.ibm.com
17 years, 2 months
Re: [Libvir] Extending libvirt to probe NUMA topology
by beth kon
Daniel,
I'm taking a stab at this work and want to be sure I'm taking the right
approach. I'm new to xen and even newer to libvirt, so have a bit of a
learning curve.
For the topology information, I assume that this will be a call through
xend, similar to xenDaemonNodeGetInfo. It would seem natural to somehow
extend the xenDaemonNodeGetInfo with this additional information except
that you suggested having the output in XML. Can you explain why you
chose XML?
--
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak(a)us.ibm.com
17 years, 2 months
Re: [Libvir] Documentation errors and shortcomings
by Tóth István
Thanks for the replays
> If an individual stats field isn't supported by the hypervisor, it
> will be returned as ((long long) -1) [for various reasons we're using
> long long here, but really we mean 64 bit signed int].
Thats very useful info, I spent quite a lot of time messing with
BigIntegers, because I didn't want to loose the top bit.
By the way, there are quite a few unisgned ints, and unsigned longs in
the API.
Am I right to assume that "unsigned int" is 32 bits, so It will only fit
into a java long, and "unsigned long" is 64 bits, so it won't fit safely
in any java primitive variable? (Apart form the stats members, as you
wrote above)
> Interesting, so you're using JNI direct access to the C library, right ?
> I looked at this a few weeks ago, but it was looking like accessing using the
> remote access would have made the Java bindings more platform independant
> but I had troubles with the RPC/TLS support, and didn't go very far. Maybe
> a JNI based solution is good enough for most potential Java users.
I thought about that too, but then I read the stern warnings about not
using the private on-the-wire protocol, so I settled on JNI.
I think getting all the crypto and protocol stuff right would be more
work than the JNI version, anyway. Of course since most people won't
want to run the JVM as root, having to use a network URI is almost
required through JNI, too.
Also, I have found an other possible problem in the API/documentation:
The Enum virDomainRestart is defined, but it is not referenced anywhere.
Is it the flag parameter to reboot?
(I've made the mistake of signing up for the digest version of the
mailing list, so I can't directly reply, but I hope I won't mess up the
threading)
regards
István
17 years, 2 months
