[libvirt] [PATCHv2 0/7] Add additional data for the NUMA topology info
by Peter Krempa
This version fixes most of coments on v1 by DanPB and Martin.
The two things that are not yet done are:
1) docs and
2) support for the xend driver
I will follow up with those tomorrow after I create a testbed for xen.
There are 2 new patches:
1/7: fixes bad comment for a bitmap function
7/7: adds data for the test driver
Peter Krempa (7):
util: Fix docs for virBitmapParse
schema: Make the cpuset type reusable across schema files
schemas: Add schemas for more CPU topology information in the caps XML
conf: Split out NUMA topology formatting to simplify access to data
capabilities: Switch CPU data in NUMA topology to a struct
capabilities: Add additional data to the NUMA topology info
test: Add support for thread and core information for the test driver
docs/schemas/basictypes.rng | 6 +++
docs/schemas/capability.rng | 11 ++++++
docs/schemas/domaincommon.rng | 5 ---
src/conf/capabilities.c | 92 ++++++++++++++++++++++++++++++-------------
src/conf/capabilities.h | 14 ++++++-
src/nodeinfo.c | 75 +++++++++++++++++++++++++++++------
src/qemu/qemu_process.c | 2 +-
src/test/test_driver.c | 24 +++++++++--
src/util/virbitmap.c | 16 ++++----
src/xen/xend_internal.c | 25 ++++++------
10 files changed, 201 insertions(+), 69 deletions(-)
--
1.8.1.1
12 years, 4 months
[libvirt] [PATCH] auto-create pci-bridge controller info
by liguang
if some devices specify a pci bus number that
haven't been defined by a pci-bridge controller
then fill the required correct controller info
silently.
it based on previous add pci-bridge support patches,
https://www.redhat.com/archives/libvir-list/2013-January/msg00577.html
Signed-off-by: liguang <lig.fnst(a)cn.fujitsu.com>
---
src/conf/domain_conf.c | 95 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 8ebe77d..dabd374 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -11756,6 +11756,98 @@ virDomainDefMaybeAddSmartcardController(virDomainDefPtr def)
}
+static int
+virDomainDefMaybeAddPcibridgeController(virDomainDefPtr def)
+{
+ int i, idx = 0;
+
+ for (i = 0; i < def->nnets; i++) {
+ if (def->nets[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+ continue;
+ idx = def->nets[i]->info.addr.pci.bus;
+ if (virDomainDefMaybeAddController(def,
+ VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+ return -1;
+ }
+
+ for (i = 0; i < def->nsounds; i++) {
+ if (def->sounds[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+ continue;
+ idx = def->sounds[i]->info.addr.pci.bus;
+ if (virDomainDefMaybeAddController(def,
+ VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+ return -1;
+ }
+
+ for (i = 0; i < def->nvideos; i++) {
+ if (def->videos[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+ continue;
+ idx = def->videos[i]->info.addr.pci.bus;
+ if (virDomainDefMaybeAddController(def,
+ VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+ return -1;
+ }
+
+ for (i = 0; i < def->ncontrollers; i++) {
+ if (def->controllers[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+ continue;
+ idx = def->controllers[i]->info.addr.pci.bus;
+ if (virDomainDefMaybeAddController(def,
+ VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+ return -1;
+ }
+
+ for (i = 0; i < def->nfss; i++) {
+ if (def->fss[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+ continue;
+ idx = def->fss[i]->info.addr.pci.bus;
+ if (virDomainDefMaybeAddController(def,
+ VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+ return -1;
+ }
+
+ for (i = 0; i < def->nhostdevs; i++) {
+ if (def->hostdevs[i]->info->type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+ continue;
+ idx = def->hostdevs[i]->info->addr.pci.bus;
+ if (virDomainDefMaybeAddController(def,
+ VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+ return -1;
+ }
+
+ for (i = 0; i < def->ndisks; i++) {
+ if (def->disks[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+ continue;
+ idx = def->disks[i]->info.addr.pci.bus;
+ if (virDomainDefMaybeAddController(def,
+ VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+ return -1;
+ }
+
+ if (def->watchdog->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+ idx = def->watchdog->info.addr.pci.bus;
+ if (virDomainDefMaybeAddController(def,
+ VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+ return -1;
+
+ if (def->memballoon->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+ idx = def->memballoon->info.addr.pci.bus;
+ if (virDomainDefMaybeAddController(def,
+ VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+ return -1;
+
+ return 0;
+}
+
/*
* Based on the declared <address/> info for any devices,
* add necessary drive controllers which are not already present
@@ -11790,6 +11882,9 @@ int virDomainDefAddImplicitControllers(virDomainDefPtr def)
if (virDomainDefMaybeAddSmartcardController(def) < 0)
return -1;
+ if (virDomainDefMaybeAddPcibridgeController(def) < 0)
+ return -1;
+
return 0;
}
--
1.7.2.5
12 years, 4 months
[libvirt] [RFC PATCH 0/n] Glue domain and storage
by Osier Yang
This is the 4th part to implement NPIV migration support [1].
Part 1:
https://www.redhat.com/archives/libvir-list/2013-January/msg00859.html
Part 2: (Already ACKed by Michal)
https://www.redhat.com/archives/libvir-list/2013-January/msg00859.html
Part 3:
https://www.redhat.com/archives/libvir-list/2013-January/msg01012.html
This set is based on above 3 ones.
The subject "Glue domain and storage" is a bit bigger than what this
series does. This set only tries to support using the storage for
domain disks. And the storage might be further used by disk backing
chains, or future scsi-host passthrough, etc, if the pricinple is
correct. However, this can setup the basis, which can be extended
for future stuffs.
This introduces new XMLs to specify the disk source with storage like
(See PATCH 3/n for more details):
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source type='pool'>
<pool uuid|name="$var"/>
<volume name|path|key='$var'/>
<seclabel relabel='no'/>
</source>
<target dev='vdb' bus='virtio'/>
</disk>
And before domain starting, the source represented by storage is
translated into the real underlying source.
Disk of type 'network' is not supported yet. But I'd like post the
patches as soon as possible to make sure I'm not on the wrong road.
Osier Yang (6):
eng: Remove the duplicate definition
rng: Change the datatype for volume name for common use
Introduce new XMLs to specify disk source using storage pool/vol
New files to glue domain and storage together
Implement translateDiskSourcePool
qemu: Translate the source when starting domain
docs/formatdomain.html.in | 31 ++-
docs/schemas/basictypes.rng | 6 +
docs/schemas/domaincommon.rng | 156 +++++---
docs/schemas/storagepool.rng | 10 +-
docs/schemas/storagevol.rng | 8 +-
src/Makefile.am | 3 +-
src/conf/domain_conf.c | 426 ++++++++++++++++----
src/conf/domain_conf.h | 46 +++
src/conf/domain_storage.c | 45 ++
src/conf/domain_storage.h | 37 ++
src/libvirt_private.syms | 6 +
src/qemu/qemu_driver.c | 7 +
src/storage/storage_driver.c | 207 ++++++++++
.../qemuxml2argv-disk-source-pool.xml | 36 ++
tests/qemuxml2xmltest.c | 1 +
15 files changed, 865 insertions(+), 160 deletions(-)
create mode 100644 src/conf/domain_storage.c
create mode 100644 src/conf/domain_storage.h
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-source-pool.xml
[1] https://www.redhat.com/archives/libvir-list/2012-November/msg00826.html
Regards,
Osier
12 years, 4 months
[libvirt] [Libvirt][Sheepdog]How to test Sheepdog patch
by harryxiyou
Hi Morita and other developers,
I have done following jobs.
1, git clone git://libvirt.org/libvirt.git
2, cd libvirt
3, git reset --hard 036ad50
4, ./autogen.sh
5, make
NOTE: step 3 calls back to Morita's patch for Libvirt version, which is here
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=036ad5052b43fe9f0d19...
After step 5, i have following questions.
1, I am not clear about how to test Sheepdog. Actually, i just wanna study
Sheepdog driver, then i will program our driver for Libvirt.
2, I am not clear about how Sheepdog, Libvirt and QEMU communicate with
each other. Before my test for Sheepdog patch for Libvirt, i have to build
Sheepdog, Libvirt and QEMU environment, right? Morita, i have seen your
patch for Libvirt but i do not find it calls for Sheepdog functions,
so it does not
have to build Sheepdog environment, right?
--
Thanks
Harry Wei
12 years, 4 months
[libvirt] [Sheepdog][Libvirt]How should i test sheepdog in libvirt
by harryxiyou
Hi Morita,
I just wanna test if sheepdog works well in libvirt. I am not sure if
i can only use
libvirt environment to finish this test? Or maybe i should also set up
QEMU/Sheepdog/Openstack environment, right? I have done following jobs.
1, git clone git://libvirt.org/libvirt.git
2, cd libvirt
3, git reset --hard v0.9.13
4, ./autogen.sh && make
NOTE: Step 3 just call back to libvirt version 0.9.13, which you,
Morita, patched
for Libvirt at around this version.
(Your patch is here
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=036ad5052b43fe9f0d19...)
I just wanna study the original patch for libvirt.
After step 4, if i can use tool virsh(under libvirt/tools dir) to test
sheepdog driver?
Therefore, i am not sure how i should use tool virsh to test if Sheepdog driver
works well in libvirt. If i can finish this test only with libvirt
ENV.?(Or also should
set up QEMU/Sheepdog/Openstack environment) How should i do next step?
Could anyone give me some suggestions? Thanks in advance ;-)
--
Thanks
Harry Wei
12 years, 4 months
[libvirt] [Libvirt][QEMU]The relationships between Libvirt and QEMU indetails
by harryxiyou
Hi Daniel and other developers,
We have programed a HLFS(HDFS based Log-Structured FileSystem)
driver for QEMU, which you can see it here.
http://cloudxy.googlecode.com/svn/trunk/hlfs/patches/hlfs_driver_for_qemu...
And i have tested in QEMU environment, which works well for us.
Now, we wanna add a HLFS driver(Volume storage) for Libvirt(The same
as Sheepdog)
but i am not sure how to test HLFS driver for Libvirt. How could i know
if the HLFS driver for Libvirt works well?
I guess libvirt uses qemu interfaces(QEMU way) to finish the real jobs like
create/delete volumes. I wanna use command 'virsh' to finish them, which
the logical procedure like this:
virsh --> libvirt client --> libvirt server --> QEMU
Therefore, 'virsh' cannot work for me. I do not know how to test it with command
'virsh' solely. Or maybe i must build QEMU environment for this test, right?
In brief, i am not clear about the relationships between Libvirt and QEMU.
How do they(QEMU and Libvirt) communicate with each other?
How could i test create/delete volumes of Sheepdog/HLFS only with Libvirt
environment? Could anyone give me some suggestions? Thanks in advance;-)
--
Thanks
Harry Wei
12 years, 4 months
[libvirt] [PATCH] virlog: remove old code comment
by Doug Goldstein
Setting the log output prefix to 0 is not supported and in fact results
in the following message:
warning : virLogParseOutputs:1021 : Ignoring invalid log output setting.
---
src/util/virlog.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/util/virlog.c b/src/util/virlog.c
index acd42c1..24ec9d3 100644
--- a/src/util/virlog.c
+++ b/src/util/virlog.c
@@ -1261,7 +1261,6 @@ static int virLogAddOutputToJournald(int priority)
* x:file:file_path
* output to a file, with the given filepath
* In all case the x prefix is the minimal level, acting as a filter
- * 0: everything
* 1: DEBUG
* 2: INFO
* 3: WARNING
--
1.7.12.4
12 years, 4 months
[libvirt] [PATCH 0/7] Introduce virCommandDoAsyncIO
by Michal Privoznik
Currently, if we want to use IO with asynchronous command we have
to copy code from virFileWrapperFd to misuse our event loop for
reading and writing to the command. However, we can extend our
virCommand implementation to automatically set things up.
Michal Privoznik (7):
virCommand: Introduce virCommandDoAsyncIO
Introduce event loop to commandtest
tests: Create test for virCommandDoAsyncIO
virFileWrapperFd: Switch to new virCommandDoAsyncIO
qemu: Catch stderr of image decompression binary
qemu: Catch stderr of image compression binary
qemu: Destroy domain on decompression binary error
src/libvirt_private.syms | 1 +
src/qemu/qemu_driver.c | 9 +-
src/qemu/qemu_migration.c | 9 +-
src/util/vircommand.c | 214 ++++++++++++++++++++++++++++++++++++++++++--
src/util/vircommand.h | 1 +
src/util/virfile.c | 82 +----------------
tests/commanddata/test3.log | 2 +-
tests/commandtest.c | 136 ++++++++++++++++++++++++++++
8 files changed, 365 insertions(+), 89 deletions(-)
--
1.8.0.2
12 years, 4 months
[libvirt] qemu kvm-pit device arg missing?
by Doug Goldstein
With a domain defined with the following:
<clock offset='utc'>
<timer name='pit' tickpolicy='delay'/>
<timer name='rtc' tickpolicy='catchup'/>
</clock>
The following define is set: VIR_DOMAIN_TIMER_TICKPOLICY_DELAY for
VIR_DOMAIN_TIMER_NAME_PIT. And VIR_DOMAIN_TIMER_TICKPOLICY_CATCHUP for
VIR_DOMAIN_TIMER_NAME_RTC.
I see where for the RTC we'll set -rtc,driftfix=slew (well
-rtc,base=X,driftfix=slew) or -rtc-td-hack for older qemu's. But for
the kvm-pit, we pass with qemu{,-kvm} 1.1 and lower
-no-kvm-pit-reinjection but with qemu{,-kvm} 1.2 the
QEMU_CAPS_NO_KVM_PIT is not set, nor detected via QMP so nothing is
ever passed. I even looked through the QMP commands passed once the
process is started and there doesn't seem to be anything passed. I was
expecting with qemu{,-kvm} 1.2 and newer to see -device
kvm-pit,lost_tick_policy=discard appear on the command line but
didn't.
Am I missing something? Or is this command line argument not necessary
any longer?
--
Doug Goldstein
12 years, 4 months
