On Thu, Feb 10, 2011 at 04:16:39PM +0100, Matthias Bolte wrote:
[...]
> > it seems to compile and work fine for me. there is however a small
> > problem at configure time:
> >
> > -
> > thinkpad:~/tmp/libvirt-0.8.8 -> ./autogen.sh --system ; make
> > Running ./configure with --prefix=/usr --sysconfdir=/etc
> > --localstatedir=/var --libdir=/usr/lib
> > fatal: Not a git repository (or any of the parent directories): .git
> > fatal: Cannot open 'bootstrap.conf': No such file or directory
> > usage: git diff [--no-index]
> > /home/veillard/tmp/libvirt-0.8.8/tmpwrk2661/archive
> > /home/veillard/tmp/libvirt-0.8.8/tmpwrk2661/archive
> > /home/veillard/tmp/libvirt-0.8.8/tmpwrk2661/archive
> > Copying file m4/codeset.m4
> > -
> >
> > Seems some git command is launched but errors out, that's normal
> > but it should not pollute the output (there is also the extra paths
> > output but that's due to the fact that I use CDPATH env variable
> > and as a result "cd dir" is not silent when successful but output
> > the target dir).
> >
> > Daniel
> >
>
> Why does the build from a tarball try to use git anyway? I can
> reproduce the failing git call.
>
> And syntax-check fails like this, but I'm not sure if it's supposed to
> work from a tarball at all:
>
> $ make -s syntax-check
> fatal: Not a git repository (or any of the parent directories): .git
> fatal: Cannot open 'bootstrap.conf': No such file or directory
> usage: git diff [--no-index]
> make: *** No rule to make target `docs/hacking1.xsl', needed by
> `HACKING'. Stop.
I guess the following should fix the missing stylesheets issue
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
diff --git a/docs/Makefile.am b/docs/Makefile.am
index 43c54f6..0dfd764 100644
--- a/docs/Makefile.am
+++ b/docs/Makefile.am
@@ -80,6 +80,7 @@ fig = \
EXTRA_DIST=\
apibuild.py \
site.xsl newapi.xsl news.xsl page.xsl \
+ hacking1.xsl hacking2.xsl \
$(dot_html) $(dot_html_in) $(gif) $(apihtml) $(apipng) \
$(devhelphtml) $(devhelppng) $(devhelpcss) $(devhelpxsl) \
$(xml) $(fig) $(png) $(css) \
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Jim Fehlig wrote:
> Markus Groß wrote:
>
>> 2. The driver supports libvirtxml <-> xen-xm conversion, thanks to the
>> unified xen
>>driver which already offered this functionality. But since this driver is
>>not part of xen unified, I had to copy this functionality, rather than
>> reusing it.
>>
>>
>
> Yep, same with some of the capabilities code. But I haven't done much
> in the way of libvirtXML <-> xen-xm conversion since I'm not convinced
> the libvirt libxenlight driver should even manage vms it has not created
> (similar to qemu driver). If a vm is started with xl tool, it has a
> daemon spawned to listen for domain death, CD eject, etc. events. I'm
> not sure of libvirt libxenlight driver should get involved with that.
>
Just to clarify, we do need to convert xl/libxl config syntax (which is
same as legacy xen python config files except that arbitrary embedded
python is not supported) to libvirtXML. At a minimum, it will be needed
to support virConnectDomain{From,To}Native(). My point above is that
this functionality, and the other missing driver table functions, can be
added incrementally. But we do need to solve the code duplication with
existing xen driver, at which point we have the conversion anyhow.
Speaking of code duplication, I think we can solve it as Matthias did
for esx and vmware/player drivers - see src/vmx. What do you think?
Thanks,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 02/10/2011 12:18 PM, Eric Blake wrote:
> On 02/09/2011 07:19 PM, Wen Congyang wrote:
>> set QEMUD_CMD_FLAG_PCI_MULTIBUS before calling qemuBuildCommandLine()
>> as the flags is not set by qemuCapsExtractVersionInfo().
>>
>> Signed-off-by: Wen Congyang
>>
>> ---
>> tests/qemuxml2argvtest.c |9 +
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> ACK to both patches; however, they must be squashed and applied as 1
> (otherwise, 'git bisect' will detect spurious 'make check' failures).
I've now pushed this.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Markus Groß wrote:
> Hi,
>
> I started working on a libxenlight driver for libvirt a few weeks ago.
> By that time I didn't knew Jim Fehlig was also working on a driver for that
> api:
> http://article.gmane.org/gmane.comp.emulators.libvirt/33024
>
> Because I already did some work and there is no driver from Jim yet,
> I am posting my current version of the driver here.
>
I was hoping to get an initial submission this week but have been quite ill.
> It is a driver for the libxl (libxenlight) interface from the upcoming xen
> 4.1.
>
> This driver is divided into 3 patches, the first adds the driver without
> changing anything in libvirt, the second one integrates it into the
> build system of libvirt. The last one is self explanatory.
>
> However there are a few caveats.
>
> 1. The driver offers only basic functionality like: suspend, resume, pinvcpu,
> etc.
>create, restore, definexml and others are not yet implemented.
>
I took the approach of getting define, create, reboot, capabilities,
getinfo, and dumpxml implemented.
> 2. The driver supports libvirtxml <-> xen-xm conversion, thanks to the
> unified xen
>driver which already offered this functionality. But since this driver is
>not part of xen unified, I had to copy this functionality, rather than
> reusing it.
>
Yep, same with some of the capabilities code. But I haven't done much
in the way of libvirtXML <-> xen-xm conversion since I'm not convinced
the libvirt libxenlight driver should even manage vms it has not created
(similar to qemu driver). If a vm is started with xl tool, it has a
daemon spawned to listen for domain death, CD eject, etc. events. I'm
not sure of libvirt libxenlight driver should get involved with that.
Hmm, I should just post my current driver so you can take a look.
Thanks.
Jim
> 3. To compile libvirt with this driver, there is a new flag --with-xenlight.
>To fix some linker errors, libvirt has to link against several
>additional libraries now which are used in xen's libxenlight.
>These libraries are not directly used within libvirt,
>but I believe that some of them are GPL licensed, so that could be an
> issue.
>
> 4. To compile the driver you may need to copy the libxl_utils.h
>from tools/libxl of your xen-source directory to an include dir in your
> PATH.
>Right now this file is not copied when installing xen,
>but I will talk with the xen developers about that.
>
> Please let me know what you think about it.
>
> Thanks,
> Markus
>
>
> Markus Groß (3):
> Add basic libxenlight driver
> Integrate libxenlight driver into libvirt
> Add myself to AUTHORS
>
> AUTHORS |1 +
> configure.ac | 35 +-
> include/libvirt/virterror.h |1 +
> po/POTFILES.in |2 +
> src/Makefile.am | 25 +
> src/driver.h |3 +-
> src/libvirt.c| 13 +
> src/util/virterror.c |3 +
> src/xenlight/xl_driver.c | 948 ++
> src/xenlight/xl_driver.h | 46 +
> src/xenlight/xl_driver_private.h | 52 +
> src/xenlight/xl_utils.c | 1969
> ++
> src/xenlight/xl_utils.h | 90 ++
> tools/virsh.c|3 +
> 14 files changed, 3188 insertions(+), 3 deletions(-)
> create mode 100644 src/xenlight/xl_driver.c
> create mode 100644 src/xenlight/xl_driver.h
> create mode 100644 src/xenlight/xl_driver_private.h
> create mode 100644 src/xenlight/xl_utils.c
> create mode 100644 src/xenlight/xl_utils.h
>
>
>
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 02/10/2011 02:57 AM, Laine Stump wrote:
> The solution is to create a dummy tap interface with a MAC guaranteed
> to be lower than any guest interface's MAC, and attach that tap to the
> bridge as soon as it's created. Since all guest MAC addresses start
> with 0xFE, we can just generate a MAC with the standard "0x52, 0x54,
> 0" prefix, and it's guaranteed to always win (physical interfaces are
> never connected to these bridges, so we don't need to worry about
> competing numerically with them).
>
> +++ b/docs/formatnetwork.html.in
> @@ -105,12 +105,15 @@
> Addressing
>
>
> - The final set of elements define the IPv4 address range available,
> - and optionally enable DHCP sevices.
> + The final set of elements define the addresses (IPv4 and/or
> + IPv6, as well as MAC) to be assigned to the bridge device
> + associated with the virtual network, and optionally enable DHCP
> + sevices.
s/sevices/services/
(pre-existing, but as long as you're touching that sentence...)
>
> + mac
> + The address attribute defines a MAC
> +(hardware) address formatted as 6 groups of 2-digit
> +hexadecimal numbers, the groups separated by colons
> +(eg, "52:54:00:1C:DA:2F"). This MAC address is
> +assigned to the bridge device when it is created. Generally
> +it is best to not specify a mac address when creating a
Hmm, for consistency, I'm thinking s/mac/MAC/g
> +network - in this case, if a defined mac address is needed for
> +proper operation, libvirt will automatically generate a random
> +mac address and save it in the config. Allowing libvirt to
(3 instances); but feel free to disregard that if you think it results
in too many all-caps words.
> +generate the MAC address will assure that it is compatible
> +with the idiosyncracies of the platform where libvirt is
s/idiosyncracies/idiosyncrasies/
> +++ b/libvirt.spec.in
> @@ -741,6 +741,44 @@ then
> > %{_sysconfdir}/libvirt/qemu/networks/default.xml
> ln -s ../default.xml
> %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml
> fi
> +
> +# All newly defined networks will have a mac address for the bridge
> +# auto-generated, but networks already existing at the time of upgrade
> +# will not. We need to go through all the network configs, look for
> +# those that don't have a mac address, and add one.
> +
> +network_files=`(cd %{_localstatedir}/lib/libvirt/network; \
> + ls *.xml | xargs grep -L "mac address"; \
> +cd %{_sysconfdir}/libvirt/qemu/networks; \
> + ls *.xml | xargs grep -L "mac address") \
> +| sort | uniq`
This leaks a message to stderr if globbing fails:
ls: cannot access *.xml: No such file or directory
You want to use && rather than ; after cd (in case for some weird reason
cd fails, you don't want to be globbing in the wrong location).
sort | uniq wastes a process. For that matter, do we really expect the
glob to result in so many networks that we exceed ARG_MAX limitations,
or can we ditch the xargs process?
`` is yucky - let's use $()
network_files=$( (cd %{_localstatedir}/lib/libvirt/network && \
grep -L "mac address" *.xml; \
cd %{_sysconfdir}/libvirt/qemu/networks && \
grep -L "mac address" *.xml) 2>/dev/null \
| sort -u)
> +
> +for file in $network_files
> +do
> + # each file exists in either the config or state directory (or both) and
> + # does not have a mac address specified in either. We add the same mac
> + # address to both files (or just one, if the other isn't there)
> +
> + mac4=`printf '%X' $(($RANDOM % 256))`
> + mac5=`printf '%X' $(($RANDOM % 256))`
> + mac6=`printf '%X' $(($RANDOM % 256))`
> + for dir in %{_localstatedir}/lib/libvirt/network
> %{_sysconfdir}/libvirt/qemu/networks
> + do
> + if test -f $dir/$file
> + then
> + sed -i.orig -e \
Is sed -i atomic? I know perl -i is not (that is, perl moves the file
to a temporary, the puts output into the original, but there exists a
window of time where the original file name refers to an incomplete
file). Are we better off skipping -i, and doing sed into a secondary
file, and atomically renaming that file over the original if all went
well? On the other hand, then you have to start worrying about file
permissions being accidentally changed.
http://www.pixelbeat.org/docs/unix_file_replacement.html
Or do we just give up on the atomicity requirement, and call this method
good enough (that is, you are unlikely to be upgrading rpm at the same
time that libvirt is trying to read (or worse modify) one of these .xml
files).
> + "s|\( address='52:54:00:$mac4:$mac5:$mac6'/>|" \
> + $dir/$file
> + if ! test $?
Won't work. $? is always non-empty, which means test $? is always true,
which means ! test $? will al
On 02/10/2011 02:53 AM, Laine Stump wrote:
> ==
> V3 changes:
>
> 0) The actual code remains untouched from V2.
>
> 1) Add txmode attribute to the domain schema, and to an xml2xml and
>xml2argv test (note that the particular file used for the xml2xml
>test was previously only being used for xml2argv, and it needed
>some cleaning up before it would work properly.
>
> 2) Document the attribute on the website, along with a bold warning to
>leave it alone!
Looks good.
> +++ b/tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel61-device
> @@ -72,3 +72,28 @@ virtio-blk-pci.ioeventfd=on/off
> virtio-blk-pci.vectors=uint32
> virtio-blk-pci.indirect_desc=on/off
> virtio-blk-pci.scsi=on/off
> +virtio-net-pci.vectors=uint32
> +virtio-net-pci.indirect_desc=on/off
> +virtio-net-pci.csum=on/off
Nice. Should we also be updating qemu-kvm-0.13.0-device with similar
content (using the Fedora 14 qemu-kvm, for example), which has
virtio-net-pci but lacks the tx parameter, to prove that the flag does
not get set in that test case?
ACK with that nit addressed (I trust you can amend that file without
having to see a v4). However, I'm not sure if this is okay to push now
(since you proposed the series before feature freeze) or not (since it
missed the freeze announcement and therefore is missing out on release
candidate testing); DV, can you give an answer?
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 02/09/2011 07:19 PM, Wen Congyang wrote:
> set QEMUD_CMD_FLAG_PCI_MULTIBUS before calling qemuBuildCommandLine()
> as the flags is not set by qemuCapsExtractVersionInfo().
>
> Signed-off-by: Wen Congyang
>
> ---
> tests/qemuxml2argvtest.c |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
ACK to both patches; however, they must be squashed and applied as 1
(otherwise, 'git bisect' will detect spurious 'make check' failures).
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 02/09/2011 12:43 PM, Eric Blake wrote:
> On 02/09/2011 09:58 AM, Daniel P. Berrange wrote:
>> Move the qemudStartVMDaemon and qemudShutdownVMDaemon
>> methods into a separate file, renaming them to
>> qemuProcessStart, qemuProcessStop. All helper methods
>> called by these are also moved & renamed to match
>>
>> * src/Makefile.am: Add qemu_process.c/.h
>> * src/qemu/qemu_command.c: Add emuDomainAssignPCIAddresses
>
> s/ emu/ qemu/
>
> ACK; I reviewed an interdiff between this and your v1 [1], and you have
> correctly picked up all the changes that went in to qemu_driver.c since
> that posting, as well as resolved all my concerns from that post, except
> for the spelling nit in the commit message.
Also, be sure you don't lose commit eacb3bb02 when rebasing (I almost
did when testing out your patch today).
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 02/09/2011 09:58 AM, Daniel P. Berrange wrote:
> Implement the v3 migration protocol, which has two extra
> steps, 'begin' on the source host and 'confirm' on the
> source host. All other methods also gain both input and
> output cookies to allow bi-directional data passing at
> all stages
>
> * src/qemu/qemu_driver.c: Wire up migrate v3 APIs
> * src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Add
> begin & confirm methods
> ---
> src/qemu/qemu_driver.c| 318 +++-
> src/qemu/qemu_migration.c | 141 ++--
> src/qemu/qemu_migration.h | 16 ++-
ACK.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 02/09/2011 09:58 AM, Daniel P. Berrange wrote:
> The migration protocol has support for a 'cookie' parameter which
> is an opaque array of bytes as far as libvirt is concerned. Drivers
> may use this for passing around arbitrary extra data they might
> need during migration. The QEMU driver needs todo a few things:
s/todo/to do/
>
> - Pass hostname/uuid to allow strict protection against localhost
>migration attempts
> - Pass SPICE/VNC server port from the target back to the source to
>allow seemless relocation of client sessions
s/seemless/seamless/
> +static void qemuMigrationCookieGraphicsFree(qemuMigrationCookieGraphicsPtr
> grap)
> +{
> +if (!grap)
> +return;
> +VIR_FREE(grap->listen);
> +VIR_FREE(grap->tlsSubject);
> +VIR_FREE(grap);
> +}
> +
> +
> +static void qemuMigrationCookieFree(qemuMigrationCookiePtr mig)
Should these two be added to cfg.mk's list of free-like functions?
> +if (virXPathLong("string(./graphics/@port)", ctxt, &port) < 0) {
> +qemuReportError(VIR_ERR_INTERNAL_ERROR,
> +"%s", _("missing port attribute in migration data"));
> +goto error;
> +}
> +grap->port = (int)port;
Why not just virXPathInt("...", ctxt, &grap->port, instead of going
through the temporary variable?
> +if (grap->type == VIR_DOMAIN_GRAPHICS_TYPE_SPICE) {
> +if (virXPathLong("string(./graphics/@tlsPort)", ctxt, &port) < 0) {
> +qemuReportError(VIR_ERR_INTERNAL_ERROR,
> +"%s", _("missing port attribute in migration
> data"));
> +goto error;
> +}
> +grap->tlsPort = (int)port;
Likewise.
> @@ -358,6 +873,16 @@ qemuMigrationPrepareTunnel(struct qemud_driver *driver,
> event = virDomainEventNewFromObj(vm,
> VIR_DOMAIN_EVENT_STARTED,
> VIR_DOMAIN_EVENT_STARTED_MIGRATED);
> +
> +if (qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen,
> +QEMU_MIGRATION_COOKIE_GRAPHICS) < 0) {
> +/* We could tear down the whole guest here, but
> + * cookie data is (so far) non-critical, so that
> + * seems little harsh. We'll just warn for now..
s/seems /seems a / (twice)
ACK with those nits fixed.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
2011/2/10 Minoru Usui :
> Hi, Eric
>
> On Tue, 1 Feb 2011 10:26:36 +0900
> Minoru Usui wrote:
>
>> Hi, Eric
>>
>> On Mon, 31 Jan 2011 15:46:39 -0700
>> Eric Blake wrote:
>>
>> > On 01/27/2011 02:51 AM, Minoru Usui wrote:
>> > > virNodeGetInfo() gets from
>> > > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq, first.
>> > >
>> > > Signed-off-by: Minoru Usui
>> >
>> > I haven't looked closely at this series yet...
>> >
>> > > + /*
>> > > + * nodeinfo->mhz should return maximum frequency,
>> > > + * but "cpu MHz" of /proc/cpuinfo is scaled by power saving feature.
>> > > + * So it gets cpufreq/cpuinfo_max_freq, if possible.
>> > > + */
>> > > + ret = get_cpu_value(0, "cpufreq/cpuinfo_max_freq", true);
>> > > + if (ret < 0)
>> > > + return -1;
>> > > + else if (ret != 1) {
>> > > + /* convert unit */
>> > > + cpu_mhz = ret / 1000;
>> >
>> > But which units is this converting between, and should it truncate or
>> > round up?
>>
>> I think it divide by 1000 is collect, because my machine returns below
>> values.
>>
>> -
>> # cat /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_max_freq
>> 231
>> 231
>> 231
>> 231
>> 231
>> 231
>> 231
>> 231
>>
>> # grep 'cpu MHz' /proc/cpuinfo
>> cpu MHz : 2333.331
>> cpu MHz : 2333.331
>> cpu MHz : 2333.331
>> cpu MHz : 2333.331
>> cpu MHz : 2333.331
>> cpu MHz : 2333.331
>> cpu MHz : 2333.331
>> cpu MHz : 2333.331
>> -
>>
>> On the other hand, I don't have clear opinion about truncate or round up.
>> Present implementation of linuxNodeInfoCPUPopulate() selects truncate,
>> so I implement to truncate logic.
>
> Are my explanations enough?
> If not or I'm misunderstanding something, please let me know.
>
I think we should round up in case we request something, because then
we get at least what we requested. If we truncate a request we might
get less than we requested, this might result in a bad situation.
Recently we switched from truncation to rounding up for memory and
storage request because of this.
But here we are reporting something. In that case we should truncate,
because if we would round up we could report more than there actually
is, this might result in a bad situation too.
So with rounding up request and truncating reports we are on the safe
side in both cases.
Matthias
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
?Ooopps,
my fault, seems I have missreaded the nrg sorry, address are well defined in
the rng :S
Sorry,
Arnaud
From: arnaud.champ...@devatom.fr
Sent: Thursday, February 10, 2011 5:59 PM
To: libvir-list@redhat.com
Subject: [libvirt] domain.rng updated ?
Hi,
I'm working on C# bindings, my goal is to expose xml descriptions (domain,
node, storage and so on...) as real C# objects, for this, I'm studying the rng
files provided in /docs/schemas/ directory of the sources. I'm currently
working on domain.rng.
I don't know if the domain.rng file is up to date because, for example, the
disk device definition in the rng doesn't speak about the "address" node that a
virhs dumpxml show :
Is the domain.rng up to date or should I use the libvirt.org XML format page
only ?
Regards,
Arnaud
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 02/10/2011 09:59 AM, arnaud.champ...@devatom.fr wrote:
> ?Hi,
>
> I'm working on C# bindings, my goal is to expose xml descriptions (domain,
> node, storage and so on...) as real C# objects, for this, I'm studying the
> rng files provided in /docs/schemas/ directory of the sources. I'm currently
> working on domain.rng.
> I don't know if the domain.rng file is up to date because, for example, the
> disk device definition in the rng doesn't speak about the "address" node that
> a virhs dumpxml show :
>
>
>
>
>
>
>
Actually, it does permit the sub-element:
defines the , then a
that selects the with of file, as well
as an that includes .
includes an ,
which covers the you were asking about.
>
> Is the domain.rng up to date or should I use the libvirt.org XML format page
> only ?
The libvirt.org XML format page (generated from
docs/formatdomain.html.in) is supposed to match domain.rng; if they
don't, that's a documentation bug and should be fixed.
Meanwhile, domain.rng is a subset of actual XML parsed by the code;
there are some additional elements, such as , that can only be
present in a live xml dump but are ignored for defining or creating a
domain. The rule of thumb is that if 'virsh dumpxml --inactive' can
produce an element, then domain.rng should permit it and
formatdomain.html.in should document it.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
?Hi,
I'm working on C# bindings, my goal is to expose xml descriptions (domain,
node, storage and so on...) as real C# objects, for this, I'm studying the rng
files provided in /docs/schemas/ directory of the sources. I'm currently
working on domain.rng.
I don't know if the domain.rng file is up to date because, for example, the
disk device definition in the rng doesn't speak about the "address" node that a
virhs dumpxml show :
Is the domain.rng up to date or should I use the libvirt.org XML format page
only ?
Regards,
Arnaud--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
2011/2/10 Daniel Veillard :
> We're entering the week freeze for 0.8.8, so let's delay new feature
> until the end of next week and let's focuse on bug fixes. I have put an
> initial release candidate at:
>
> ftp://libvirt.org/libvirt/libvirt-0.8.8-rc1.tar.gz
>
> it seems to compile and work fine for me. there is however a small
> problem at configure time:
>
> -
> thinkpad:~/tmp/libvirt-0.8.8 -> ./autogen.sh --system ; make
> Running ./configure with --prefix=/usr --sysconfdir=/etc --localstatedir=/var
> --libdir=/usr/lib
> fatal: Not a git repository (or any of the parent directories): .git
> fatal: Cannot open 'bootstrap.conf': No such file or directory
> usage: git diff [--no-index]
> /home/veillard/tmp/libvirt-0.8.8/tmpwrk2661/archive
> /home/veillard/tmp/libvirt-0.8.8/tmpwrk2661/archive
> /home/veillard/tmp/libvirt-0.8.8/tmpwrk2661/archive
> Copying file m4/codeset.m4
> -
>
> Seems some git command is launched but errors out, that's normal
> but it should not pollute the output (there is also the extra paths
> output but that's due to the fact that I use CDPATH env variable
> and as a result "cd dir" is not silent when successful but output
> the target dir).
>
> Daniel
>
Why does the build from a tarball try to use git anyway? I can
reproduce the failing git call.
And syntax-check fails like this, but I'm not sure if it's supposed to
work from a tarball at all:
$ make -s syntax-check
fatal: Not a git repository (or any of the parent directories): .git
fatal: Cannot open 'bootstrap.conf': No such file or directory
usage: git diff [--no-index]
make: *** No rule to make target `docs/hacking1.xsl', needed by
`HACKING'. Stop.
Another Win32 problem was pthread_sigmask usage in virsh. Dan pushed a
fix for that a moment ago. I still have another Win32 problem related
to %lld in format strings.
Matthias
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Feb 10, 2011 at 03:38:08PM +0100, Matthias Bolte wrote:
> 2011/2/10 Daniel P. Berrange :
> > On Thu, Feb 10, 2011 at 03:20:37PM +0100, Matthias Bolte wrote:
> >> 2011/2/10 Daniel P. Berrange :
> >> > Win32 doesn't have a concept of signal masks so disable that
> >> > code. It is unclear how SIGINT is delivered (if at all) on
> >> > Win32, so this might further work to provide an alternative
> >> > to pthread_sigmask
> >> >
> >> > * tools/virsh.c: Avoid pthread_sigmask on Win32
> >> > ---
> >>
> >> ACK. This fixes one of the current problems on Win32.
> >
> > This was the only problem I see with Win32. What others do you see ?
> >
> > Regards,
> > Daniel
>
> I get errors like this related to %lld in format strings:
>
> virsh.c: In function 'cmdDomblkstat':
> virsh.c:990:9: warning: unknown conversion type character 'l' in
> format [-Wformat]
>
> The problem goes away when I replace the define for vshPrint
>
> #define vshPrint(ctl, ...) fprintf(stdout, __VA_ARGS__)
>
> by this function
>
> static void
> vshPrint(vshControl *ctl ATTRIBUTE_UNUSED, const char *format, ...)
I'm surprised you didn't need to annotate this
with ATTRIBUTE_FMT_PRINTF, otherwise gcc would
assume win32 printf style, rather than gnu IIUC.
> {
> va_list ap;
>
> va_start(ap, format);
> vfprintf(stdout, format, ap);
> va_end(ap);
> }
>
> I'm not sure why this became a problem now, as vshPrint is a define
> since 2006 and virsh used to compile before. Maybe this is an issue
> with gnulib in the current libvirt-0.8.8-rc1 tarball, as I'm testing
> based on this tarball it.
>
> Are you compiling this from a git checkout or a tarball?
I'm using GIT.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
2011/2/10 Daniel P. Berrange :
> On Thu, Feb 10, 2011 at 03:20:37PM +0100, Matthias Bolte wrote:
>> 2011/2/10 Daniel P. Berrange :
>> > Win32 doesn't have a concept of signal masks so disable that
>> > code. It is unclear how SIGINT is delivered (if at all) on
>> > Win32, so this might further work to provide an alternative
>> > to pthread_sigmask
>> >
>> > * tools/virsh.c: Avoid pthread_sigmask on Win32
>> > ---
>>
>> ACK. This fixes one of the current problems on Win32.
>
> This was the only problem I see with Win32. What others do you see ?
>
> Regards,
> Daniel
I get errors like this related to %lld in format strings:
virsh.c: In function 'cmdDomblkstat':
virsh.c:990:9: warning: unknown conversion type character 'l' in
format [-Wformat]
The problem goes away when I replace the define for vshPrint
#define vshPrint(ctl, ...) fprintf(stdout, __VA_ARGS__)
by this function
static void
vshPrint(vshControl *ctl ATTRIBUTE_UNUSED, const char *format, ...)
{
va_list ap;
va_start(ap, format);
vfprintf(stdout, format, ap);
va_end(ap);
}
I'm not sure why this became a problem now, as vshPrint is a define
since 2006 and virsh used to compile before. Maybe this is an issue
with gnulib in the current libvirt-0.8.8-rc1 tarball, as I'm testing
based on this tarball it.
Are you compiling this from a git checkout or a tarball?
Matthias
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Feb 10, 2011 at 03:20:37PM +0100, Matthias Bolte wrote:
> 2011/2/10 Daniel P. Berrange :
> > Win32 doesn't have a concept of signal masks so disable that
> > code. It is unclear how SIGINT is delivered (if at all) on
> > Win32, so this might further work to provide an alternative
> > to pthread_sigmask
> >
> > * tools/virsh.c: Avoid pthread_sigmask on Win32
> > ---
>
> ACK. This fixes one of the current problems on Win32.
This was the only problem I see with Win32. What others do you see ?
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
2011/2/10 Daniel P. Berrange :
> Win32 doesn't have a concept of signal masks so disable that
> code. It is unclear how SIGINT is delivered (if at all) on
> Win32, so this might further work to provide an alternative
> to pthread_sigmask
>
> * tools/virsh.c: Avoid pthread_sigmask on Win32
> ---
ACK. This fixes one of the current problems on Win32.
Matthias
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Feb 09, 2011 at 10:33:01 -0700, Eric Blake wrote:
> On 02/09/2011 09:02 AM, Jiri Denemark wrote:
> > This needs to be squashed into the previous patch but is provided
> > separately for easier review.
> > ---
> > src/qemu/qemu_capabilities.c | 14 +
> > src/qemu/qemu_capabilities.h |2 +
> > tests/qemuhelptest.c | 727
> > +-
> > tests/qemuxml2argvtest.c | 468 ++--
> > 4 files changed, 617 insertions(+), 594 deletions(-)
> >
> > void
> > +qemuCapsSetList(virBitmapPtr caps, ...)
> > +{
> > +va_list list;
> > +int flag;
> > +
> > +va_start(list, caps);
> > +while ((flag = va_arg(list, int)) < QEMU_CAPS_LAST)
This is the bug I was talking about in the previous email. I should rather use
"enum qemuCapsFlags" instead of "int" in case someone passes -fshort-enum
option to gcc which would result in the enum being represented as char rather
than int.
> > +ignore_value(virBitmapSetBit(caps, flag));
> > +va_end(list);
>
> QEMU_CAPS_LAST as a terminal seems a bit awkward. Would it be any
> better to require 0 to be the terminal?
The problem is that 0 is a valid flag value (QEMU_CAPS_KQEMU) addressing the
lowest bit. We could reserve the value for a terminal but in that case we
could never make use of the lowest bit in the bitmap. Not that it would make a
huge difference but QEMU_CAPS_LAST just seemed good enough to me :-) Also it's
kinda nice to have a call like
qemuCapsSetList(caps, QEMU_CAPS_1, QEMU_CAPS_2, ..., QEMU_CAPS_LAST)
Jirka
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
> On 02/09/2011 09:02 AM, Jiri Denemark wrote:
> > This is done for two reasons:
> > - we are getting very close to 64 flags which is the maximum we can use
> > with unsigned long long
> > - by using LL constants in enum we already violates C99 constraint that
> > enum values have to fit into int
>
> Does gcc warn about that (possible via some -W flag that we aren't
> currently using)?
It doesn't warn about it by default and I'm not aware of any flag which would
turn this warning on.
> Or are we silently relying on a (common) extension that might bite us
> elsewhere?
Apparently yes.
It already bit me when I wanted to change tests to use qemuCaps* functions
before the patch that starts using virBitmap. Passing enum values as variable
arguments didn't work at all since the values didn't have all the same type.
Those that fit into int were ints and the others were long.
Which reminds me I have a possible bug in the last patch...
> > -*flags = qemuCapsComputeCmdFlags(help, *version, *is_kvm,
> > *kvm_version);
> > +qemuCapsComputeCmdFlags(help, *version, *is_kvm, *kvm_version, flags);
> > +
> > +if (!(strflags = virBitmapString(flags))) {
> > +virReportOOMError();
> > +return -1;
> > +}
> > +
> > +VIR_DEBUG("Version %u.%u.%u, cooked version %u, flags %s",
> > + major, minor, micro, *version, strflags);
> > +VIR_FREE(strflags);
>
> Using virReportOOMError() is harsh, when the only thing that we lack is
> a VIR_DEBUG(). Would it be any better to do:
>
> if ((strflags = virBitmapString(flags))) {
> VIR_DEBUG(...);
> VIR_FREE(strflags);
> }
>
> and just lose the debug message if we're tight on memory?
Yeah, that's probably better, although it wouldn't make a huge difference in
practise anyway. After all, logging functions also just ignore OOM conditions.
> > void
> > -qemuCapsClear(unsigned long long *caps,
> > +qemuCapsClear(virBitmapPtr caps,
> >enum qemuCapsFlags flag)
> > {
> > -*caps &= ~flag;
> > +ignore_value(virBitmapClearBit(caps, flag));
>
> So why does this require caps to exist...
Trying to set caps that are NULL is more a bug in the code than something that
is intentional (as oppose to the Get case) and I prefer to get a SIGSEGV
instead of magically hiding that, esp. since gcc is not very clever (see
below).
> > }
> >
> >
> > bool
> > -qemuCapsGet(unsigned long long caps,
> > +qemuCapsGet(virBitmapPtr caps,
> > enum qemuCapsFlags flag)
> > {
> > -return !!(caps & flag);
> > +bool b;
> > +
> > +if (!caps || virBitmapGetBit(caps, flag, &b) < 0)
>
> while this does not? Shouldn't qemuCapsGet be marked ATTRIBUTE_NONNULL(1)?
This is mostly for two reasons. First, gcc only warns on ATTRIBUTE_NONNULL if
NULL is explicitly passed as a parameter and not if it's done through a
variable. So it doesn't really help with detecting cases where NULL is
indirectly passed to qemuCapsGet(). Second, there are places (actually it's
probably just one case currently) in the code where we don't care what the
qemu binary is capable of when calling a function that expect qemuCaps
argument. So we want to pass NULL there. And it seems more practical to me to
do the test inside qemuCapsGet that in any place where it could possibly be
called with NULL.
>
> >
> > -void qemuCapsSet(unsigned long long *caps,
> > - enum qemuCapsFlags flag);
> > +virBitmapPtr qemuCapsNew(void);
> > +
> > +# define qemuCapsFree(caps) virBitmapFree(caps)
>
> Add this to cfg.mk's list of free-like functions.
Ah, I forgot to do that because I originally wanted to just get rid of
qemuCapsFree() and call virBitmapFree directly instead. I didn't do that so
I'll add the macro to cfg.mk.
> > -bool qemuCapsGet(unsigned long long caps,
> > +bool qemuCapsGet(virBitmapPtr caps,
> > enum qemuCapsFlags flag);
>
> I guess you really did intend for qemuCapsGet to work even if
> qemuCapsFree failed.
I didn't get this last comment. Could you be more specific about what you
wanted to say? :-)
Jirka
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
---
AUTHORS |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/AUTHORS b/AUTHORS
index 38ea4bb..24ae98b 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -154,6 +154,7 @@ Patches have also been contributed by:
Zdenek Styblik
Gui Jianfeng
Michal Novotny
+ Markus GroÃ
[send patches to get your name here]
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Hi,
I started working on a libxenlight driver for libvirt a few weeks ago.
By that time I didn't knew Jim Fehlig was also working on a driver for that api:
http://article.gmane.org/gmane.comp.emulators.libvirt/33024
Because I already did some work and there is no driver from Jim yet,
I am posting my current version of the driver here.
It is a driver for the libxl (libxenlight) interface from the upcoming xen 4.1.
This driver is divided into 3 patches, the first adds the driver without
changing anything in libvirt, the second one integrates it into the
build system of libvirt. The last one is self explanatory.
However there are a few caveats.
1. The driver offers only basic functionality like: suspend, resume, pinvcpu,
etc.
create, restore, definexml and others are not yet implemented.
2. The driver supports libvirtxml <-> xen-xm conversion, thanks to the unified
xen
driver which already offered this functionality. But since this driver is
not part of xen unified, I had to copy this functionality, rather than
reusing it.
3. To compile libvirt with this driver, there is a new flag --with-xenlight.
To fix some linker errors, libvirt has to link against several
additional libraries now which are used in xen's libxenlight.
These libraries are not directly used within libvirt,
but I believe that some of them are GPL licensed, so that could be an issue.
4. To compile the driver you may need to copy the libxl_utils.h
from tools/libxl of your xen-source directory to an include dir in your PATH.
Right now this file is not copied when installing xen,
but I will talk with the xen developers about that.
Please let me know what you think about it.
Thanks,
Markus
Markus Groß (3):
Add basic libxenlight driver
Integrate libxenlight driver into libvirt
Add myself to AUTHORS
AUTHORS |1 +
configure.ac | 35 +-
include/libvirt/virterror.h |1 +
po/POTFILES.in |2 +
src/Makefile.am | 25 +
src/driver.h |3 +-
src/libvirt.c| 13 +
src/util/virterror.c |3 +
src/xenlight/xl_driver.c | 948 ++
src/xenlight/xl_driver.h | 46 +
src/xenlight/xl_driver_private.h | 52 +
src/xenlight/xl_utils.c | 1969 ++
src/xenlight/xl_utils.h | 90 ++
tools/virsh.c|3 +
14 files changed, 3188 insertions(+), 3 deletions(-)
create mode 100644 src/xenlight/xl_driver.c
create mode 100644 src/xenlight/xl_driver.h
create mode 100644 src/xenlight/xl_driver_private.h
create mode 100644 src/xenlight/xl_utils.c
create mode 100644 src/xenlight/xl_utils.h
--
1.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 02/10/2011 05:48 AM, Daniel P. Berrange wrote:
Quite a few hosts don't have cgroups mounted and so see warnings
from libvirt logged, which then cause bug reports, etc. Reduce
the log level to INFO so they're not visible by default
* src/qemu/qemu_driver.c: Reduce log level for cgroups
---
src/qemu/qemu_driver.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 52ea98e..20a4157 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -1331,7 +1331,7 @@ qemudStartup(int privileged) {
rc = virCgroupForDriver("qemu",&qemu_driver->cgroup, privileged, 1);
if (rc< 0) {
char buf[1024];
-VIR_WARN("Unable to create cgroup for driver: %s",
+VIR_INFO("Unable to create cgroup for driver: %s, disabling cgroups",
virStrerror(-rc, buf, sizeof(buf)));
}
ACK.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
> > @@ -3181,12 +3181,18 @@ qemuBuildCommandLine(virConnectPtr conn,
> > devices. Fortunately, those don't need
> > static PCI addresses, so we don't really
> > care that we can't use -device */
> > -if ((qemuCmdFlags & QEMU_CAPS_DEVICE) &&
> > -(disk->bus != VIR_DOMAIN_DISK_BUS_XEN))
> > -withDeviceArg = 1;
> > -if (!(optstr = qemuBuildDriveStr(disk, bootable,
> > - (withDeviceArg ? qemuCmdFlags
> > :
> > - (qemuCmdFlags &
> > ~QEMU_CAPS_DEVICE)
> > +if (qemuCapsGet(qemuCmdFlags, QEMU_CAPS_DEVICE)) {
> > +if (disk->bus != VIR_DOMAIN_DISK_BUS_XEN) {
> > +withDeviceArg = 1;
> > +} else {
> > +qemuCapsClear(&qemuCmdFlags, QEMU_CAPS_DEVICE);
> > +deviceFlagMasked = true;
> > +}
> > +}
> > +optstr = qemuBuildDriveStr(disk, bootable, qemuCmdFlags);
> > +if (deviceFlagMasked)
> > +qemuCapsSet(&qemuCmdFlags, QEMU_CAPS_DEVICE);
> > +if (!optstr)
>
> Certainly a tougher prospect. On the surface, it looks correct;
> however, I'm worried that there might be some potential for a data race
> bug - that is, if we ever have any command that can build a command line
> string while holding a read-only connection, is it right to be
> temporarily modifying the domain def? (That is, it seems like
> domxml-to-native should work on a read-only connection without trying to
> modify the guest definition.)
Eh, the code is not changing domain def anywhere. The only thing which is
changed is qemuCmdFlags, which is generated in every caller of
qemuBuildCommandLine() so cloning the bitmap seemed like an unneeded overkill
to me.
> Would it be any easier to just change the signature of qemuBuildDriveStr
> to take an additional bool parameter on whether to ignore the
> QEMU_CAPS_DEVICE flag?
That's another possibility.
> My concerns about qemuBuildDriveStr probably warrant a v2 patch (perhaps
> broken into two portions - separating a parameter addition or cloning
> from the mechanical rewrite into helper functions).
Do you still think it's needed?
Jirka
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Quite a few hosts don't have cgroups mounted and so see warnings
from libvirt logged, which then cause bug reports, etc. Reduce
the log level to INFO so they're not visible by default
* src/qemu/qemu_driver.c: Reduce log level for cgroups
---
src/qemu/qemu_driver.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 52ea98e..20a4157 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -1331,7 +1331,7 @@ qemudStartup(int privileged) {
rc = virCgroupForDriver("qemu", &qemu_driver->cgroup, privileged, 1);
if (rc < 0) {
char buf[1024];
-VIR_WARN("Unable to create cgroup for driver: %s",
+VIR_INFO("Unable to create cgroup for driver: %s, disabling cgroups",
virStrerror(-rc, buf, sizeof(buf)));
}
--
1.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Feb 10, 2011 at 10:20:04AM +, Daniel P. Berrange wrote:
> On Thu, Feb 10, 2011 at 10:02:35AM +0100, Michal Privoznik wrote:
> > So now we rely on libvirt LIBVIRT_DEFAULT_URI environment variable.
> > ---
> > src/libvirtSnmp.c |3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/libvirtSnmp.c b/src/libvirtSnmp.c
> > index ce21369..39b74bd 100644
> > --- a/src/libvirtSnmp.c
> > +++ b/src/libvirtSnmp.c
> > @@ -180,7 +180,8 @@ int libvirtSnmpInit(void)
> > /* virConnectOpenAuth is called here with all default parameters,
> > * except, possibly, the URI of the hypervisor. */
> > /* TODO: configure the URI */
> > -conn = virConnectOpenAuth("qemu:///system", virConnectAuthPtrDefault,
> > 0);
> > +/* Use libvirt env variable LIBVIRT_DEFAULT_URI by default*/
> > +conn = virConnectOpenAuth("", virConnectAuthPtrDefault, 0);
>
> It needs to be NULL, rather than "".
ACK for a version with NULL :-)
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Feb 10, 2011 at 10:02:35AM +0100, Michal Privoznik wrote:
> So now we rely on libvirt LIBVIRT_DEFAULT_URI environment variable.
> ---
> src/libvirtSnmp.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/src/libvirtSnmp.c b/src/libvirtSnmp.c
> index ce21369..39b74bd 100644
> --- a/src/libvirtSnmp.c
> +++ b/src/libvirtSnmp.c
> @@ -180,7 +180,8 @@ int libvirtSnmpInit(void)
> /* virConnectOpenAuth is called here with all default parameters,
> * except, possibly, the URI of the hypervisor. */
> /* TODO: configure the URI */
> -conn = virConnectOpenAuth("qemu:///system", virConnectAuthPtrDefault, 0);
> +/* Use libvirt env variable LIBVIRT_DEFAULT_URI by default*/
> +conn = virConnectOpenAuth("", virConnectAuthPtrDefault, 0);
It needs to be NULL, rather than "".
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
> > +for ( ; sz > 0; sz--)
> > +virBufferVSprintf(&buf, "%08x", bitmap->map[sz - 1]);
>
> I probably would have written:
>
> while (sz--)
> virBufferVSprintf(&buf, "%08x", bitmap->map[sz]);
Yeah, it looks nicer; I'll use that since I'll send a new version anyway.
> since sz is guaranteed to be non-zero to start with. But your way
> works, and the compiler (hopefully) generates the same code (when
> optimizing).
Not that this is in a performance critical path requiring any optimizations
:-)
> Problem - "%08x" is not portable. bitmap->map[x] is a uint32_t, which
> means we need to use "%08"PRIx32 (since some platforms declare uint32_t
> as long rather than int) to avoid a gcc warning.
Ah, thanks for spotting that. I always forget about this dark side of C.
> For that matter, why did we make the bitset use uint32_t as the
> underlying type, instead of just using long?
Right, I'll fix that first followed by a v2 of this patch.
Jirka
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Feb 10, 2011 at 10:43:08AM +0800, Daniel Veillard wrote:
> On Wed, Feb 09, 2011 at 04:43:25PM +0100, Michal Privoznik wrote:
> > Add environment variable LIBVIRT_MIB_CONNECT_URI to control URI
> > which snmp agent is connecting to. It is now possible to connect
> > to all hypervisors (including test:///) instead of hardcoded
> > qemu:///system, which is used now by default when variable is not
> > set.
>
> Should this use the existing LIBVIRT_DEFAULT_URI if set instead ?
> That's the current way to define the default URI for the stack, so
> why would you want a different one for SNMP ?
Yes, the problem is that the current code is passing an explicit
qemu:///system in to virConnectOpen, so libvirt's default logic
is being bypassed. If the SNMP agent just passed 'NULL' then libvirt
would auto-pick the hypervisor, and LIBVIRT_DEFAULT_URI would also
'just work'. So NACK to this patch, ust replace qemu:///system with
NULL.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Changes in V2:
1) auto-generate mac addresses in networkDefine and
networkCreate instead of networkStartNetworkDaemon,
and add the %post script to fixup existing networks.
2) instead of mac being an attribute of the element,
make it its own element, as is done elsewhere in the xml, eg:
3) The dummy tap device is now called "-nic" rather
than "-mac".
4) add to the website xml docs
5) update network.rng
6) add to a couple of the network xml test data files.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=609463
The problem was that, since a bridge always acquires the MAC address
of the connected interface with the numerically lowest MAC, as guests
are started and stopped, it was possible for the MAC address to change
over time, and this change in the network was being detected by
Windows 7 (it sees the MAC of the default route change), so on each
reboot it would bring up a dialog box asking about this "new network".
The solution is to create a dummy tap interface with a MAC guaranteed
to be lower than any guest interface's MAC, and attach that tap to the
bridge as soon as it's created. Since all guest MAC addresses start
with 0xFE, we can just generate a MAC with the standard "0x52, 0x54,
0" prefix, and it's guaranteed to always win (physical interfaces are
never connected to these bridges, so we don't need to worry about
competing numerically with them).
Note that the dummy tap is never set to IFF_UP state - that's not
necessary in order for the bridge to take its MAC, and not setting it
to UP eliminates the clutter of having an (eg) "virbr0-nic" displayed
in the output of the ifconfig command.
I chose to not auto-generate the MAC address in the network XML
parser, as there are likely to be consumers of that API that don't
need or want to have a MAC address associated with the
bridge.
Instead, in bridge_driver.c when the network is being defined, if
there is no MAC, one is generated. To account for virtual network
configs that already exist when upgrading from an older version of
libvirt, I've added a %post script to the specfile that searches for
all network definitions in both the config directory
(/etc/libvirt/qemu/networks) and the state directory
(/var/lib/libvirt/network) that are missing a mac address, generates a
random address, and adds it to the config (and a matching address to
the state file, if there is one).
docs/formatnetwork.html.in: document
docs/schemas/network.rng: add nac address to schema
libvirt.spec.in: %post script to update existing networks
src/conf/network_conf.[ch]: parse and format
src/libvirt_private.syms: export a couple private symbols we need
src/network/bridge_driver.c:
auto-generate mac address when needed,
create dummy interface if mac address is present.
tests/networkxml2xmlin/isolated-network.xml
tests/networkxml2xmlin/routed-network.xml
tests/networkxml2xmlout/isolated-network.xml
tests/networkxml2xmlout/routed-network.xml: add mac address to some tests
---
docs/formatnetwork.html.in | 21 -
docs/schemas/network.rng |8 +++
libvirt.spec.in | 38 +++
src/conf/network_conf.c | 30
src/conf/network_conf.h |5 ++
src/libvirt_private.syms |2 +
src/network/bridge_driver.c | 65 ++
tests/networkxml2xmlin/isolated-network.xml |1 +
tests/networkxml2xmlin/routed-network.xml|1 +
tests/networkxml2xmlout/isolated-network.xml |1 +
tests/networkxml2xmlout/routed-network.xml |1 +
11 files changed, 171 insertions(+), 2 deletions(-)
diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in
index b1b0485..be5ceb5 100644
--- a/docs/formatnetwork.html.in
+++ b/docs/formatnetwork.html.in
@@ -105,12 +105,15 @@
Addressing
- The final set of elements define the IPv4 address range available,
- and optionally enable DHCP sevices.
+ The final set of elements define the addresses (IPv4 and/or
+ IPv6, as well as MAC) to be assigned to the bridge device
+ associated with the virtual network, and optionally enable DHCP
+ sevices.
...
+
@@ -121,6 +124,20 @@
+ mac
+ The address attribute defines a MAC
+(hardware) address formatted as 6 groups of 2-digit
+hexadecimal numbers, the groups separated by colons
+(eg, "52:54:00:1C:DA:2F"). This MAC address is
+assigned to the bridge device when it is created. Generally
+it is best to not specify a mac address when creating a
+network
==
V3 changes:
0) The actual code remains untouched from V2.
1) Add txmode attribute to the domain schema, and to an xml2xml and
xml2argv test (note that the particular file used for the xml2xml
test was previously only being used for xml2argv, and it needed
some cleaning up before it would work properly.
2) Document the attribute on the website, along with a bold warning to
leave it alone!
==
This is in response to:
https://bugzilla.redhat.com/show_bug.cgi?id=629662
Explanation
qemu's virtio-net-pci driver allows setting the algorithm used for tx
packets to either "bh" or "timer". This is done by adding ",tx=bh" or
",tx=timer" to the "-device virtio-net-pci" commandline option.
'bh' stands for 'bottom half'; when this is set, packet tx is all done
in an iothread in the bottom half of the driver. (In libvirt, this
option is called the more descriptive "iothread".)
'timer' means that tx work is done in qemu, and if there is more tx
data than can be sent at the present time, a timer is set before qemu
moves on to do other things; when the timer fires, another attempt is
made to send more data. (libvirt retains the name "timer" for this
option.)
The resulting difference, according to the qemu developer who added
the option is:
bh makes tx more asynchronous and reduces latency, but potentially
causes more processor bandwidth contention since the cpu doing the
tx isn't necessarily the cpu where the guest generated the
packets.
Solution
This patch provides a libvirt domain xml knob to change the option on
the qemu commandline, by adding a new attribute "txmode" to the
element that can be placed inside any element in
a domain definition. It's use would be something like this:
...
...
I chose to put this setting as an attribute to rather than as
a sub-element to because it is specific to the virtio-net
driver, not something that is generally usable by all network drivers.
(note that this is the same placement as the "driver name=..."
attribute used to choose kernel vs. userland backend for the
virtio-net driver.)
Actually adding the tx=xxx option to the qemu commandline is only done
if the version of qemu being used advertises it in the output of
qemu -device virtio-net-pci,?
If a particular txmode is requested in the XML, and the option isn't
listed in that help output, an UNSUPPORTED_CONFIG error is logged, and
the domain fails to start.
---
docs/formatdomain.html.in | 50
docs/schemas/domain.rng|8 +++
src/conf/domain_conf.c | 26 ++-
src/conf/domain_conf.h | 11
src/qemu/qemu_capabilities.c |3 +
src/qemu/qemu_capabilities.h |1 +
src/qemu/qemu_command.c| 27 +++
tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel61-device | 25 ++
tests/qemuhelptest.c |3 +-
.../qemuxml2argv-net-virtio-device.args|2 +-
.../qemuxml2argv-net-virtio-device.xml |3 +
tests/qemuxml2argvtest.c |2 +-
tests/qemuxml2xmltest.c|1 +
13 files changed, 158 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 9f7a113..84b1cab 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1378,6 +1378,56 @@ qemu-kvm -net nic,model=? /dev/null
ne2k_isa i82551 i82557b i82559er ne2k_pci pcnet rtl8139 e1000 virtio
+Setting NIC driver-specific
options
+
+
+ ...
+
+
+
+
+
+
+
+
+ ...
+
+
+ Some NICs may have tunable driver-specific options. These are
+ set as attributes of the driver sub-element of the
+ interface definition. Currently the following attributes are
+ available for the "virtio" NIC driver:
+
+
+
+ txmode
+
+The txmode attribute specifies how to handle
+transmission of packets when the transmit buffer is full. The
+value can be either 'iothread' or 'timer'.
+Since 0.8.8 (QEMU and KVM only)
+
+If set to 'iothread', packet tx is all done in an iothread in
+the bottom half of the driver (this option translates into
+adding "tx=bh" to the qemu commandline -device virtio-net-pci
+option).
+
+If set to 'timer', tx work is done in qemu, and if there is
+more tx data than can be sent at the present time, a timer is
+set before qemu moves on to do other things; when the timer
+fires, another attempt is made to send more da
So now we rely on libvirt LIBVIRT_DEFAULT_URI environment variable.
---
src/libvirtSnmp.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/libvirtSnmp.c b/src/libvirtSnmp.c
index ce21369..39b74bd 100644
--- a/src/libvirtSnmp.c
+++ b/src/libvirtSnmp.c
@@ -180,7 +180,8 @@ int libvirtSnmpInit(void)
/* virConnectOpenAuth is called here with all default parameters,
* except, possibly, the URI of the hypervisor. */
/* TODO: configure the URI */
-conn = virConnectOpenAuth("qemu:///system", virConnectAuthPtrDefault, 0);
+/* Use libvirt env variable LIBVIRT_DEFAULT_URI by default*/
+conn = virConnectOpenAuth("", virConnectAuthPtrDefault, 0);
if (NULL == conn) {
printf("No connection to hypervisor\n");
--
1.7.3.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 02/09/2011 08:30 PM, Eric Blake wrote:
On 02/09/2011 11:44 AM, Michal Novotny wrote:
Signed-off-by: Michal Novotny
That created a rather long commit subject for 'git am', so I pruned it.
The project is now maintained by Michal Novotny and it's heavily
based
on Radek's version. For more information including the information
on posting
- the patches you to libvirt-php please refer toPHP
binding page.
+ the patches you to libvirt-php please refer tohttp://libvirt.org/php";>PHP binding.
The grammar was already awful here; we might as well fix it while editing:
For more information, including information on posting patches to
libvirt-php, please refer to thePHP bindings site.
+Project pages
+Since February 2011 the project have it's own pages hosted at libvirt.org.
For more information on the project
+ please refer tohttp://libvirt.org/php";>http://libvirt.org/php.
ACK with that nit fixed, so I pushed it.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Good, thanks for pushing this.
Michal
--
Michal Novotny, RHCE
Virtualization Team (xen userspace), Red Hat
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
