- Devel - libvirt List Archives

[libvirt] [PATCH] qemu: Add network bandwidth settings for ethernet type interfaces
by Anirban Chakraborty 01 Sep '14

01 Sep '14

Please apply. thanks, Anirban Chakraborty Signed-off-by: Anirban Chakraborty <abchak(a)juniper.net> --- src/qemu/qemu_command.c | 5 +++++ src/qemu/qemu_hotplug.c | 3 +++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 2184caa..258c6a7 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -7251,6 +7251,11 @@ qemuBuildInterfaceCommandLine(virCommandPtr cmd, if (tapfd[0] < 0) goto cleanup; } + /* Configure network bandwidth for ethernet type network interfaces */ + if (actualType == VIR_DOMAIN_NET_TYPE_ETHERNET) + if (virNetDevBandwidthSet(net->ifname, + virDomainNetGetActualBandwidth(net), false) < 0) + goto cleanup; if ((actualType == VIR_DOMAIN_NET_TYPE_NETWORK || actualType == VIR_DOMAIN_NET_TYPE_BRIDGE || diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index a364c52..aeb53c5 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -940,6 +940,9 @@ int qemuDomainAttachNetDevice(virConnectPtr conn, if (qemuOpenVhostNet(vm->def, net, priv->qemuCaps, vhostfd, &vhostfdSize) < 0) goto cleanup; } else if (actualType == VIR_DOMAIN_NET_TYPE_ETHERNET) { + if (virNetDevBandwidthSet(net->ifname, + virDomainNetGetActualBandwidth(net), false) < 0) + goto cleanup; vhostfdSize = 1; if (VIR_ALLOC(vhostfd) < 0) goto cleanup; -- 1.8.2.3

1 0

[libvirt] Cosmetic bug on libvirt.org
by Christophe Fergeau 29 Aug '14

29 Aug '14

Hey, I just noticed that clicking on "FAQ" in the left sidebar on libvirt.org main page highlights the "Wiki" cell instead of highlighting "FAQ". I have no idea how the website works, so I'm just reporting it here. Cheers, Christophe

2 1

[libvirt] [PATCH 1.2.8] storage: zfs: fix double listing of new volumes
by Roman Bogorodskiy 29 Aug '14

29 Aug '14

Currently, after calling commands to create a new volumes, virStorageBackendZFSCreateVol calls virStorageBackendZFSFindVols that calls virStorageBackendZFSParseVol. virStorageBackendZFSParseVol checks if a volume already exists by trying to get it using virStorageVolDefFindByName. For a just created volume it returns NULL, so volume is reported as new and appended to pool->volumes. This causes a volume to be listed twice as storageVolCreateXML appends this new volume to the list as well. Fix that by passing a new volume definition to virStorageBackendZFSParseVol so it could determine if it needs to add this volume to the list. --- src/storage/storage_backend_zfs.c | 45 ++++++++++++++++++++++----------------- 1 file changed, 26 insertions(+), 19 deletions(-) diff --git a/src/storage/storage_backend_zfs.c b/src/storage/storage_backend_zfs.c index 2d74055..d8201ac 100644 --- a/src/storage/storage_backend_zfs.c +++ b/src/storage/storage_backend_zfs.c @@ -58,7 +58,8 @@ virStorageBackendZFSCheckPool(virConnectPtr conn ATTRIBUTE_UNUSED, static int virStorageBackendZFSParseVol(virStoragePoolObjPtr pool, - const char *volume) + virStorageVolDefPtr vol, + const char *volume_string) { int ret = -1; char **tokens; @@ -66,9 +67,9 @@ virStorageBackendZFSParseVol(virStoragePoolObjPtr pool, char **name_tokens = NULL; char *vol_name; bool is_new_vol = false; - virStorageVolDefPtr vol = NULL; + virStorageVolDefPtr volume = NULL; - if (!(tokens = virStringSplitCount(volume, "\t", 0, &count))) + if (!(tokens = virStringSplitCount(volume_string, "\t", 0, &count))) return -1; if (count != 2) @@ -79,36 +80,41 @@ virStorageBackendZFSParseVol(virStoragePoolObjPtr pool, vol_name = name_tokens[1]; - vol = virStorageVolDefFindByName(pool, vol_name); + if (vol == NULL) + volume = virStorageVolDefFindByName(pool, vol_name); + else + volume = vol; - if (vol == NULL) { - if (VIR_ALLOC(vol) < 0) + if (volume == NULL) { + if (VIR_ALLOC(volume) < 0) goto cleanup; is_new_vol = true; - vol->type = VIR_STORAGE_VOL_BLOCK; + volume->type = VIR_STORAGE_VOL_BLOCK; - if (VIR_STRDUP(vol->name, vol_name) < 0) + if (VIR_STRDUP(volume->name, vol_name) < 0) goto cleanup; } - if (!vol->key && VIR_STRDUP(vol->key, tokens[0]) < 0) + if (!volume->key && VIR_STRDUP(volume->key, tokens[0]) < 0) goto cleanup; - if (vol->target.path == NULL) { - if (virAsprintf(&vol->target.path, "%s/%s", - pool->def->target.path, vol->name) < 0) + if (volume->target.path == NULL) { + if (virAsprintf(&volume->target.path, "%s/%s", + pool->def->target.path, volume->name) < 0) goto cleanup; } - if (virStrToLong_ull(tokens[1], NULL, 10, &vol->target.capacity) < 0) { + if (virStrToLong_ull(tokens[1], NULL, 10, &volume->target.capacity) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("malformed volsize reported")); goto cleanup; } if (is_new_vol && - VIR_APPEND_ELEMENT(pool->volumes.objs, pool->volumes.count, vol) < 0) + VIR_APPEND_ELEMENT(pool->volumes.objs, + pool->volumes.count, + volume) < 0) goto cleanup; ret = 0; @@ -116,12 +122,13 @@ virStorageBackendZFSParseVol(virStoragePoolObjPtr pool, virStringFreeList(tokens); virStringFreeList(name_tokens); if (is_new_vol && (ret == -1)) - virStorageVolDefFree(vol); + virStorageVolDefFree(volume); return ret; } static int -virStorageBackendZFSFindVols(virStoragePoolObjPtr pool) +virStorageBackendZFSFindVols(virStoragePoolObjPtr pool, + virStorageVolDefPtr vol) { virCommandPtr cmd = NULL; char *volumes_list = NULL; @@ -157,7 +164,7 @@ virStorageBackendZFSFindVols(virStoragePoolObjPtr pool) if (STREQ(lines[i], "")) continue; - if (virStorageBackendZFSParseVol(pool, lines[i]) < 0) + if (virStorageBackendZFSParseVol(pool, vol, lines[i]) < 0) continue; } @@ -233,7 +240,7 @@ virStorageBackendZFSRefreshPool(virConnectPtr conn ATTRIBUTE_UNUSED, } /* Obtain a list of volumes */ - if (virStorageBackendZFSFindVols(pool) < 0) + if (virStorageBackendZFSFindVols(pool, NULL) < 0) goto cleanup; cleanup: @@ -285,7 +292,7 @@ virStorageBackendZFSCreateVol(virConnectPtr conn ATTRIBUTE_UNUSED, if (virCommandRun(cmd, NULL) < 0) goto cleanup; - if (virStorageBackendZFSFindVols(pool) < 0) + if (virStorageBackendZFSFindVols(pool, vol) < 0) goto cleanup; ret = 0; -- 2.0.2

2 2

Re: [libvirt] [Qemu-devel] IO accounting overhaul
by Stefan Hajnoczi 29 Aug '14

29 Aug '14

On Thu, Aug 28, 2014 at 04:38:09PM +0200, Benoît Canet wrote: > I collected some items of a cloud provider wishlist regarding I/O accouting. > > In a cloud I/O accouting can have 3 purpose: billing, helping the customers > and doing metrology to help the cloud provider seeks hidden costs. > > I'll cover the two former topic in this mail because they are the most important > business wize. > > 1) prefered place to collect billing IO accounting data: > -------------------------------------------------------- > For billing purpose the collected data must be as close as possible to what the > customer would see by using iostats in his vm. > > The first conclusion we can draw is that the choice of collecting IO accouting > data used for billing in the block devices models is right. I agree. When statistics are collected at lower layers it becomes are for the end user to understand numbers that include hidden costs for image formats, network protocols, etc. > 2) what to do with occurences of rare events: > --------------------------------------------- > > Another point is that QEMU developpers agree that they don't know which policy > to apply to some I/O accounting events. > Must QEMU discard invalid I/O write IO or account them as done ? > Must QEMU count a failed read I/O as done ? > > When discusting this with a cloud provider the following appears: these decisions > are really specific to each cloud provider and QEMU should not implement them. > The right thing to do is to add accouting counters to collect these events. > > Moreover these rare events are precious troubleshooting data so it's an additional > reason not to toss them. Sounds good, network interface statistics also include error counters. > 3) list of block I/O accouting metrics wished for billing and helping the customers > ----------------------------------------------------------------------------------- > > Basic I/O accouting data will end up making the customers bills. > Extra I/O accouting informations would be a precious help for the cloud provider > to implement a monitoring panel like Amazon Cloudwatch. One thing to be aware of is that counters inside QEMU cannot be trusted. If a malicious guest can overwrite memory in QEMU then the counters can be manipulated. For most purposes this should be okay. Just be aware that evil guests could manipulate their counters if a security hole is found in QEMU. > Here is the list of counters and statitics I would like to help implement in QEMU. > > This is the most important part of the mail and the one I would like the community > review the most. > > Once this list is settled I would proceed to implement the required infrastructure > in QEMU before using it in the device models. > > /* volume of data transfered by the IOs */ > read_bytes > write_bytes > > /* operation count */ > read_ios > write_ios > flush_ios > > /* how many invalid IOs the guest submit */ > invalid_read_ios > invalid_write_ios > invalid_flush_ios > > /* how many io error happened */ > read_ios_error > write_ios_error > flush_ios_error > > /* account the time passed doing IOs */ > total_read_time > total_write_time > total_flush_time > > /* since when the volume is iddle */ > qvolume_iddleness_time ? > > /* the following would compute latecies for slices of 1 seconds then toss the > * result and start a new slice. A weighted sumation of the instant latencies > * could help to implement this. > */ > 1s_read_average_latency > 1s_write_average_latency > 1s_flush_average_latency > > /* the former three numbers could be used to further compute a 1 minute slice value */ > 1m_read_average_latency > 1m_write_average_latency > 1m_flush_average_latency > > /* the former three numbers could be used to further compute a 1 hours slice value */ > 1h_read_average_latency > 1h_write_average_latency > 1h_flush_average_latency > > /* 1 second average number of requests in flight */ > 1s_read_queue_depth > 1s_write_queue_depth > > /* 1 minute average number of requests in flight */ > 1m_read_queue_depth > 1m_write_queue_depth > > /* 1 hours average number of requests in flight */ > 1h_read_queue_depth > 1h_write_queue_depth I think libvirt captures similar data. At least virt-manager displays graphs with similar data (maybe for CPU, memory, or network instead of disk). > 4) Making this happen > ------------------------- > > Outscale want to make these IO stat happen and gave me the go to do whatever > grunt is required to do so. > That said we could collaborate on some part of the work. Seems like a nice improvement to the query-blockstats available today. CCing libvirt for management stack ideas. Stefan

2 1

[libvirt] [PATCH 0/2] Couple more Coverity issues
by John Ferlan 29 Aug '14

29 Aug '14

After perusing the pile of 70 or so warnings - these two stuck out as ones that were low hanging fruit and not false positives. Many of the remaining "issues" are false positives or perhaps even bugs in Coverity, but I understand why they're being flagged. Freeing memory from counted lists where the incoming count must be zero based on code path - for some reason Coverity flags them because the incoming list memory is NULL and the for loop deref would be bad. The issue is Coverity doesn't seem to dig deep enough to determine that the count and list pointer are linked, sigh (yes, a lot of those). John Ferlan (2): virnetserverservice: Resolve Coverity ARRAY_VS_SINGLETON qemu_driver: Resolve Coverity FORWARD_NULL src/qemu/qemu_driver.c | 3 +-- src/rpc/virnetserverservice.c | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) -- 1.9.3

2 7

[libvirt] [PATCH v2 0/4] Introduce support for virtio-blk-pci iothreads
by John Ferlan 28 Aug '14

28 Aug '14

v1: http://www.redhat.com/archives/libvir-list/2014-August/msg01155.html Changes since v1 Patches 1-3 - purely from code review Patch 4 - rework the checking of the to be added disk that has the iothread property set to be done during qemuBuildDriveDevStr() after the config check. This way the same checks are done for both start and hotplug. Only set the "inuse" bit after qemuBuildDriveDevStr() returns successfully for both start and hotplug. This also enforces only setting for this path Since the only way a disk with the property can be added is if the current emulator supports the feature, the calls to set/clear the bit if iothread is set should be safe from not needing to also ensure iothreadmap exists. John Ferlan (4): domain_conf: Introduce iothreads XML qemu: Add support for iothreads domain_conf: Add support for iothreads in disk definition qemu: Allow use of iothreads for disk definitions docs/formatdomain.html.in | 34 ++++++++++++ docs/schemas/domaincommon.rng | 14 +++++ src/conf/domain_conf.c | 47 +++++++++++++++- src/conf/domain_conf.h | 4 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 64 ++++++++++++++++++++++ src/qemu/qemu_hotplug.c | 6 ++ .../qemuxml2argv-iothreads-disk.args | 17 ++++++ .../qemuxml2argv-iothreads-disk.xml | 40 ++++++++++++++ tests/qemuxml2argvdata/qemuxml2argv-iothreads.args | 8 +++ tests/qemuxml2argvdata/qemuxml2argv-iothreads.xml | 29 ++++++++++ tests/qemuxml2argvtest.c | 4 ++ tests/qemuxml2xmltest.c | 2 + 14 files changed, 271 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-iothreads-disk.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-iothreads-disk.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-iothreads.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-iothreads.xml -- 1.9.3

3 16

[libvirt] [PATCH v2 0/2] network: Bring netdevs online later
by Matthew Rosato 28 Aug '14

28 Aug '14

The following patchset introduces code to defer setting netdevs online (and therefore registering MACs) until right before beginning guest CPU execution. The first patch introduces some infrastructure changes in preparation of the actual function added in the 2nd patch. Associated BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1081461 Changes for v2: * Ping for comments, esp. on patch #2. * Moved @flags operand of virNetDevMacVLanCreateWithVPortProfile to the end of the operand list. * Minor changes based on comments by Martin Kletzander. * Added detail to patch #2 commit message. * Martin suggested that I replace various ? operations with if/else statements, but I ended up leaving them alone as they were being used to conditionally assign values to constant fields. * I left the contents of qemu_interface as-is, rather than collapsing them into non-qemu-specific functions, in order to keep Makefile linkage consistent & happy (needs to be part of QEMU_DRIVER_SOURCES). Instead, incorporated copyright suggestions from previous comments. Martin, if you feel strongly about not having these new functions in a qemu-specific part, feel free to comment. Changes since RFC: * Add a separate patch to introduce a flags field for macvlan/macvtap creation. * Use macvlan/tap IFUP flags to skip virNetDevSetOnline (for qemu only). * Add hotplug support. * For macvlan, save the current virNetDevVPortProfileOp in virDomainNetDef during qemuPhysIfaceConnect. As Laine mentioned, could use this field in a future patch to eliminate passing virNetDevVPortProfileOp everywhere. * Add qemu_interface.c and qemu_interface.h to encapsulate new functions. Matthew Rosato (2): util: Introduce flags field for macvtap creation network: Bring netdevs online later src/Makefile.am | 3 +- src/conf/domain_conf.h | 2 ++ src/lxc/lxc_process.c | 6 ++-- src/qemu/qemu_command.c | 12 +++++-- src/qemu/qemu_hotplug.c | 7 ++++ src/qemu/qemu_interface.c | 78 +++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_interface.h | 32 ++++++++++++++++++ src/qemu/qemu_process.c | 4 +++ src/util/virnetdevmacvlan.c | 36 ++++++++++++-------- src/util/virnetdevmacvlan.h | 16 ++++++--- 10 files changed, 172 insertions(+), 24 deletions(-) create mode 100644 src/qemu/qemu_interface.c create mode 100644 src/qemu/qemu_interface.h -- 1.7.9.5

2 6

[libvirt] [PATCH 00/19] More Coverity patches
by John Ferlan 28 Aug '14

28 Aug '14

I almost didn't want to do this due to the sheer volume, but figured at the very least the bulk of these are resource leaks found by the much pickier new coverity scanner. After this there are "only" 70 issues found... John Ferlan (19): libxl_migration: Resolve Coverity NULL_RETURNS daemon: Resolve Coverity NEGATIVE_RETURNS domain_conf: Resolve Coverity RESOURCE_LEAK cpu_x86: Resolve Coverity RESOURCE_LEAK qemu_command: Resolve Coverity RESOURCE_LEAK qemu_agent: Resolve Coverity RESOURCE_LEAK libxl_domain: Resolve Coverity RESOURCE_LEAK qemu_capabilities: Resolve Coverity RESOURCE_LEAK network_conf: Resolve Coverity RESOURCE_LEAK virsh-network: Resolve Coverity RESOURCE_LEAK bridge_driver: Resolve Coverity RESOURCE_LEAK libxl_migration: Resolve Coverity RESOURCE_LEAK phyp_driver: Resolve Coverity RESOURCE_LEAK qemu_driver: Resolve Coverity RESOURCE_LEAK storage_conf: Resolve Coverity RESOURCE_LEAK qemu_monitor: Resolve Coverity NESTING_INDENT_MISMATCH domain_conf: Resolve Coverity DEADCODE qemu_driver: Resolve Coverity DEADCODE qemu_command: Resolve Coverity DEADCODE daemon/remote.c | 24 ++++++++++++------------ src/conf/domain_conf.c | 28 ++++++++++++++++++++++++---- src/conf/network_conf.c | 2 ++ src/conf/storage_conf.c | 2 ++ src/cpu/cpu_x86.c | 15 ++++++++++----- src/libxl/libxl_domain.c | 4 +++- src/libxl/libxl_migration.c | 11 +++++++++-- src/network/bridge_driver.c | 1 + src/phyp/phyp_driver.c | 1 + src/qemu/qemu_agent.c | 6 ++++-- src/qemu/qemu_capabilities.c | 2 +- src/qemu/qemu_command.c | 9 +++++---- src/qemu/qemu_driver.c | 8 ++++++++ src/qemu/qemu_monitor.c | 3 ++- tools/virsh-network.c | 2 +- 15 files changed, 85 insertions(+), 33 deletions(-) -- 1.9.3

4 31

[libvirt] Automatically affinitize hostdev interrupts to vm vCpus (qemu/kvm)
by Mooney, Sean K 28 Aug '14

28 Aug '14

Hi I would like to ask for comments and propose a possible new libvirt feature. Problem statement: At present when you boot a vm via libvirt it is possible to pin vm vCPUs to host CPUs to improve performance in the guest under certain conditions. If hostdev interrupts are not pined to a specific core/cpuset suboptimal processing of irqs may occur reducing the performance of both guest and host. I would like to propose extending libvirt to automatically pin interrupts for hostdev devices if they are present in the guest. By affinitizing interrupts, cache line sharing between the specified interrupt and guest can be achieved. If CPU affinity for the guest, as set by the cpuset parameter, is intelligently chosen to place the guest on the same numa node as the hostdev, cross socket traffic can be mitigated. As a result, latency which would be introduce if the interrupt processing was scheduled to a non-local numa node CPU can be reduced via interrupt pinning. Proposed change: * util/virpci and util/virhostdev will be extended to retrieve IRQ and msi_interupt information from sysfs. * util/virinterupt will be created * util/virinterupt will implement managing interrupt affinity via /proc/irq/x/smp_affinity * qemuProcessInitCpuAffinity will be extended to conditionally affinitize hostdev interrupts to vm vCpus when hostdevs are present in the vm definition. Alternative implementation: In addition to the above changes the hostdev element could be extended to include a cpuset attribute: * if the cpuset is auto: the interrupts would be pinned to the same cpuset as the vms vCPU * if a cpuset is specified: the interrupts would be affinitized as per the set cpuset * if the cpuset is native: the interrupts will not be pinned and the current behaviour will not be changed. * If the cpuset attribute is not present either the behaviour of auto or native could be used as a default. o Using auto as the default would allow transparent use of the feature. o Using native as the default would allow no changes to any existing deployments unless the feature is requested. Any feedback is welcomed. Regards Sean. -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 2

[libvirt] Proposition for the implementation of new features for Hyper-V driver
by Adrien Kantcheff 28 Aug '14

28 Aug '14

Dear libvirt developers, During my final student training in the French company Bull, with a previous student (Simon RASTELLO), we developed new features for Hyper-V driver. For a project called OpenCloudware, our work was to bring new functionalities using libvirt API in order to do basic actions on virtual machines hosted on Hyper-V. You may be interested in pushing our developments in the official release. The libvirt driver already provides functions to enumerate and get WMI classes by sending WQL requests to WMI provider and also to call WMI class methods. For that last kind of communication, a method requires input parameters. There are two kinds of argument: basic (integer, string...) and complex (objects, end point references, embedded instances). Actually, just the first argument passing mode is available with libvirt driver. But the second one is very useful because there is many WMI methods with complex types parameters, and for the moment it constraints developers to call WMI methods only with basic types parameters. So in order to expand WMI methods calls, we have implemented the second argument passing mode. Thanks to this new argument passing mode, we are available to set new functionalities. Our contributions include: * hyperv_driver.c o hypervDomainDefineXML o hypervDomainCreateXML o hypervDomainUndefine o hypervDomainUndefineFlags o hypervDomainShutdown o hypervDomainShutdownFlags o hypervDomainGetVcpus o hypervDomainGetVcpusFlags o hypervConnectGetMaxVcpus o hypervDomainGetMaxVcpus o hypervDomainSetVcpus o hypervDomainSetVcpusFlags o hypervDomainSetMemory o hypervDomainSetMemoryFlags o hypervDomainSetMaxMemory o hypervNodeGetFreeMemory o hypervDomainAttachDevice o hypervDomainAttachDeviceFlags o hypervDomainGetSchedulerParameters o hypervDomainGetSchedulerParametersFlags o hypervDomainGetSchedulerType o hypervConnectGetCapabilities o hypervConnectGetVersion o hypervDomainSetAutostart o hypervDomainGetAutostart * hyperv_network.c o hypervConnectNumOfNetworks o hypervConnectListNetworks o hypervConnectNumOfDefinedNetworks o hypervConnectListDefinedNetworks o hypervNetworkLookupByName o hypervNetworkGetXMLDesc * hyperv_storage_driver.c o hypervConnectNumOfStoragePools (stub) o hypervConnectListStoragePools (stub) o hypervConnectNumOfDefinedStoragePools (stub) o hypervStoragePoolLookupByName (stub) o hypervStorageVolLookupByPath (stub) * hyperv_private.h o Add mutex to protect against concurrent calls o Add virDomainXMLOptionPtr to parse Domain XML * hyperv_wmi.h o Structures for complex arguments: objects, EPR (end point references) and embedded instances * hyperv_wmi.c o Methods to invoke WMI methods with complex arguments * hyperv_wmi_generator.input o CIM_DataFile o Win32_ComputerSystemProduct o Msvm_VirtualSystemManagementService o Msvm_VirtualSystemGlobalSettingData o Msvm_ResourceAllocationSettingData o Msvm_AllocationCapabilities o Msvm_VirtualSwitch o Msvm_SwitchPort o Msvm_SyntheticEthernetPortSettingData o Msvm_VirtualSwitchManagementService o Win32_OperatingSystem o Win32_PerfFormattedData_HvStats_HyperVHypervisorVirtualProcessor o Win32_PerfRawData_HvStats_HyperVHypervisorVirtualProcessor * hyperv_wmi_generator.py o Add CIM_DataFile class header to be generated o Add tab classes and types to be generated o Add a function to print header types * openwsman.h o Add ws_xml_create_doc signature o Add xml_parser_get_root signature Attach files contain sources and an pdf of our contributions. I'm ending my training this week but I'm available to answer any questions you may have. You can use my personal email: adrien.kantcheff(a)gmail.com<mailto:adrien.kantcheff@gmail.com> I also put in copy of this email my tutors Yves VINTER and Christian BOURGEOIS. Feel free to contact them as well. Best regards, Adrien KANTCHEFF Bull

2 1