December 2010 - Devel - libvirt List Archives

[libvirt] [PATCH] [v3] storage: Ignore dangling symbolic link for filesystem pool
by Osier Yang 21 Dec '10

21 Dec '10

If there is a dangling symbolic link in filesystem pool, the pool will fail to start or refresh, this patch is to fix it by ignoring it with a warning log. --- src/storage/storage_backend.c | 10 +++++++++- src/storage/storage_backend_fs.c | 2 +- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index 10ea33c..f4a17a2 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -977,7 +977,8 @@ virStorageBackendForType(int type) { /* * Allows caller to silently ignore files with improper mode * - * Returns -1 on error, -2 if file mode is unexpected. + * Returns -1 on error, -2 if file mode is unexpected or the + * volume is a dangling symbolic link. */ int virStorageBackendVolOpenCheckMode(const char *path, unsigned int flags) @@ -986,6 +987,13 @@ virStorageBackendVolOpenCheckMode(const char *path, unsigned int flags) struct stat sb; if ((fd = open(path, O_RDONLY|O_NONBLOCK|O_NOCTTY)) < 0) { + if (stat(path, &sb) < 0 && + (errno == ENOENT || errno == ELOOP)) { + VIR_WARN(_("cannot open volume '%s' :%s"), path, + strerror(errno)); + return -2; + } + virReportSystemError(errno, _("cannot open volume '%s'"), path); diff --git a/src/storage/storage_backend_fs.c b/src/storage/storage_backend_fs.c index d916d2d..ff39d48 100644 --- a/src/storage/storage_backend_fs.c +++ b/src/storage/storage_backend_fs.c @@ -651,7 +651,7 @@ virStorageBackendFileSystemRefresh(virConnectPtr conn ATTRIBUTE_UNUSED, goto cleanup; else { /* Silently ignore non-regular files, - * eg '.' '..', 'lost+found' */ + * eg '.' '..', 'lost+found', dangling symbolic link */ virStorageVolDefFree(vol); vol = NULL; continue; -- 1.7.3.2

2 2

[libvirt] [PATCH 1/1] Skip file-based security checks for network disks
by Josh Durgin 21 Dec '10

21 Dec '10

Network disks are accessed by qemu directly, and have no associated file on the host, so checking for file ownership etc. is unnecessary. Signed-off-by: Josh Durgin <joshd(a)hq.newdream.net> --- src/conf/domain_conf.c | 2 +- src/qemu/qemu_security_dac.c | 2 +- src/security/security_apparmor.c | 2 +- src/security/security_selinux.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index d516fbe..c857a89 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -8353,7 +8353,7 @@ int virDomainDiskDefForeachPath(virDomainDiskDefPtr disk, size_t depth = 0; char *nextpath = NULL; - if (!disk->src) + if (!disk->src || disk->type == VIR_DOMAIN_DISK_TYPE_NETWORK) return 0; if (disk->driverType) { diff --git a/src/qemu/qemu_security_dac.c b/src/qemu/qemu_security_dac.c index 55dc0c6..88fdb8d 100644 --- a/src/qemu/qemu_security_dac.c +++ b/src/qemu/qemu_security_dac.c @@ -144,7 +144,7 @@ qemuSecurityDACRestoreSecurityImageLabelInt(virSecurityDriverPtr drv ATTRIBUTE_U if (disk->readonly || disk->shared) return 0; - if (!disk->src) + if (!disk->src || disk->type == VIR_DOMAIN_DISK_TYPE_NETWORK) return 0; /* If we have a shared FS & doing migrated, we must not diff --git a/src/security/security_apparmor.c b/src/security/security_apparmor.c index b43c4ac..468d0a3 100644 --- a/src/security/security_apparmor.c +++ b/src/security/security_apparmor.c @@ -619,7 +619,7 @@ AppArmorSetSecurityImageLabel(virSecurityDriverPtr drv, if (secdef->type == VIR_DOMAIN_SECLABEL_STATIC) return 0; - if (!disk->src) + if (!disk->src || disk->type == VIR_DOMAIN_DISK_TYPE_NETWORK) return 0; if (secdef->imagelabel) { diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index 49efa75..47da677 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -436,7 +436,7 @@ SELinuxRestoreSecurityImageLabelInt(virSecurityDriverPtr drv ATTRIBUTE_UNUSED, if (disk->readonly || disk->shared) return 0; - if (!disk->src) + if (!disk->src || disk->type == VIR_DOMAIN_DISK_TYPE_NETWORK) return 0; /* If we have a shared FS & doing migrated, we must not -- 1.7.2.3

2 1

[libvirt] Support for Parallels products?
by Justin Clift 21 Dec '10

21 Dec '10

Hi all, Has anyone looked at adding support for Parallels virtualisation products, or have any idea if it's even possible? Google isn't showing much in the way of search results, so not sure it's been looked at before. These are the server oriented products: http://www.parallels.com/au/products/server/ They have a hosted hypervisor (like VMware GSX/Server), and a bare metal hypervisor. They also have desktop oriented products: http://www.parallels.com/au/computing/

1 0

[libvirt] [PATCHv2] docs: added compiling page and significantly expanded windows page
by Justin Clift 21 Dec '10

21 Dec '10

Also added an additional menu placement for the windows page, in order to attract further potential testers. --- This version of the patch includes information on TLS certificate files, connection types, and ESX/vSphere. docs/compiling.html.in | 48 ++++++++++ docs/downloads.html.in | 41 +-------- docs/sitemap.html.in | 10 ++ docs/windows.html.in | 235 +++++++++++++++++++++++++++++++++++++++++++++--- 4 files changed, 282 insertions(+), 52 deletions(-) create mode 100644 docs/compiling.html.in diff --git a/docs/compiling.html.in b/docs/compiling.html.in new file mode 100644 index 0000000..471f52d --- /dev/null +++ b/docs/compiling.html.in @@ -0,0 +1,48 @@ +<?xml version="1.0"?> +<html> + <body> + <h1><a name="installation">libvirt Installation</a></h1> + + <ul id="toc"></ul> + + <h2><a name="Compilatio">Compiling a release tarball</a></h2> + + <p> + libvirt uses the standard configure/make/install steps: + </p> + + <pre> + gunzip -c libvirt-xxx.tar.gz | tar xvf - + cd libvirt-xxxx + ./configure --help</pre> + + <p> + To see the options, then the compilation/installation proper: + </p> + + <pre> + ./configure [possible options] + make + make install</pre> + + <p> + At that point you may have to rerun ldconfig or a similar utility to + update your list of installed shared libs. + </p> + + <h2><a name="build">Building from a GIT checkout</a></h2> + + <p> + The libvirt build process uses GNU autotools, so after obtaining a + checkout it is necessary to generate the configure script and Makefile.in + templates using the <code>autogen.sh</code> command, passing the extra + arguments as for configure. As an example, to do a complete build and + install it into your home directory run: + </p> + + <pre> + ./autogen.sh --prefix=$HOME/usr --enable-compile-warnings=error + make + make install</pre> + </body> +</html> diff --git a/docs/downloads.html.in b/docs/downloads.html.in index 709bee8..64a16c9 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -91,46 +91,9 @@ <br /> - <h1><a name="installation">libvirt Installation</a></h1> - - <h2><a name="Compilatio">Compiling a release tarball</a></h2> - - <p> - libvirt uses the standard configure/make/install steps: - </p> - - <pre> - gunzip -c libvirt-xxx.tar.gz | tar xvf - - cd libvirt-xxxx - ./configure --help</pre> - - <p> - To see the options, then the compilation/installation proper: - </p> - - <pre> - ./configure [possible options] - make - make install</pre> - <p> - At that point you may have to rerun ldconfig or a similar utility to - update your list of installed shared libs. + Once you've have obtained the libvirt source code, you can compile it + using the <a href="compiling.html">instructions here</a>. </p> - - <h2><a name="build">Building from a GIT checkout</a></h2> - - <p> - The libvirt build process uses GNU autotools, so after obtaining a - checkout it is necessary to generate the configure script and Makefile.in - templates using the <code>autogen.sh</code> command, passing the extra - arguments as for configure. As an example, to do a complete build and - install it into your home directory run: - </p> - - <pre> - ./autogen.sh --prefix=$HOME/usr --enable-compile-warnings=error - make - make install</pre> </body> </html> diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index 7db59a1..63e420f 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -21,12 +21,22 @@ <li> <a href="downloads.html">Downloads</a> <span>Get the latest source releases, binary builds and get access to the source repository</span> + <ul> + <li> + <a href="windows.html">Windows</a> + <span>Downloads for Windows</span> + </li> + </ul> </li> <li> <a href="docs.html">Documentation</a> <span>Information for users, administrators and developers</span> <ul> <li> + <a href="compiling.html">Compiling</a> + <span>How to compile libvirt</span> + </li> + <li> <a href="deployment.html">Deployment</a> <span>Information about deploying and using libvirt</span> <ul> diff --git a/docs/windows.html.in b/docs/windows.html.in index 8ca6b0d..e28595d 100644 --- a/docs/windows.html.in +++ b/docs/windows.html.in @@ -3,20 +3,233 @@ <body> <h1 >Windows support</h1> + <ul id="toc"></ul> + + <p> + Libvirt is known to work as a client (not server) on Windows XP + (32-bit), and Windows 7 (64-bit). Other Windows variants likely work + as well but we either haven't tested or received reports for them. + </p> + + <h2><a name="installer">Experimental installation package</a></h2> + + <p> + A windows installation package is in development. An experimental + version is available here: + </p> + + <a href="http://libvirt.org/sources/win32_experimental/Libvirt-0.8.6-2.exe">http://libvirt.org/sources/win32_experimental/Libvirt-0.8.6-2.exe</a> + + <p> + <b>It is not production ready.</b> + </p> + + <p> + This version includes the libvirt development headers and libraries + for compiling against, the virsh shell with its needed dependencies, + and untested Python bindings. + </p> + + <h3><a name="caveats">Caveats</h3> + + <ul> + <li> + This installer just repackages the files compiled using Matthias + Bolte's msys_setup scripting (described below). + </li> + <li> + This is a .exe installer, created using NSIS. We're looking into + something to create .msi installers as well. + </li> + <li> + The script for the NSIS installer is available online + <a href="https://github.com/justinclift/nsis_libvirt_installer">here</a>. + </li> + </ul> + + <h3><a name="knowninstallerprobs">Existing problems with this installer we know about</a> + + <p> + These are problems we know about, and need to be fixed in subsequent + versions of the installer (assistance welcomed): + </p> + + <ul> + <li> + New versions install over other libvirt versions + <br /><br /> + If a version of this installer has installed libvirt on the system + already, this installer will automatically suggest the same + installation location, then overwrite the version already there + without checking. + <br /><br /> + This is fairly non-optimal, and should be fixed. What should + probably happen, is for this installer to detect an existing + installation then offer to either uninstall it first or ask for a + new installation location. + <br /><br /> + </li> + + <li> + Start menu shortcuts aren't being removed at uninstall time + <br /><br /> + Not sure why yet. Needs to be investigated. + <br /><br /> + </li> + + <li> + Libvirt dll files should be added to path + <br /><br /> + At the moment, anything that needs to use the libvirt dll files + (ie the C# bindings) won't automatically find them. This can be + worked around by copying the dll files into the same directory as + whatever needs them, but is probably not an optimal approach. + There might be a better way and needs to be investigated. + </li> + </ul> + + <h2><a name="conntypes">Connection types</h2> + + <p> + These connection types are known to work: + </p> + + <ul> + <li>QEMU with TLS (qemu+tls://)</li> + <li>QEMU with direct TCP (qemu+tcp://)</li> + <li>VMware ESX (esx://)</li> + <li>VMware VPX (vpx://)</li> + </ul> + + <p> + These connection types are known not to work: + </p> + + <ul> + <li>QEMU with SSH (qemu+ssh://)</li> + </ul> + + <p> + All other connection types may or may not work, and haven't been + tested. + </p> + + <p> + Please let us know either the results (either way) if you do. + </p> + + <p> + <b>WARNING - The qemu+tcp:// connection type passes all traffic + without encryption. This is a security hazard, and should <i>not</i> + be used in security sensitive environments.</b> + </p> + + <h2><a name="esx">Connecting to VMware ESX/vSphere</h2> + + <p> + Details on the capabilities and connection string syntax used for + connecting to VMware ESX and vSphere can be found online here:<br /> + </p> + + <a href="http://libvirt.org/drvesx.html">http://libvirt.org/drvesx.html</a> + + <h2><a name="tlscerts">TLS Certificates</h2> + + <p> + TLS certificates are needed prior to connecting to either QEMU + instances with TLS, or connecting to VMware ESX/vSphere. + </p> + + <p> + Information on generating TLS certificates can be found here: + </p> + + <a href="http://wiki.libvirt.org/page/TLSSetup">http://wiki.libvirt.org/page/TLSSetup</a> + + <p> + These instructions are for *nix, and have not yet been adapted for + Windows. You'll need to figure out the Windows equivalents until + that's done (sorry). If you can help us out with this, that would be + really welcome. + </p> + + <p> + The locations of the TLS certificates and key file are hard coded, + rather than being configurable. + </p> + + <p> + The Certificate Authority (CA) certificate file must be placed in: + </p> + + <ul> + <li>%APPDATA%\libvirt\pki\CA\cacert.pem</li> + </ul> + <p> - Libvirt can be compiled on Windows - using the free <a href="http://www.mingw.org/">MinGW compiler</a>. - You can also cross-compile to a Windows target - from a Fedora machine using the packages available - <a href="http://hg.et.redhat.com/misc/fedora-mingw--devel/">from - the Fedora MinGW project</a> + The Client certificate file must be placed in: + </p> + + <ul> + <li>%APPDATA%\libvirt\pki\libvirt\clientcert.pem</li> + </ul> + + <p> + The Client key file must be placed in: + </p> + + <ul> + <li>%APPDATA%\libvirt\pki\libvirt\private\clientkey.pem</li> + </ul> + + <p> + On an example Windows 7 x64 system here, this resolves to these paths: + </p> + + <ul> + <li>C:\Users\someuser\AppData\Roaming\libvirt\pki\CA\cacert.pem</li> + <li>C:\Users\someuser\AppData\Roaming\libvirt\pki\libvirt\clientcert.pem</li> + <li>C:\Users\someuser\AppData\Roaming\libvirt\pki\libvirt\private\clientkey.pem</li> + </ul> + + <h2><a name="feedback">Feedback</h2> + + <p> + Feedback and suggestions on changes to make and what else to include + <a href="contact.html">are desired</a>. + </p> + + <h2><a name="compiling">Compiling yourself</a></h2> + + <p> + Libvirt can be compiled on Windows using the free + <a href="http://www.mingw.org/">MinGW compiler</a>. + </p> + + <h3><a name="msys_setup">MSYS Build script</a></h3> + + <p> + The easiest way is to use the <b>msys_setup</b> script, developed by + Matthias Bolte. This is actively developed and kept current with + libvirt releases: + </p> + + <a href="https://github.com/photron/msys_setup">https://github.com/photron/msys_setup</a> + + <h3><a name="cross-compile">Cross compiling</a></h3> + + <p> + You can also cross-compile to a Windows target from a Fedora machine + using the packages available + <a href="http://hg.et.redhat.com/misc/fedora-mingw--devel/">from the Fedora MinGW project</a> (which includes a working libvirt specfile). </p> + <h3><a name="configure">By hand</a></h3> + <p> - Libvirt can only be built as a client on Windows - allowing remote access to systems libvirt servers. - Configure libvirt like this: + Use these options when following the instructions on the + <a href="compiling.html">Compiling</a> page. </p> <pre> @@ -32,9 +245,5 @@ --without-libvirtd </pre> - <p> - We intend to supply Windows binaries on this page - later, but at the moment you have to compile from source. - </p> </body> </html> -- 1.7.3.2

2 2

[libvirt] [PATCHv2 0/7] resend: various cleanups
by Eric Blake 21 Dec '10

21 Dec '10

I've been sitting on several unreviewed cleanups. Some of them needed tweaks given recent changes in the tree, so I've rebased them and am posting them in one group to make review easier. Eric Blake (7): build: allow autoconf 2.59 again build: allow older libselinux again build: improve testsuite results with older automake tests: avoid data race tests: avoid spurious failure of nodeinfotest qemu: use virAsprintf instead of PATH_MAX build: find xdr headers on cygwin .gnulib | 2 +- configure.ac | 37 +++++++++++++++++++++++--- src/Makefile.am | 2 +- src/nodeinfo.c | 11 ++++++-- src/qemu/qemu_driver.c | 53 ++++++++++++++++++++------------------- src/security/security_selinux.c | 29 +++++++++++++++++---- tests/Makefile.am | 8 +++--- tests/commandhelper.c | 2 +- tests/nodeinfotest.c | 5 ++- 9 files changed, 100 insertions(+), 49 deletions(-) -- 1.7.3.3

3 20

[libvirt] [PATCH] xen: Prevent updating device when attaching a device
by Osier Yang 21 Dec '10

21 Dec '10

When attaching a device that already exists, xend driver updates the device with "device_configure", it causes problems (e.g. for disk device, it only can be used to update device like CDROM), and actually we provide additional API (virDomainUpdateDevice) to update device, this fix is to raise up errors instead of updating the existed device. * src/xen/xend_internal.c --- src/xen/xend_internal.c | 36 +++++++++++++++++++++++++----------- 1 files changed, 25 insertions(+), 11 deletions(-) diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c index 6ce0c3f..c71aeb3 100644 --- a/src/xen/xend_internal.c +++ b/src/xen/xend_internal.c @@ -3956,6 +3956,7 @@ xenDaemonAttachDeviceFlags(virDomainPtr domain, const char *xml, virDomainDefPtr def = NULL; virBuffer buf = VIR_BUFFER_INITIALIZER; char class[8], ref[80]; + char *target; if ((domain == NULL) || (domain->conn == NULL) || (domain->name == NULL)) { virXendError(VIR_ERR_INVALID_ARG, __FUNCTION__); @@ -4020,6 +4021,8 @@ xenDaemonAttachDeviceFlags(virDomainPtr domain, const char *xml, STREQ(def->os.type, "hvm") ? 1 : 0, priv->xendConfigVersion, 1) < 0) goto cleanup; + + target = dev->data.disk->dst; break; case VIR_DOMAIN_DEVICE_NET: @@ -4029,6 +4032,12 @@ xenDaemonAttachDeviceFlags(virDomainPtr domain, const char *xml, STREQ(def->os.type, "hvm") ? 1 : 0, priv->xendConfigVersion, 1) < 0) goto cleanup; + + if (virParseMacAddr(target, dev->data.net->mac) < 0) { + virXendError(VIR_ERR_INTERNAL_ERROR, + _("malformed mac address '%s'"), target); + goto cleanup; + } break; case VIR_DOMAIN_DEVICE_HOSTDEV: @@ -4037,13 +4046,18 @@ xenDaemonAttachDeviceFlags(virDomainPtr domain, const char *xml, if (xenDaemonFormatSxprOnePCI(dev->data.hostdev, &buf, 0) < 0) goto cleanup; - } else { - virXendError(VIR_ERR_NO_SUPPORT, "%s", - _("unsupported device type")); - goto cleanup; - } - break; + virDomainDevicePCIAddress PCIAddr; + + PCIAddr = dev->data.hostdev->source.subsys.u.pci; + virAsprintf(&target, "PCI device: %.4x:%.2x:%.2x", PCIAddr.domain, + PCIAddr.bus, PCIAddr.slot); + + if (target == NULL) { + virReportOOMError(); + goto cleanup; + } + } default: virXendError(VIR_ERR_NO_SUPPORT, "%s", _("unsupported device type")); @@ -4056,17 +4070,17 @@ xenDaemonAttachDeviceFlags(virDomainPtr domain, const char *xml, /* device doesn't exist, define it */ ret = xend_op(domain->conn, domain->name, "op", "device_create", "config", sexpr, NULL); - } - else { - /* device exists, attempt to modify it */ - ret = xend_op(domain->conn, domain->name, "op", "device_configure", - "config", sexpr, "dev", ref, NULL); + } else { + virXendError(VIR_ERR_OPERATION_INVALID, + _("target '%s' already exists"), target); } cleanup: VIR_FREE(sexpr); virDomainDefFree(def); virDomainDeviceDefFree(dev); + if (dev->type == VIR_DOMAIN_DEVICE_HOSTDEV) + VIR_FREE(target); return ret; } -- 1.7.3.2

1 0

[libvirt] [PATCH] bridge: avoid double free
by Paweł Krześniak 20 Dec '10

20 Dec '10

--- src/network/bridge_driver.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index c3f32d7..b0834ae 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -557,7 +557,6 @@ dhcpStartDhcpDaemon(virNetworkObjPtr network) cmd = virCommandNew(DNSMASQ); if (networkBuildDnsmasqArgv(network, pidfile, cmd) < 0) { - VIR_FREE(pidfile); goto cleanup; }

2 2

[libvirt] vmware, vcenter, clusterComputeResource error.
by guillaume LE LOUËT 20 Dec '10

20 Dec '10

Hello dear libvirt users. I am trying to make some migration from a VMWare esx to another. I am using ubuntu, and the last version found (my install script is http://dl.dropbox.com/u/7494462/libvirt/install.sh ) The configuration is the following: 192.168.18.5 is the first esx 172.28.2.7 is the vcenter. The vcenter has been added the esx and manages it. The DRS is activated on that vcenter. The esx is running one VM, created from the vcenter. Using libvirt, I can connect to the esx # /opt/libvirt/bin/virsh -c "esx://192.168.18.5?no_verify=1" Enter username for 192.168.18.5 [root]: Enter root's password for 192.168.18.5: Welcome to virsh, the virtualization interactive terminal. I cannot however connect to the esx, specifying to use the vcenter : # /opt/libvirt/bin/virsh -c "esx://192.168.18.5?vcenter=*&no_verify=1" Enter username for 192.168.18.5 [root]: Enter root's password for 192.168.18.5: Enter username for 172.28.2.7 [administrator]: administrateur Enter administrateur's password for 172.28.2.7: error: internal error Invalid lookup from 'ClusterComputeResource' error: failed to connect to the hypervisor I have the same error for the following commands: # /opt/libvirt/bin/virsh -c "vpx:// 172.28.2.7/Entropy-VMW/Demo/192.168.18.5?no_verify=1" # /opt/libvirt/bin/virsh -c "esx:// 192.168.18.5?vcenter=172.28.2.7&no_verify=1" I have a different error when I use bad resource names for datacenter, cluster : # /opt/libvirt/bin/virsh -c "vpx:// 172.28.2.7/badDatacenter/Demo/dsl_18.120?no_verify=1" error: internal error Could not find datacenter 'badDatacenter' # /opt/libvirt/bin/virsh -c "vpx:// 172.28.2.7/Entropy-VMW/badCluster/dsl_18.120?no_verify=1" error: internal error Could not find compute resource 'badCluster' My questions are : what am I missing ? What is a ClusterComputeResource ? Do I need to activate or configurate some tools on the vcenter ?

2 1

[libvirt] [PATCH 0/6] vbox: Add Windows support
by Matthias Bolte 20 Dec '10

20 Dec '10

This series makes the VirtualBox driver work on Windows. On non-Windows systems VirtualBox uses XPCOM, on Windows it uses MSCOM (Microsoft COM). XPCOM and MSCOM are slightly different. This series adds a new glue layer for MSCOM. The main difference is the representation of arrays. A new vboxArray type hides the differences from the general driver code. I've tested this with the 3.x series of VirtualBox. Testing with 2.x revealed that 2.x and 3.x represent IIDs differently. This problem is not fixed by this series and will need some additional work. Therefore, the VirtualBox driver only works with the 3.x series on Windows for now. VirtualBox 4.x seems to stay in line with the 3.x COM API. I expect it to work properly on Windows once we've added general support for it. Matthias

4 24

[libvirt] [PATCH] build: fix typo that broke 'make dist'
by Wen Congyang 20 Dec '10

20 Dec '10

* src/Makefile.am (VMWARE_DRIVER_SOURCES): Fix vmware_driver.h. Signed-off-by: Wen Congyang <wency(a)cn.fujitsu.com> --- src/Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 6749786..07ec528 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -255,7 +255,7 @@ OPENVZ_DRIVER_SOURCES = \ openvz/openvz_driver.c openvz/openvz_driver.h VMWARE_DRIVER_SOURCES = \ - vmware/vmware_driver.c vmware/vmware.h \ + vmware/vmware_driver.c vmware/vmware_driver.h \ vmware/vmware_conf.c vmware/vmware_conf.h VBOX_DRIVER_SOURCES = \ -- 1.7.1

3 2