April 2015 - Devel - libvirt List Archives

[libvirt] [PATCH 0/2] rework the check for the numa cpus
by Luyao Huang 21 Apr '15

21 Apr '15

We introduce a check for numa cpu total count in 5f7b71, But seems this check cannot work well. There are some scenarioes: 1. one of cpu id is out of maxvcpus, can set success(cpu count = 5 < 10): <vcpu placement='static'>10</vcpu> <cell id='0' cpus='0-3,100' memory='512000' unit='KiB'/> the cpus '100' exceed maxvcpus, this setting is not valid (although qemu do not output error). 2. use the same cpu in 2 cell, can set success(cpu count = 8 < 10): <vcpu placement='static'>10</vcpu> <cell id='0' cpus='0-3' memory='512000' unit='KiB'/> <cell id='1' cpus='0-3' memory='512000' unit='KiB'/> I guess nobody will use this setting if he really want use numa in his vm. (qemu not output error, but we can find some interesting things in vm, all cpus have bind in one numa node) 3. use the same cpu in 2 cell, cannot set success(cpu count = 11 > 10): <vcpu placement='static'>10</vcpu> <cell id='0' cpus='0-6' memory='512000' unit='KiB'/> <cell id='1' cpus='0-3' memory='512000' unit='KiB'/> No need forbid this scenario if scenario 2 is a 'valid' setting. However add new check during parse xml will make vm has broken settings disappear after update libvirtd, so possible solutions: 1. add new check when parse xml, and find a way to avoid vm evaporate. I chose this way and i don't think just drop the invalid settings is a good idea for numa cpus, so i add a new function. 2. add new check when start vm. I think this is a configuration issue, so no need report it so late. 3. just remove this check and do not add new check... :) Luyao Huang (2): conf: introduce a new function to add check avoid losing track conf: rework the cpu check for vm numa settings src/bhyve/bhyve_driver.c | 4 ++-- src/conf/domain_conf.c | 21 ++++++++++++++------- src/conf/domain_conf.h | 1 + src/conf/numa_conf.c | 37 ++++++++++++++++++++++++++++++------- src/conf/numa_conf.h | 2 +- src/esx/esx_driver.c | 2 +- src/libxl/libxl_driver.c | 4 ++-- src/lxc/lxc_driver.c | 4 ++-- src/openvz/openvz_driver.c | 4 ++-- src/parallels/parallels_driver.c | 2 +- src/phyp/phyp_driver.c | 2 +- src/qemu/qemu_driver.c | 4 ++-- src/test/test_driver.c | 4 ++-- src/uml/uml_driver.c | 4 ++-- src/vbox/vbox_common.c | 2 +- src/vmware/vmware_driver.c | 4 ++-- src/xen/xen_driver.c | 4 ++-- src/xenapi/xenapi_driver.c | 4 ++-- 18 files changed, 70 insertions(+), 39 deletions(-) -- 1.8.3.1

3 4

[libvirt] [PATCH] lxc: fix 2 issue around cpuset
by Luyao Huang 21 Apr '15

21 Apr '15

There are two bugs in this function: 1. cannot start a vm with cpuset but without numatune settings # virsh -c lxc:/// start helloworld error: Failed to start domain helloworld error: internal error: guest failed to start: Invalid value '1-3' for 'cpuset.mems': Invalid argument we don't free &mask after use it for virCgroupSetCpusetCpus() and then virDomainNumatuneMaybeFormatNodeset() do not get a new &mask, then we use it in virCgroupSetCpusetMems(). 2. when start a lxc with numatune memory mode not strict # virsh -c lxc:/// start helloworld error: Failed to start domain helloworld error: internal error: guest failed to start: Unknown failure in libvirt_lxc startup We shouldn't set anything in cpuset.mems for these mode. Signed-off-by: Luyao Huang <lhuang(a)redhat.com> --- src/lxc/lxc_cgroup.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/lxc/lxc_cgroup.c b/src/lxc/lxc_cgroup.c index c1813e2..5e959a2 100644 --- a/src/lxc/lxc_cgroup.c +++ b/src/lxc/lxc_cgroup.c @@ -77,11 +77,15 @@ static int virLXCCgroupSetupCpusetTune(virDomainDefPtr def, if (virCgroupSetCpusetCpus(cgroup, mask) < 0) goto cleanup; + /* free mask to make sure we won't use it in a wrong way later */ + VIR_FREE(mask); } if (virDomainNumatuneGetMode(def->numa, -1) != - VIR_DOMAIN_NUMATUNE_MEM_STRICT) + VIR_DOMAIN_NUMATUNE_MEM_STRICT) { + ret = 0; goto cleanup; + } if (virDomainNumatuneMaybeFormatNodeset(def->numa, nodemask, &mask, -1) < 0) -- 1.8.3.1

3 2

[libvirt] [PATCH] qemu: set macvtap physdevs online when macvtap is set online
by Laine Stump 20 Apr '15

20 Apr '15

A further fix for: https://bugzilla.redhat.com/show_bug.cgi?id=1113474 Since there is no possibility that any type of macvtap will work if the parent physdev it's attached to is offline, we should bring the physdev online at the same time as the macvtap. When taking the macvtap offline, it's also necessary to take the physdev offline for macvtap passthrough mode (because the physdev has the same MAC address as the macvtap device, so could potentially cause problems with misdirected packets during migration, as outlined in commits 829770 and 879c13). We can't set the physdev offline for other macvtap modes 1) because there may be other macvtap devices attached to the same physdev in the other modes whereas passthrough mode is exclusive to one macvtap at a time, and 2) there's no practical reason to do so anyway. --- src/qemu/qemu_hotplug.c | 8 +++----- src/qemu/qemu_interface.c | 29 +++++++++++++++++++++++++++-- 2 files changed, 30 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 2f0549e..9be2ea3 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -3931,11 +3931,9 @@ qemuDomainDetachNetDevice(virQEMUDriverPtr driver, VIR_WARN("cannot clear bandwidth setting for device : %s", detach->ifname); - /* deactivate the tap/macvtap device on the host (currently this - * isn't necessary, as everything done in - * qemuInterfaceStopDevice() is made meaningless when the device - * is deleted anyway, but in the future it may be important, and - * doesn't hurt anything for now) + /* deactivate the tap/macvtap device on the host, which could also + * affect the parent device (e.g. macvtap passthrough mode sets + * the parent device offline) */ ignore_value(qemuInterfaceStopDevice(detach)); diff --git a/src/qemu/qemu_interface.c b/src/qemu/qemu_interface.c index 201a7dd..01226ac 100644 --- a/src/qemu/qemu_interface.c +++ b/src/qemu/qemu_interface.c @@ -63,7 +63,20 @@ qemuInterfaceStartDevice(virDomainNetDefPtr net) goto cleanup; } break; - case VIR_DOMAIN_NET_TYPE_DIRECT: + + case VIR_DOMAIN_NET_TYPE_DIRECT: { + const char *physdev = virDomainNetGetActualDirectDev(net); + bool isOnline = true; + + /* set the physdev online if necessary. It may already be up, + * in which case we shouldn't re-up it just in case that causes + * some sort of "blip" in the physdev's status. + */ + if (physdev && virNetDevGetOnline(physdev, &isOnline) < 0) + goto cleanup; + if (!isOnline && virNetDevSetOnline(physdev, true) < 0) + goto cleanup; + /* macvtap devices share their MAC address with the guest * domain, and if they are set online prior to the domain CPUs * being started, the host may send out traffic from this @@ -79,6 +92,7 @@ qemuInterfaceStartDevice(virDomainNetDefPtr net) if (virNetDevSetOnline(net->ifname, true) < 0) goto cleanup; break; + } case VIR_DOMAIN_NET_TYPE_USER: case VIR_DOMAIN_NET_TYPE_ETHERNET: @@ -146,7 +160,9 @@ qemuInterfaceStopDevice(virDomainNetDefPtr net) } break; - case VIR_DOMAIN_NET_TYPE_DIRECT: + case VIR_DOMAIN_NET_TYPE_DIRECT: { + const char *physdev = virDomainNetGetActualDirectDev(net); + /* macvtap interfaces need to be marked !IFF_UP (ie "down") to * prevent any host-generated traffic sent from this interface * from putting bad info into the arp caches of other machines @@ -154,7 +170,16 @@ qemuInterfaceStopDevice(virDomainNetDefPtr net) */ if (virNetDevSetOnline(net->ifname, false) < 0) goto cleanup; + + /* also mark the physdev down for passthrough macvtap, as the + * physdev has the same MAC address as the macvtap device. + */ + if (virDomainNetGetActualDirectMode(net) == + VIR_NETDEV_MACVLAN_MODE_PASSTHRU && + physdev && virNetDevSetOnline(physdev, false) < 0) + goto cleanup; break; + } case VIR_DOMAIN_NET_TYPE_USER: case VIR_DOMAIN_NET_TYPE_ETHERNET: -- 2.1.0

2 3

[libvirt] [PATCH 0/7] QoS: Adapt to changing MAC
by Michal Privoznik 20 Apr '15

20 Apr '15

While we taught libvirt to listen to MAC address changes from guests we forgot to update our QoS hierarchy accordingly. The first 3 patches are pure bug fixes and can go in regardless of state of the rest. The 4th patch is a slight improvement as it makes filter priority predictable. Then, patches 5-7 actually fix the bug. Michal Privoznik (7): virNetDevBandwidthPlug: Update function description RNG schema: allow plain @floor to <bandwidth/> virDomainActualNetDefContentsFormat: Format class_id more frequently virNetDevBandwidthSet: Add priority to filter virnetdevbandwidth.c: Separate tc filter creation to a function Introduce virNetDevBandwidthUpdateFilter processNicRxFilterChangedEvent: Take appropriate actions for NET_TYPE_NETWORK too docs/schemas/networkcommon.rng | 8 +- src/conf/domain_conf.c | 3 +- src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 22 +++ src/util/virnetdevbandwidth.c | 186 ++++++++++++++++----- src/util/virnetdevbandwidth.h | 6 + .../qemuxml2argv-net-bandwidth2.xml | 65 +++++++ tests/qemuxml2xmltest.c | 1 + tests/virnetdevbandwidthtest.c | 4 +- 9 files changed, 250 insertions(+), 46 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-bandwidth2.xml -- 2.0.5

2 17

[libvirt] [PATCH] parallels: make device addressing consistent
by Nikolay Shirokovskiy 20 Apr '15

20 Apr '15

In Parallels we do not support device name hints aka <target dev=../> option and full-fledged device disk device addressing through <address type=.. controller=.. bus=.. target=.. unit=../> and have only one index instead. In this situation to be consistent we can only take one-to-one mapping from some reasonable subset of full address. Values outside this subset are invalid to create Parallels VMs. Reasonable mapping is default one defined in virDomainDiskDefAssignAddress. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)parallels.com> --- src/parallels/parallels_sdk.c | 72 ++++++++++++++++++++++++++++++++++------ 1 files changed, 61 insertions(+), 11 deletions(-) diff --git a/src/parallels/parallels_sdk.c b/src/parallels/parallels_sdk.c index d199898..80e9d00 100644 --- a/src/parallels/parallels_sdk.c +++ b/src/parallels/parallels_sdk.c @@ -462,7 +462,7 @@ prlsdkGetDiskInfo(PRL_HANDLE prldisk, PRL_UINT32 emulatedType; PRL_UINT32 ifType; PRL_UINT32 pos; - PRL_UINT32 prldiskIndex; + virDomainDeviceDriveAddressPtr address; int ret = -1; pret = PrlVmDev_GetEmulatedType(prldisk, &emulatedType); @@ -499,15 +499,32 @@ prlsdkGetDiskInfo(PRL_HANDLE prldisk, pret = PrlVmDev_GetIfaceType(prldisk, &ifType); prlsdkCheckRetGoto(pret, cleanup); + + pret = PrlVmDev_GetStackIndex(prldisk, &pos); + prlsdkCheckRetGoto(pret, cleanup); + + address = &disk->info.addr.drive; switch (ifType) { case PMS_IDE_DEVICE: disk->bus = VIR_DOMAIN_DISK_BUS_IDE; + disk->dst = virIndexToDiskName(pos, "hd"); + address->bus = pos / 2; + address->target = 0; + address->unit = pos % 2; break; case PMS_SCSI_DEVICE: disk->bus = VIR_DOMAIN_DISK_BUS_SCSI; + disk->dst = virIndexToDiskName(pos, "sd"); + address->bus = 0; + address->target = 0; + address->unit = pos; break; case PMS_SATA_DEVICE: disk->bus = VIR_DOMAIN_DISK_BUS_SATA; + disk->dst = virIndexToDiskName(pos, "sd"); + address->bus = 0; + address->target = 0; + address->unit = pos; break; default: virReportError(VIR_ERR_INTERNAL_ERROR, @@ -516,17 +533,10 @@ prlsdkGetDiskInfo(PRL_HANDLE prldisk, break; } - pret = PrlVmDev_GetStackIndex(prldisk, &pos); - prlsdkCheckRetGoto(pret, cleanup); + if (!disk->dst) + goto cleanup; disk->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE; - disk->info.addr.drive.target = pos; - - pret = PrlVmDev_GetIndex(prldisk, &prldiskIndex); - prlsdkCheckRetGoto(pret, cleanup); - - if (!(disk->dst = virIndexToDiskName(prldiskIndex, "sd"))) - goto cleanup; ret = 0; @@ -2852,6 +2862,7 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool bootD virDomainDeviceDriveAddressPtr drive; PRL_UINT32 devIndex; PRL_DEVICE_TYPE devType; + char *dst = NULL; if (prlsdkCheckDiskUnsupportedParams(disk) < 0) return -1; @@ -2909,22 +2920,50 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool bootD /* We have only one controller of each type */ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive " "address of disk %s, Parallels Cloud Server has " - "only one controller."), disk->src->path); + "only one controller."), disk->dst); + goto cleanup; + } + + if (drive->target > 0) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive " + "address of disk %s, Parallels Cloud Server has " + "only target 0."), disk->dst); goto cleanup; } switch (disk->bus) { case VIR_DOMAIN_DISK_BUS_IDE: + if (drive->unit > 1) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive " + "address of disk %s, Parallels Cloud Server has " + "only units 0-1 for IDE bus."), disk->dst); + goto cleanup; + } sdkbus = PMS_IDE_DEVICE; idx = 2 * drive->bus + drive->unit; + dst = virIndexToDiskName(idx, "hd"); break; case VIR_DOMAIN_DISK_BUS_SCSI: + if (drive->bus > 0) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive " + "address of disk %s, Parallels Cloud Server has " + "only bus 0 for SCSI bus."), disk->dst); + goto cleanup; + } sdkbus = PMS_SCSI_DEVICE; idx = drive->unit; + dst = virIndexToDiskName(idx, "sd"); break; case VIR_DOMAIN_DISK_BUS_SATA: + if (drive->bus > 0) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive " + "address of disk %s, Parallels Cloud Server has " + "only bus 0 for SATA bus."), disk->dst); + goto cleanup; + } sdkbus = PMS_SATA_DEVICE; idx = drive->unit; + dst = virIndexToDiskName(idx, "sd"); break; default: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", @@ -2933,6 +2972,16 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool bootD goto cleanup; } + if (!dst) + goto cleanup; + + if (STRNEQ(dst, disk->dst)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive " + "address of disk %s, Parallels Cloud Server supports " + "only defaults address to logical device name."), disk->dst); + goto cleanup; + } + pret = PrlVmDev_SetIfaceType(sdkdisk, sdkbus); prlsdkCheckRetGoto(pret, cleanup); @@ -2968,6 +3017,7 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool bootD return 0; cleanup: PrlHandle_Free(sdkdisk); + VIR_FREE(dst); return ret; } -- 1.7.1

2 1

[libvirt] [PATCH] parallels: fix return status for parallelsConnectOpen
by Nikolay Shirokovskiy 20 Apr '15

20 Apr '15

We should return VIR_DRV_OPEN_ERROR in case if we handle scheme in query but some error occur. Previously we sometimes return VIR_DRV_OPEN_DECLINE. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)parallels.com> --- src/parallels/parallels_network.c | 2 +- src/parallels/parallels_storage.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/parallels/parallels_network.c b/src/parallels/parallels_network.c index 47f4886..42ef836 100644 --- a/src/parallels/parallels_network.c +++ b/src/parallels/parallels_network.c @@ -349,7 +349,7 @@ parallelsNetworkOpen(virConnectPtr conn, error: virObjectUnref(privconn->networks); privconn->networks = NULL; - return VIR_DRV_OPEN_DECLINED; + return VIR_DRV_OPEN_ERROR; } int parallelsNetworkClose(virConnectPtr conn) diff --git a/src/parallels/parallels_storage.c b/src/parallels/parallels_storage.c index 6397601..4091124 100644 --- a/src/parallels/parallels_storage.c +++ b/src/parallels/parallels_storage.c @@ -494,7 +494,7 @@ parallelsStorageOpen(virConnectPtr conn, error: parallelsStorageUnlock(storageState); parallelsStorageClose(conn); - return -1; + return VIR_DRV_OPEN_ERROR; } static int -- 1.7.1

2 1

[libvirt] [PATCH v2] parallels: use SDK disks system names for paths
by Nikolay Shirokovskiy 20 Apr '15

20 Apr '15

For block devices SDK friendly name do not refer to block device path but rather some description while system name refer to device path. For ploop devices both names refer to image path. Thus system name is better choice. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)parallels.com> --- src/parallels/parallels_sdk.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/parallels/parallels_sdk.c b/src/parallels/parallels_sdk.c index 72c1773..e1ba7cf 100644 --- a/src/parallels/parallels_sdk.c +++ b/src/parallels/parallels_sdk.c @@ -485,13 +485,13 @@ prlsdkGetDiskInfo(PRL_HANDLE prldisk, disk->device = VIR_DOMAIN_DISK_DEVICE_DISK; } - pret = PrlVmDev_GetFriendlyName(prldisk, NULL, &buflen); + pret = PrlVmDev_GetSysName(prldisk, NULL, &buflen); prlsdkCheckRetGoto(pret, cleanup); if (VIR_ALLOC_N(buf, buflen) < 0) goto cleanup; - pret = PrlVmDev_GetFriendlyName(prldisk, buf, &buflen); + pret = PrlVmDev_GetSysName(prldisk, buf, &buflen); prlsdkCheckRetGoto(pret, cleanup); if (virDomainDiskSetSource(disk, buf) < 0) -- 1.7.1

2 1

[libvirt] [PATCH] domtop: Properly free cpu status
by Michal Privoznik 20 Apr '15

20 Apr '15

So, in the example the cpu stats are collected within a function called do_top. At the beginning of the function we ask the daemon for how much vCPUs can we get stats, and how many stats for a vCPU can we get. This is because it's how our API works - users are required to preallocate a chunk of memory for the results. Now, at the end, we try to free the allocated array, but we are not doing it correctly. There's this virTypedParamsFree() function which gets a pointer to the array and the length of the array. However, if there was an error in getting vCPU stats we pass a negative number instead of the originally computed value. This flaw results in SIGSEGV: libvirt: QEMU Driver error : Requested operation is not valid: domain is not running ERROR do_top:333 : Unable to get cpu stats ==29201== Invalid read of size 4 ==29201== at 0x4F1DF8B: virTypedParamsClear (virtypedparam.c:1145) ==29201== by 0x4F1DFEB: virTypedParamsFree (virtypedparam.c:1165) ==29201== by 0x4023C3: do_top (domtop.c:349) ==29201== by 0x40260B: main (domtop.c:386) ==29201== Address 0x131cd7c0 is 16 bytes after a block of size 768 alloc'd ==29201== at 0x4C2C070: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==29201== by 0x401FF1: do_top (domtop.c:295) ==29201== by 0x40260B: main (domtop.c:386) Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- examples/domtop/domtop.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/examples/domtop/domtop.c b/examples/domtop/domtop.c index e50988e..2283994 100644 --- a/examples/domtop/domtop.c +++ b/examples/domtop/domtop.c @@ -346,8 +346,8 @@ do_top(virConnectPtr conn, ret = 0; cleanup: - virTypedParamsFree(now_params, now_nparams * max_id); - virTypedParamsFree(then_params, then_nparams * max_id); + virTypedParamsFree(now_params, nparams * max_id); + virTypedParamsFree(then_params, nparams * max_id); if (dom) virDomainFree(dom); return ret; -- 2.0.5

2 1

[libvirt] [PATCH 0/5] Add vmport feature (v3)
by Marc-André Lureau 20 Apr '15

20 Apr '15

Hi, The QEMU machine vmport option allows to set the VMWare IO port emulation. This emulation is useful for absolute pointer input when the guest has vmware input drivers, and is enabled by default for kvm. However it is unnecessary for Spice-enabled VM, since the agent already handles absolute pointer and multi-monitors. Furthermore, it prevents Spice from switching to relative input since the regular ps/2 pointer driver is replaced by the vmware driver. It is thus advised to disable vmport when using a Spice VM. This will permit the Spice client to switch from absolute to relative pointer, as it may be required for certain games or applications. The following patch series allows to configure the vmport feature. The first version sent used a domain attribute, Daniel Berrange suggested to use a feature instead. I sent a second version that didn't receive reviews. Hopefully this one will stand more chances! cheers Marc-André Lureau (5): docs: add domain vmport feature domain/conf: add VIR_DOMAIN_FEATURE_VMPORT qemu: add QEMU_CAPS_MACHINE_VMPORT_OPT qemu: add machine vmport argument tests: add machine-vmport-opt qemu test docs/formatdomain.html.in | 6 +++++ docs/schemas/domaincommon.rng | 9 +++++++ src/conf/domain_conf.c | 5 +++- src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 6 +++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 14 +++++++++++ .../qemuxml2argv-machine-vmport-opt.args | 6 +++++ .../qemuxml2argv-machine-vmport-opt.xml | 28 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 2 ++ 10 files changed, 77 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-vmport-opt.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-vmport-opt.xml -- 2.1.0

4 19

[libvirt] Building libvirt under Windows
by Pavel Fedin 20 Apr '15

20 Apr '15

Hello! I am currently building libvirt under Windows64, and i would like to ask for correct way to do it. The first thing to resolve is absence of RPC XDR library. From configure source i figured out that portablexdr library may help. I have downloaded it, but it comes with a different RPC code generator named portable-rpcgen. I managed to use it, but i had to patch both libvirt (in order to recognize this generator and handle it properly) and portable-rpcgen (in order to correctly work under Windows, as well as get rid of some crashes). Initially i wanted to upstream portablexdr fixes and emailed the author. But the author replied that he is not going to fix portablexdr because it's now deprecated, since original XDR code comes under free license now. So, i have all necessary fixes in my own fork. He suggested me to come here to ask about these things. So, guys, how do you do it ? I cannot find any rpcgen package usable under Windows (MinGW, not Cygwin). Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia

2 2