January 2013 - Devel - libvirt List Archives

[libvirt] [PATCHv2 0/7] Add additional data for the NUMA topology info
by Peter Krempa 29 Jan '13

29 Jan '13

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

4 20

[libvirt] [PATCH] auto-create pci-bridge controller info
by liguang 29 Jan '13

29 Jan '13

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

4 5

[libvirt] [Libvirt][Test]How to test storage solely in Libvirt?
by harryxiyou 28 Jan '13

28 Jan '13

Hi all, I wanna test if a storage driver (like Sheepdog) works well in Libvirt separately. How should i finish this job. Could anyone give me some suggestions? -- Thanks Harry Wei

4 7

[libvirt] [RFC PATCH 0/n] Glue domain and storage
by Osier Yang 28 Jan '13

28 Jan '13

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

4 19

[libvirt] [Libvirt][Sheepdog]How to test Sheepdog patch
by harryxiyou 28 Jan '13

28 Jan '13

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=036ad5052b43fe9f0d197e… 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

2 2

[libvirt] [Sheepdog][Libvirt]How should i test sheepdog in libvirt
by harryxiyou 27 Jan '13

27 Jan '13

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=036ad5052b43fe9f0d197e…) 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

2 7

[libvirt] [Libvirt][QEMU]The relationships between Libvirt and QEMU indetails
by harryxiyou 27 Jan '13

27 Jan '13

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_1… 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

1 0

[libvirt] [PATCH] virlog: remove old code comment
by Doug Goldstein 27 Jan '13

27 Jan '13

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

2 1

[libvirt] [PATCH 0/7] Introduce virCommandDoAsyncIO
by Michal Privoznik 27 Jan '13

27 Jan '13

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

2 15

[libvirt] qemu kvm-pit device arg missing?
by Doug Goldstein 27 Jan '13

27 Jan '13

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

1 0