Menu
▾
▴
open-vm-tools-devel — List for open-vm-tools developer discussions.
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(30) |
Oct
(50) |
Nov
(42) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(36) |
Feb
(13) |
Mar
(74) |
Apr
(17) |
May
(62) |
Jun
(53) |
Jul
(32) |
Aug
(58) |
Sep
(44) |
Oct
(21) |
Nov
(35) |
Dec
(53) |
| 2009 |
Jan
(43) |
Feb
(58) |
Mar
(14) |
Apr
(16) |
May
(61) |
Jun
(49) |
Jul
(11) |
Aug
(22) |
Sep
(37) |
Oct
(12) |
Nov
(23) |
Dec
(10) |
| 2010 |
Jan
(21) |
Feb
(13) |
Mar
(5) |
Apr
(18) |
May
(14) |
Jun
(10) |
Jul
(1) |
Aug
|
Sep
(13) |
Oct
(8) |
Nov
(11) |
Dec
(14) |
| 2011 |
Jan
(13) |
Feb
(19) |
Mar
(16) |
Apr
(10) |
May
(22) |
Jun
(4) |
Jul
(63) |
Aug
(14) |
Sep
(10) |
Oct
(12) |
Nov
(10) |
Dec
(43) |
| 2012 |
Jan
(3) |
Feb
(4) |
Mar
(35) |
Apr
(1) |
May
(32) |
Jun
(8) |
Jul
(10) |
Aug
(6) |
Sep
(3) |
Oct
(25) |
Nov
(14) |
Dec
(4) |
| 2013 |
Jan
(12) |
Feb
(6) |
Mar
(15) |
Apr
(24) |
May
(9) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
|
Oct
(8) |
Nov
(3) |
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
(4) |
Apr
(2) |
May
(4) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2015 |
Jan
|
Feb
(5) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Reindl H. <h.r...@th...> - 2011-12-08 00:15:07
|
Am 08.12.2011 01:00, schrieb Marcelo Vanzin:
> On 12/07/2011 03:26 PM, Reindl Harald wrote:
>> Dec 07 23:05:17.551: vcpu-0| Guest: [ debug] [vmsvc:vmsvc] SyncDriver:
>> ioctl failed: 16 (Das Gerät oder die Ressource ist belegt)
>
> Hmmm... Dmitry just showed me the new kernel sources and this interface seems
> to have changed since I first looked at it. Could you try to apply this patch
> and see if it helps:
>
> diff --git a/open-vm-tools/lib/syncDriver/syncDriverLinux.c
> b/open-vm-tools/lib/syncDriver/syncDriverLinux.c
> index 7dfae42..7d84f98 100644
> --- a/open-vm-tools/lib/syncDriver/syncDriverLinux.c
> +++ b/open-vm-tools/lib/syncDriver/syncDriverLinux.c
> @@ -191,9 +191,13 @@ LinuxDriver_Freeze(const char *paths,
> * supported on the device, we get EOPNOTSUPP. Ignore the latter,
> * since freezing does not make sense for all fs types, and some
> * Linux fs drivers may not have been hooked up in the running kernel.
> + *
> + * The kernel may also return EBUSY if the superblock is already
> + * frozen, which can happen if, for example, multiple mount points
> + * exist.
> */
> close(fd);
> - if (errno != EOPNOTSUPP) {
> + if (errno != EOPNOTSUPP && errno != EBUSY) {
> Debug(LGPFX "ioctl failed: %d (%s)\n", errno, strerror(errno));
> err = first ? SD_UNAVAILABLE : SD_ERROR;
> break;
rpmbuild does not like this patch, see below
my one for the fedora-version looks a little different
and was done with "diff -uNr", help appreciated
>[builduser@buildserver:/rpmbuild/SPECS]$ cat /rpmbuild/SOURCES/open-vm-tools-2.6.41.patch
>--- open-vm-tools-original/modules/linux/shared/compat_netdevice.h 2011-10-27 20:57:11.000000000 +0200
>+++ open-vm-tools-patched/modules/linux/shared/compat_netdevice.h 2011-11-23 16:57:55.814275389 +0100
>@@ -184,7 +184,7 @@
> * so let's add back ones we care about.
> */
> #if !defined(HAVE_NET_DEVICE_OPS) && \
>- LINUX_VERSION_CODE >= KERNEL_VERSION(3, 0, 0)
>+ LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 41)
> # define HAVE_NET_DEVICE_OPS 1
> #endif
_____________________
[builduser@buildserver:/rpmbuild/SPECS]$ rpmbuild -bb vmware-tools.spec
Ausführung(%prep): /bin/sh -e /var/tmp/rpm-tmp.QMx1dr
+ umask 022
+ cd /home/builduser/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /home/builduser/rpmbuild/BUILD
+ rm -rf open-vm-tools-2011.11.20-535097
+ /usr/bin/gzip -dc /home/builduser/rpmbuild/SOURCES/open-vm-tools-2011.11.20-535097.tar.gz
+ /bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd open-vm-tools-2011.11.20-535097
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'Patch #1 (open-vm-tools-2.6.41.patch):'
Patch #1 (open-vm-tools-2.6.41.patch):
+ /bin/cat /home/builduser/rpmbuild/SOURCES/open-vm-tools-2.6.41.patch
+ /usr/bin/patch -s -p1 --fuzz=0
+ echo 'Patch #2 (open-vm-tools-vsync.patch):'
Patch #2 (open-vm-tools-vsync.patch):
+ /bin/cat /home/builduser/rpmbuild/SOURCES/open-vm-tools-vsync.patch
+ /usr/bin/patch -s -p1 --fuzz=0
The text leading up to this was:
--------------------------
|diff --git a/open-vm-tools/lib/syncDriver/syncDriverLinux.c
|b/open-vm-tools/lib/syncDriver/syncDriverLinux.c
|index 7dfae42..7d84f98 100644
|--- a/open-vm-tools/lib/syncDriver/syncDriverLinux.c
|+++ b/open-vm-tools/lib/syncDriver/syncDriverLinux.c
--------------------------
File to patch:
|
|
From: Marcelo V. <mv...@vm...> - 2011-12-08 00:00:36
|
On 12/07/2011 03:26 PM, Reindl Harald wrote:
> Dec 07 23:05:17.551: vcpu-0| Guest: [ debug] [vmsvc:vmsvc] SyncDriver:
> ioctl failed: 16 (Das Gerät oder die Ressource ist belegt)
Hmmm... Dmitry just showed me the new kernel sources and this interface seems
to have changed since I first looked at it. Could you try to apply this patch
and see if it helps:
diff --git a/open-vm-tools/lib/syncDriver/syncDriverLinux.c
b/open-vm-tools/lib/syncDriver/syncDriverLinux.c
index 7dfae42..7d84f98 100644
--- a/open-vm-tools/lib/syncDriver/syncDriverLinux.c
+++ b/open-vm-tools/lib/syncDriver/syncDriverLinux.c
@@ -191,9 +191,13 @@ LinuxDriver_Freeze(const char *paths,
* supported on the device, we get EOPNOTSUPP. Ignore the latter,
* since freezing does not make sense for all fs types, and some
* Linux fs drivers may not have been hooked up in the running kernel.
+ *
+ * The kernel may also return EBUSY if the superblock is already
+ * frozen, which can happen if, for example, multiple mount points
+ * exist.
*/
close(fd);
- if (errno != EOPNOTSUPP) {
+ if (errno != EOPNOTSUPP && errno != EBUSY) {
Debug(LGPFX "ioctl failed: %d (%s)\n", errno, strerror(errno));
err = first ? SD_UNAVAILABLE : SD_ERROR;
break;
> wouldn't it be a good idea to switch this from ioctl to fsfreeze or look
> inside the guest-tools if fsfreeze is supported and use it in such cases
fsfreeze most probably just uses the same ioctl interface we're using
directly, so there wouldn't be any difference in functionality, only more
complicated code.
--
- Marcelo
|
|
From: Reindl H. <h.r...@th...> - 2011-12-07 23:26:18
|
Am 07.12.2011 23:43, schrieb Marcelo Vanzin:
> Sorry but I'll have to ask you to change the log config again, since the
> config above unfortunately doesn't enable logging for the library that
> actually does the freezing.
>
> Use this instead:
> [logging]
> log = true
> vmsvc.level = debug
> vmsvc.handler = vmx
>
>
> That will generate a few more logs than the previous settings. Feel free to
> send the new vmware.log directly to my e-mail if you think it's too large.
no problem, our VPN is working from vCenter back to my home-machine :-)
compressed log attached, contains all logs from a new start of the VM
until freeze of filesystem / online-backup failed
i think these two lines are the relevant
ioctl failed because ressource busy
Dec 07 23:05:17.551: vcpu-0| Guest: [ debug] [vmsvc:vmsvc] SyncDriver: ioctl failed: 16 (Das Gerät oder die
Ressource ist belegt)
Dec 07 23:05:17.553: vcpu-0| Guest: [ warning] [vmsvc:vmbackup] Error freezing filesystems.
____________________________
wouldn't it be a good idea to switch this from ioctl to fsfreeze or
look inside the guest-tools if fsfreeze is supported and use it in
such cases, RHEL5 is missing it, RHEL6 supports it and fedora as
many other distributions do also because they switched to recent
kernels long ago
> [root@buildserver:~]$ fsfreeze --help
> Usage: fsfreeze [options] <mount point>
>
> Options:
> -h, --help this help
> -f, --freeze freeze the filesystem
> -u, --unfreeze unfreeze the filesystem
>
> For more information see fsfreeze(8).
> [root@buildserver:~]$ fsfreeze -f /
> [root@buildserver:~]$ fsfreeze -u /
-f, --freeze
This option requests the specified a filesystem to be frozen from new modifications. When this is
selected, all ongoing transactions in the filesystem are allowed to complete, new write system
calls are halted, other calls which modify the filesystem are halted, and all dirty data, meta‐
data, and log information are written to disk. Any process attempting to write to the frozen
filesystem will block waiting for the filesystem to be unfrozen.
Note that even after freezing, the on-disk filesystem can contain information on files that are
still in the process of unlinking. These files will not be unlinked until the filesystem is
unfrozen or a clean mount of the snapshot is complete.
|
|
From: Marcelo V. <mv...@vm...> - 2011-12-07 22:43:21
|
Hi Reindl, On 12/07/2011 07:26 AM, Reindl Harald wrote: >> [logging] log = true vmbackup.level = debug vmbackup.handler = vmx >> vmvss.level = debug vmvss.handler = vmx Sorry but I'll have to ask you to change the log config again, since the config above unfortunately doesn't enable logging for the library that actually does the freezing. Use this instead: [logging] log = true vmsvc.level = debug vmsvc.handler = vmx That will generate a few more logs than the previous settings. Feel free to send the new vmware.log directly to my e-mail if you think it's too large. -- - Marcelo |
|
From: Reindl H. <h.r...@th...> - 2011-12-07 15:26:39
|
hi logoutput as requested at the end of this message hope this helps thank you! Am 05.12.2011 18:40, schrieb Dmitry Torokhov: >> Dec 3 16:24:59 master vmsvc[1183]: [ warning] [vmbackup] Error freezing >> filesystems. Dec 3 16:25:27 master vmsvc[1183]: [ warning] [vmbackup] >> Error freezing filesystems. Dec 3 16:55:38 master vmsvc[1183]: [ warning] >> [vmbackup] Error freezing filesystems. Dec 3 17:23:10 master vmsvc[1183]: >> [ warning] [vmbackup] Error freezing filesystems. Dec 3 17:53:30 master >> vmsvc[1183]: [ warning] [vmbackup] Error freezing filesystems. > > Please try enabling debug log in tools: > > [logging] > log = true > vmbackup.level = debug > vmbackup.handler = vmx > vmvss.level = debug > vmvss.handler = vmx > > Hopefully it will show what method is being used for syncing file systems and > where exactly it fails. > > Thanks, > Dmitry Dec 07 15:19:25.687: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver-flat.vmdk" : open successful (21) size = 536870912, hd = 0. Type 3 Dec 07 15:19:25.693: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver-flat.vmdk" : closed. Dec 07 15:19:25.709: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver_1-flat.vmdk" : open successful (21) size = 8589934592, hd = 0. Type 3 Dec 07 15:19:25.709: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver_1-flat.vmdk" : closed. Dec 07 15:19:25.716: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver_2-flat.vmdk" : open successful (21) size = 1073741824, hd = 0. Type 3 Dec 07 15:19:25.716: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver_2-flat.vmdk" : closed. Dec 07 15:19:25.721: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver_3-flat.vmdk" : open successful (21) size = 5368709120, hd = 0. Type 3 Dec 07 15:19:25.721: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver_3-flat.vmdk" : closed. Dec 07 15:19:25.729: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver_4-flat.vmdk" : open successful (21) size = 4294967296, hd = 0. Type 3 Dec 07 15:19:25.729: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver_4-flat.vmdk" : closed. Dec 07 15:19:25.735: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver_5-flat.vmdk" : open successful (21) size = 12884901888, hd = 0. Type 3 Dec 07 15:19:25.735: vmx| DISKLIB-VMFS : "/vmfs/volumes/4c5ff85a-c4e18c48-6b43-78e7d1e8c6aa/buildserver_1/buildserver_5-flat.vmdk" : closed. Dec 07 15:19:25.736: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] *** VmBackupStart Dec 07 15:19:25.737: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] Using quiesceApps = 1, quiesceFS = 1, allowHWProvider = 1,execScripts = 1, scriptArg = , timeout = 0 Dec 07 15:19:25.737: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] Quiescing volumes: (null) Dec 07 15:19:25.737: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] *** VmBackup_SendEvent Dec 07 15:19:25.738: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] *** VmBackupStartScripts Dec 07 15:19:25.738: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] Trying to run scripts from /etc/vmware-tools/backupScripts.d Dec 07 15:19:26.739: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] *** VmBackupAsyncCallback Dec 07 15:19:26.740: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] VmBackupAsyncCallback: checking VmBackupOnFreeze Dec 07 15:19:26.740: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] Async request 'VmBackupOnFreeze' completed Dec 07 15:19:26.740: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] *** VmBackupEnableSync Dec 07 15:19:26.740: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] *** VmBackupSyncDriverStart Dec 07 15:19:26.757: vcpu-1| Guest: [ warning] [vmsvc:vmbackup] Error freezing filesystems. Dec 07 15:19:26.758: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] *** VmBackup_SendEvent Dec 07 15:19:26.758: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] *** VmBackupStartScripts Dec 07 15:19:26.758: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] Trying to run scripts from /etc/vmware-tools/backupScripts.d Dec 07 15:19:27.760: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] *** VmBackupAsyncCallback Dec 07 15:19:27.760: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] VmBackupAsyncCallback: checking VmBackupOnFreezeFail Dec 07 15:19:27.760: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] Async request 'VmBackupOnFreezeFail' completed Dec 07 15:19:27.761: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] *** VmBackupFinalize Dec 07 15:19:27.761: vcpu-1| Guest: [ debug] [vmsvc:vmbackup] *** VmBackup_SendEvent |
|
From: Reindl H. <h.r...@th...> - 2011-12-06 16:55:31
|
Am 06.12.2011 17:53, schrieb Marcelo Vanzin: > Look at Dmitry's conf file again; it's different than yours. > >> [root@buildserver:~]$ stat /var/log/vmtools.log > > With Dmitry's config, the logs would show up in your VM's vmware.log (on the > ESX host), not anywhere inside the guest. oh - thank you, did not know this i will give it another try asap tomorrow not in the office - VMware SMB Roadshow in Vienna :-) |
|
From: Marcelo V. <mv...@vm...> - 2011-12-06 16:53:14
|
Hey Reindl, On 12/06/2011 03:21 AM, Reindl Harald wrote: > [root@buildserver:~]$ cat /etc/vmware-tools/tools.conf [logging] log = > true log.file = /var/log/vmtools.log > > [vmbackup] vmbackup.level = debug vmbackup.handler = vmx vmvss.level = > debug vmvss.handler = vmx vss.log = true Look at Dmitry's conf file again; it's different than yours. > [root@buildserver:~]$ stat /var/log/vmtools.log With Dmitry's config, the logs would show up in your VM's vmware.log (on the ESX host), not anywhere inside the guest. -- - Marcelo |
|
From: Reindl H. <h.r...@th...> - 2011-12-06 11:21:17
|
Am 05.12.2011 19:54, schrieb Dmitry Torokhov: > On Monday, December 05, 2011 07:00:04 PM Reindl Harald wrote: >> hi and thank you for your feedback >> >> Am 05.12.2011 18:40, schrieb Dmitry Torokhov: >>>> Dec 3 16:24:59 master vmsvc[1183]: [ warning] [vmbackup] Error >>>> freezing >>>> filesystems. Dec 3 16:25:27 master vmsvc[1183]: [ warning] [vmbackup] >>>> Error freezing filesystems. Dec 3 16:55:38 master vmsvc[1183]: [ >>>> warning] [vmbackup] Error freezing filesystems. Dec 3 17:23:10 >>>> master vmsvc[1183]: [ warning] [vmbackup] Error freezing filesystems. >>>> Dec 3 17:53:30 master vmsvc[1183]: [ warning] [vmbackup] Error >>>> freezing filesystems. >>> >>> Please try enabling debug log in tools: >>> >>> [logging] >>> log = true >>> vmbackup.level = debug >>> vmbackup.handler = vmx >>> vmvss.level = debug >>> vmvss.handler = vmx >>> >>> Hopefully it will show what method is being used for syncing file >>> systems and where exactly it fails. >> >> in which config-file this should happen > > /etc/vmware-tools/tools.conf does not interest the vm-tools, with or without debug-rpm and not with my changed version below nor exactly like you suggested - there is nothing more information :-( if there would be an option for the VDR to make only crash-consistent backups this would help much because i need the vdr-backups usually to restore whole machines if in the worst-case the san-storage dies the data are backuped daily with rsync offsite, vdr once each week crash-consistent works if i stop the vm-tools automatically but then you have to take care disable automatic restart of crashed virtual machines to avoid a hard reset __________________ [root@buildserver:~]$ cat /var/log/messages | grep vmb Dec 6 12:09:44 buildserver vmsvc[681]: [ warning] [vmbackup] Error freezing filesystems. [root@buildserver:~]$ cat /etc/vmware-tools/tools.conf [logging] log = true log.file = /var/log/vmtools.log [vmbackup] vmbackup.level = debug vmbackup.handler = vmx vmvss.level = debug vmvss.handler = vmx vss.log = true [root@buildserver:~]$ stat /var/log/vmtools.log Datei: „/var/log/vmtools.log“ Größe: 0 Blöcke: 0 EA Block: 4096 reguläre leere Datei Gerät: 821h/2081d Inode: 13 Verknüpfungen: 1 Zugriff: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root) [root@buildserver:~]$ cat /var/log/vmtools.log |
|
From: SourceForge.net <no...@so...> - 2011-12-06 10:04:39
|
Tracker item #3452233, was opened at 2011-12-06 02:04 Message generated for change (Tracker Item Submitted) made by xrevolver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3452233&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Igor (xrevolver) Assigned to: Nobody/Anonymous (nobody) Summary: failed co compile on RHEL 5 or CentOS 5 Initial Comment: [root@localhost open-vm-tools-8.8.1-528969]#./configure --without-x --without-dnet --without-icu [root@localhost open-vm-tools-8.8.1-528969]#make .... ... libtool: compile: gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"8.8.1\" "-DPACKAGE_STRING=\"open-vm-tools 8.8.1\"" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE_URL=\"\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"8.8.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DX_DISPLAY_MISSING=1 -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DNO_DNET=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DNO_XSM=1 -DNO_XCOMPOSITE=1 -DNO_MULTIMON=1 -I. -DVMTOOLS_USE_GLIB -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fvisibility=hidden -DGCC_EXPLICIT_EXPORT -I/root/open-vm-tools-8.8.1-528969/lib/include -I/root/open-vm-tools-8.8.1-528969/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -g -O2 -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -MT libvix_la-vixTools.lo -MD -MP -MF .deps/libvix_la-vixTools.Tpo -c vixTools.c -fPIC -DPIC -o .libs/libvix_la-vixTools.o vixTools.c: In function ‘VixToolsListFiles’: vixTools.c:5323: error: ‘GRegex’ undeclared (first use in this function) vixTools.c:5323: error: (Each undeclared identifier is reported only once vixTools.c:5323: error: for each function it appears in.) vixTools.c:5323: error: ‘regex’ undeclared (first use in this function) cc1: warnings being treated as errors vixTools.c:5376: warning: implicit declaration of function ‘g_regex_new’ vixTools.c:5445: warning: implicit declaration of function ‘g_regex_match’ make[3]: *** [libvix_la-vixTools.lo] Error 1 make[3]: Leaving directory `/root/open-vm-tools-8.8.1-528969/services/plugins/vix' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/open-vm-tools-8.8.1-528969/services/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/open-vm-tools-8.8.1-528969/services' make: *** [all-recursive] Error 1 [root@localhost open-vm-tools-8.8.1-528969]# Looks like GRegex introduced in glib2 >= 2.14 while RHEL5 and CentOS 5 use glib2 2.12 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3452233&group_id=204462 |
|
From: Dmitry T. <dt...@vm...> - 2011-12-05 18:54:45
|
On Monday, December 05, 2011 07:00:04 PM Reindl Harald wrote: > hi and thank you for your feedback > > Am 05.12.2011 18:40, schrieb Dmitry Torokhov: > >> Dec 3 16:24:59 master vmsvc[1183]: [ warning] [vmbackup] Error > >> freezing > >> filesystems. Dec 3 16:25:27 master vmsvc[1183]: [ warning] [vmbackup] > >> Error freezing filesystems. Dec 3 16:55:38 master vmsvc[1183]: [ > >> warning] [vmbackup] Error freezing filesystems. Dec 3 17:23:10 > >> master vmsvc[1183]: [ warning] [vmbackup] Error freezing filesystems. > >> Dec 3 17:53:30 master vmsvc[1183]: [ warning] [vmbackup] Error > >> freezing filesystems. > > > > Please try enabling debug log in tools: > > > > [logging] > > log = true > > vmbackup.level = debug > > vmbackup.handler = vmx > > vmvss.level = debug > > vmvss.handler = vmx > > > > Hopefully it will show what method is being used for syncing file > > systems and where exactly it fails. > > in which config-file this should happen /etc/vmware-tools/tools.conf > and is it enough to enable it or > has the debug-rpm built from rpmbuild to be installed before? I do not think so. > > this i night i have to upgrade the last 3 machines and can play > around with this after that work, couurently my weekly woruaround > would look like disable HA partially, stop vmware-tools on all guests > and start the tools an full HA after vdr-backup > > BTW: > is the "vmsync"-module really needed any longer? > i think the command/capability below exists since > some kernel versions > > [root@srv-rhsoft:~]$ which fsfreeze > /sbin/fsfreeze > [root@srv-rhsoft:~]$ /sbin/fsfreeze --help > Usage: fsfreeze [options] <mount point> > > Options: > -h, --help this help > -f, --freeze freeze the filesystem > -u, --unfreeze unfreeze the filesystem > > For more information see fsfreeze(8). We are trying to use standard FIFREEZE ioctl and fall back to our vmsync driver of FIFREEZE is not available. BTW, for production environments I'd recommend packaging 8.6.0 release, not the unstable release you are using. Thanks, Dmitry |
|
From: Reindl H. <h.r...@th...> - 2011-12-05 18:00:13
|
hi and thank you for your feedback Am 05.12.2011 18:40, schrieb Dmitry Torokhov: >> Dec 3 16:24:59 master vmsvc[1183]: [ warning] [vmbackup] Error freezing >> filesystems. Dec 3 16:25:27 master vmsvc[1183]: [ warning] [vmbackup] >> Error freezing filesystems. Dec 3 16:55:38 master vmsvc[1183]: [ warning] >> [vmbackup] Error freezing filesystems. Dec 3 17:23:10 master vmsvc[1183]: >> [ warning] [vmbackup] Error freezing filesystems. Dec 3 17:53:30 master >> vmsvc[1183]: [ warning] [vmbackup] Error freezing filesystems. > > Please try enabling debug log in tools: > > [logging] > log = true > vmbackup.level = debug > vmbackup.handler = vmx > vmvss.level = debug > vmvss.handler = vmx > > Hopefully it will show what method is being used for syncing file systems and > where exactly it fails. in which config-file this should happen and is it enough to enable it or has the debug-rpm built from rpmbuild to be installed before? this i night i have to upgrade the last 3 machines and can play around with this after that work, couurently my weekly woruaround would look like disable HA partially, stop vmware-tools on all guests and start the tools an full HA after vdr-backup BTW: is the "vmsync"-module really needed any longer? i think the command/capability below exists since some kernel versions [root@srv-rhsoft:~]$ which fsfreeze /sbin/fsfreeze [root@srv-rhsoft:~]$ /sbin/fsfreeze --help Usage: fsfreeze [options] <mount point> Options: -h, --help this help -f, --freeze freeze the filesystem -u, --unfreeze unfreeze the filesystem For more information see fsfreeze(8). |
|
From: Dmitry T. <dt...@vm...> - 2011-12-05 17:41:05
|
Hi Reindl, On Saturday, December 03, 2011 07:48:51 PM Reindl Harald wrote: > hi > > i think i need help > > below a src.rpm for Fedora 15 > http://koji.fedoraproject.org/koji/buildinfo?buildID=276240 this is > stripped down without all the gui/shared-folders-stuif and worked perfectly > some days ago > > http://access.thelounge.net/harry/open-vm-tools-0.0.0.535097-26.fc15.2011120 > 3.rh.src.rpm > > worked means: > * VDR backup successfull > * VDR probe-restore successfull > * VDR restore after destroy the guest with "rm -rf /" successfull > * VMware-HA sucessfull > > well so for me the topic upgrade to Fedora 15 was done > > yesterday i stared upgrade our build/admin-machine and the goldenmaster > all went fine, in the night from friday to saturday VMware-Data-Recovery > is scheduled for all machines - well the F15 guests failed > > Dec 3 16:24:59 master vmsvc[1183]: [ warning] [vmbackup] Error freezing > filesystems. Dec 3 16:25:27 master vmsvc[1183]: [ warning] [vmbackup] > Error freezing filesystems. Dec 3 16:55:38 master vmsvc[1183]: [ warning] > [vmbackup] Error freezing filesystems. Dec 3 17:23:10 master vmsvc[1183]: > [ warning] [vmbackup] Error freezing filesystems. Dec 3 17:53:30 master > vmsvc[1183]: [ warning] [vmbackup] Error freezing filesystems. Please try enabling debug log in tools: [logging] log = true vmbackup.level = debug vmbackup.handler = vmx vmvss.level = debug vmvss.handler = vmx Hopefully it will show what method is being used for syncing file systems and where exactly it fails. Thanks, Dmitry |
|
From: Reindl H. <h.r...@th...> - 2011-12-03 18:49:01
|
hi i think i need help below a src.rpm for Fedora 15 http://koji.fedoraproject.org/koji/buildinfo?buildID=276240 this is stripped down without all the gui/shared-folders-stuif and worked perfectly some days ago http://access.thelounge.net/harry/open-vm-tools-0.0.0.535097-26.fc15.20111203.rh.src.rpm worked means: * VDR backup successfull * VDR probe-restore successfull * VDR restore after destroy the guest with "rm -rf /" successfull * VMware-HA sucessfull well so for me the topic upgrade to Fedora 15 was done yesterday i stared upgrade our build/admin-machine and the goldenmaster all went fine, in the night from friday to saturday VMware-Data-Recovery is scheduled for all machines - well the F15 guests failed Dec 3 16:24:59 master vmsvc[1183]: [ warning] [vmbackup] Error freezing filesystems. Dec 3 16:25:27 master vmsvc[1183]: [ warning] [vmbackup] Error freezing filesystems. Dec 3 16:55:38 master vmsvc[1183]: [ warning] [vmbackup] Error freezing filesystems. Dec 3 17:23:10 master vmsvc[1183]: [ warning] [vmbackup] Error freezing filesystems. Dec 3 17:53:30 master vmsvc[1183]: [ warning] [vmbackup] Error freezing filesystems. what i really do not undertsand is why the hell this worked a few days before like a charme and now no way and there is no option in VMware-Data-Recovery to make only a crash-consistent backup (AFAIK) if they vmware-tools are not installed this is used automatically but this is no option because VMware-High-Ability needs the alive-signal of the guest hopefully anybody can figure out what here happens since F14 is EOL and i guess there are many users needing this which do not want the oversized official tools from VMware with all the useless binary-modules yes, i do not build sepearted lib(kmod-packages because it is easier and kernel-updates will first installed on the buildmachine, after a reboot the vmware-tools rebuilt for this kernel and from this point on the new kernel and modules are distributed to all other machines which have only the interal repos active -- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm |
|
From: Reindl H. <h.r...@th...> - 2011-11-28 19:21:33
|
Am 28.11.2011 19:09, schrieb Marcelo Vanzin: > On 11/24/2011 03:09 AM, Reindl Harald wrote: > If you look at the master branch a few of these issues might have been fixed > already. As our QA starts testing new distros / updates to existing distros, > we'll fix things in the development branch, and in some cases the stable > branch will pick up those changes. i took the snapshot open-vm-tools-2011.11.20-535097.tar.gz > If, as your diff suggests, Fedora is changing the LINUX_VERSION_CODE macro, > they are messing with the version number. So our checks, which are made for > the official kernel versions, would have to be adjusted for Fedora's > "unofficial version" kernels it's ok for me, this is really the only line to change i tested vmware-data-recovery (backup, probe-restore, real restore) as also HA with forced kernel crash, all fine * echo 1 > /proc/sys/kernel/sysrq * echo c > /proc/sysrq-trigger so i am satisfied with my "private" patch and glad to have provided here since others may neeed it tooo |
|
From: Marcelo V. <mv...@vm...> - 2011-11-28 18:09:18
|
On 11/24/2011 03:09 AM, Reindl Harald wrote: > why not patching the sources? That's a side-effect of how VMware adds support for newer distros. Right now I don't believe brand new distros (or recent distros that have had kernel updates) are officially supported by the current released products; that reflects in open-vm-tools, since we sync the stable branch to those stable releases. If you look at the master branch a few of these issues might have been fixed already. As our QA starts testing new distros / updates to existing distros, we'll fix things in the development branch, and in some cases the stable branch will pick up those changes. That will generally come out after some delay, since update releases have to go through our internal development and QA cycle. Sometimes, while preparing open-vm-tools updates, I'll cherry-pick a few changes from development that I consider "safe". But I'm not comfortable doing that for all types of changes. > there is nothing messing in fedora devel-kernel 2.6.40 was renamed to 3.0 > from linux so fedoras 2.6.40 is 3.0 and fedoras 2.6.41 is 3.1 If, as your diff suggests, Fedora is changing the LINUX_VERSION_CODE macro, they are messing with the version number. So our checks, which are made for the official kernel versions, would have to be adjusted for Fedora's "unofficial version" kernels. That will happen once that Fedora / kernel combination becomes officially supported by VMware, but it doesn't seem to be the case now. Until then, you may keep your private patches, or also monitor changes to the master branch looking for fixes for newer kernels that might affect your Fedora kernel. -- - Marcelo |
|
From: Reindl H. <h.r...@th...> - 2011-11-24 11:09:27
|
why not patching the sources? there is nothing messing in fedora devel-kernel 2.6.40 was renamed to 3.0 from linux so fedoras 2.6.40 is 3.0 and fedoras 2.6.41 is 3.1 and since upstream > 2.6.39 was never released this is safe the original comment above my changed line speaks about 3.1 and in the source is KERNEL_VERSION(3, 0, 0), wrong comment or bug, anyways 2.6-41 is correct for fedora [root@buildserver64:~]$ cat /rpmbuild/SOURCES/open-vm-tools-2.6.41.patch --- open-vm-tools-original/modules/linux/shared/compat_netdevice.h 2011-10-27 20:57:11.000000000 +0200 +++ open-vm-tools-patched/modules/linux/shared/compat_netdevice.h 2011-11-23 16:57:55.814275389 +0100 @@ -184,7 +184,7 @@ * so let's add back ones we care about. */ #if !defined(HAVE_NET_DEVICE_OPS) && \ - LINUX_VERSION_CODE >= KERNEL_VERSION(3, 0, 0) + LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 41) # define HAVE_NET_DEVICE_OPS 1 #endif Am 23.11.2011 19:58, schrieb Marcelo Vanzin: > Hi Reindl, > > I have an update to 8.8.x open-vm-tools that should provide a fix for that; > but it will probably need adjustments since Fedora is messing with the kernel > version numbers. > > I'm planning to post the update later today. > > On 11/23/2011 06:55 AM, Reindl Harald wrote: >> hi >> >> currently there seems to be no way to get open-vm-tools compiled with >> recent 2.6.41-kernels of Fedora 15 and rpmfusion seems to have totally >> dropped there packages -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm |
|
From: Marcelo V. <mv...@vm...> - 2011-11-23 19:27:22
|
Hi David, Got word back from the pvscsi team. They say the drivers are identical (and looking at the source history, there aren't any changes between 1.0.1.0 and 1.0.1.1 that would explain any performance difference), and perhaps the issues are related to changes in CentOS itself. Sorry I can't help more, but this is not really my area of expertise. On 11/10/2011 02:08 PM, David H wrote: > Really appreciate it Marcelo, thanks. I opened a ticket with vmware > but was just told to run esxtop to try and find storage issues; I > explained to the support tech that there is not a performance issue at > the host level since the centos 5 guests still run extremely fast. > > David > > On Thu, Nov 10, 2011 at 4:59 PM, Marcelo Vanzin <mv...@vm...> wrote: >> Hi David, >> >> I forwarded your message to the internal team that owns pvscsi. I'll re-post any >> replies they send to the list. -- - Marcelo |
|
From: Marcelo V. <mv...@vm...> - 2011-11-23 18:58:30
|
Hi Reindl, I have an update to 8.8.x open-vm-tools that should provide a fix for that; but it will probably need adjustments since Fedora is messing with the kernel version numbers. I'm planning to post the update later today. On 11/23/2011 06:55 AM, Reindl Harald wrote: > hi > > currently there seems to be no way to get open-vm-tools compiled with > recent 2.6.41-kernels of Fedora 15 and rpmfusion seems to have totally > dropped there packages -- - Marcelo |
|
From: Reindl H. <h.r...@th...> - 2011-11-23 14:56:01
|
hi
currently there seems to be no way to get open-vm-tools
compiled with recent 2.6.41-kernels of Fedora 15 and
rpmfusion seems to have totally dropped there packages
F14 support is ending this month
so in december users are forced updating to F15 which is a disaster
without vmware-tools on recent ESXi-Envirnoemnts with active HA
is there any plan to get this solved?
________________
CAUTION:
2.6.40 / 2.6.41 are the 3.0/3.1 kernels for fedora
i patched the VMware-Workstation 8.0.1 module sources and after that the
modules where compiled, the same snippet is in theopen-vm-tools source-package,
not sure if this is the only issue here, i will try to get the last version
through rpmbuild, but totally unsure how to handle the kernel-modules
[root@srv-rhsoft:/usr/lib/vmware/modules/source]$ cat vmware-2.6.41.patch
--- vmnet-only/compat_netdevice.h 2011-11-14 08:16:55.000000000 +0100
+++ vmnet-only-patched/compat_netdevice.h 2011-11-20 14:11:04.168217852 +0100
@@ -104,7 +104,7 @@
int size = sizeof *dev + priv_size;
/*
- * The name is dynamically allocated before 2.4.0, but
+ * The name is dynamically allocated before 2.4.0, but
* is an embedded array in later kernels.
*/
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 0)
@@ -161,7 +161,7 @@
# if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 0)
dev->name = (char*)(dev + 1);
# endif
- strcpy(dev->name, mask);
+ strcpy(dev->name, mask);
}
return dev;
}
@@ -183,7 +183,7 @@
* so let's add back ones we care about.
*/
#if !defined(HAVE_NET_DEVICE_OPS) && \
- LINUX_VERSION_CODE >= KERNEL_VERSION(3, 0, 0)
+ LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 41)
# define HAVE_NET_DEVICE_OPS 1
#endif
|
|
From: SourceForge.net <no...@so...> - 2011-11-22 18:19:10
|
Tracker item #3441183, was opened at 2011-11-22 10:19 Message generated for change (Tracker Item Submitted) made by martin-rosenau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3441183&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: toolbox Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Rosenau (martin-rosenau) Assigned to: Nobody/Anonymous (nobody) Summary: TFTP server for VLANCE under DOS Initial Comment: Since no VMWARE tools for DOS exist but some people run DOS as VMWARE guest OS I developed a TFTP server for the VLANCE network adapter running under DOS (intended to run in a VMWARE environment). This allows file transfer between DOS and the host OS via network. License is currently GPL v2.0. Are you interested to add this tool to your project? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3441183&group_id=204462 |
|
From: David H <isp...@gm...> - 2011-11-10 22:08:32
|
Really appreciate it Marcelo, thanks. I opened a ticket with vmware but was just told to run esxtop to try and find storage issues; I explained to the support tech that there is not a performance issue at the host level since the centos 5 guests still run extremely fast. David On Thu, Nov 10, 2011 at 4:59 PM, Marcelo Vanzin <mv...@vm...> wrote: > Hi David, > > I forwarded your message to the internal team that owns pvscsi. I'll re-post any > replies they send to the list. > |
|
From: Marcelo V. <mv...@vm...> - 2011-11-10 21:59:10
|
Hi David, I forwarded your message to the internal team that owns pvscsi. I'll re-post any replies they send to the list. On 11/10/2011 01:52 PM, David H wrote: > Hi all, hope this reaches someone who might know the more intimate > details of the pvscsi driver's development. I've been running > numerous centos 5 x86_64 installs on vmware ESXi 4.1 with EMC storage > on the back end. Since the pvscsi is not built in, I only mount /var > on a pvscsi adaptor and hard disk after installing the > vmware-open-vm-tools-kmod-8.3.2-257589.el5.x86_64 and associated > packages, and the rest of the OS on a vmware LSI SAS hard disk that it > can see during install. This package includes the pvscsi.ko version > 1.0.1.1. -- - Marcelo |
|
From: David H <isp...@gm...> - 2011-11-10 21:52:31
|
Hi all, hope this reaches someone who might know the more intimate details of the pvscsi driver's development. I've been running numerous centos 5 x86_64 installs on vmware ESXi 4.1 with EMC storage on the back end. Since the pvscsi is not built in, I only mount /var on a pvscsi adaptor and hard disk after installing the vmware-open-vm-tools-kmod-8.3.2-257589.el5.x86_64 and associated packages, and the rest of the OS on a vmware LSI SAS hard disk that it can see during install. This package includes the pvscsi.ko version 1.0.1.1. With this configuration, I typically see about 260 MB/sec write speeds, 500 MB/sec read speeds and anywhere from 7000 to 11,000 IOPS depending on the number of drives in the LUN on the EMC. With CentOS 6, it comes with vmw_pvscsi.ko module version 1.0.1.0-k which I assume is actually an older version than what the open tools install. In any case, with CentOS 6 x86_64 running on an identical configuration (same vmware host, same EMC LUN, same size vmdk file, same /var partition) I'm lucky to get 70 to 80 MB/sec write, 250 MB/sec read, 800 IOPS; so dramatically lower performance. The only difference I could find in the pvscsi mod config is that disable_msix defaults to on in 1.0.1.1 and off in 1.0.1.0-k. I did try turning it off via a boot flag, and verified it was off under /sys, but the performance was not affected; still bad. I tried to install the el5 rpm on centos 6 to get the other module working but that just produces an error "pvscsi: no symbol version for module_layout". I also tried to manually rebuild a new initrd using the pvscsi.ko file but have not been able to figure out the magic combination of files, command, etc. to get a bootable machine yet. Any ideas? Thanks, David |
|
From: SourceForge.net <no...@so...> - 2011-10-31 23:08:34
|
Tracker item #3297924, was opened at 2011-05-05 06:49 Message generated for change (Comment added) made by mvanzin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3297924&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Timo Gurr (tgurr) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong "Guest OS" information in vSphere client displayed Initial Comment: The guest is configured as "Other 2.6x Linux (64-bit)", attached screenshot (vmware-tools_stopped.png). # uname -a Linux wwwproxy 2.6.38.5 #2 SMP Wed May 4 12:33:49 CEST 2011 x86_64 Six-Core AMD Opteron(tm) Processor 2425 HE AuthenticAMD GNU/Linux After starting open-vm-tools-2011.04.25-402641 the information in vCenter changes to "Other (32-bit)", attached screenshot (vmware-tools_started.png) which is obviously wrong. VMware vSphere vCenter Client/Server is Version 4.1.0 Build 345043. ---------------------------------------------------------------------- >Comment By: Marcelo Vanzin (mvanzin) Date: 2011-10-31 16:08 Message: I'll close this as "won't fix" because (i) we consider this a bug in our UI and we have a bug tracking that internally, and (ii) there's not enough information to root cause the underlying issue in the bug. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-22 07:45 Message: Gentoo and many "Other" distros will probably show as their original configured OS. There's no point in adding every single distro out there to our UI, when only a few of them require tweaks at the hypervisor level. (I'd argue that the current list is already too long, but that's a separate discusssion.) As for the Fedora problem; unless you add some log statements to GuestInfoGather() in services/plugins/guestInfo/guestInfoServer.c (after the call to Hostinfo_GetOSName()), there's not much I can figure out from logs or anything else, because we don't log the raw data anywhere. "osName" and "osNameFull" are the strings provided to the UI to identify the OS. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-22 07:00 Message: I tried hardcoding lsb_release to return "Fedora release 8 (Werewolf)" and my image is still 32 bit. I've been looking at the code where lsb_release is called and it would seem that uname is also involved. Although command line uname appears to return very similar information as what I found online for FC 8. I sure don't see any issues with it. ---------------------------------------------------------------------- Comment By: Timo Gurr (tgurr) Date: 2011-07-22 05:02 Message: So what's the deal on Gentoo or (m)any other "Other" Linux distributions? # lsb_release -sd "Gentoo Base System release 2.0.3" Issue on the open virtual machine tools side, or time to open a vmware bug? ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 11:44 Message: I just tried with Fedora 8 (which has a very similar output of "lsb_release -sd") and the code seems to detect Fedora correctly. I'll close this as an issue with the vCenter / VI client code (they may be missing the mapping to show Fedora correctly), but I shouldn't worry much because this is mostly a cosmetic issue. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 10:56 Message: In general, the OS would be reported as "Other (32-bit)" if the code completely failed to recognize that output. The interesting bit is that we do have a check for Fedora in the code, and it should recognize that output. I'll need to try it out to see what's going on. As for what if affects, there are a couple of vCenter features that will look at that value and decide whether they'll run against the VM or not. But I think those features do not support Fedora anyway, so you should be safe. In your case it's probably just a cosmetic thing. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-20 18:21 Message: lsb_release -sd returns: "Fedora release 9 (Sulphur)" I can see where that would get me Other (32-bit). Could you give me some idea of what tools are looking for in the response to indicate 64 bit? If I have to, I'll make this return what's necessary, since it's not used by our appliance for any other purpose. Also, would there be any side-effects to just allowing this to happen? The vmx file is still set to Other (64 bit). ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-20 16:36 Message: Tools will generally use the output of "lsb_release -sd" to figure out the OS information. Fedora 9 should have that; what's the output of that command in your VM? If lsb_release is not available, then that's probably the cause. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-18 19:44 Message: I'm seeing this on Fedora 9 as well with open-vm-tools-2011.06.27-437995. Anything I can provide to assist? vSphere 4.1.0 Build 260247 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3297924&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2011-10-31 22:57:04
|
Tracker item #3424368, was opened at 2011-10-16 05:06 Message generated for change (Settings changed) made by mvanzin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3424368&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: guestd Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Lukas Ruf (lukas_ruf) Assigned to: Nobody/Anonymous (nobody) Summary: Cut&Paste fails with latest VMware Workstation Initial Comment: After upgrading to latest VMware Workstation Cut&Paste does not work anymore. Host: unchanged (Win7e, 64b) Guest: unchanged (Debian Linux, openvm-tools stable) Config: unchanged VMware: workstation changed from 7.1 to latest If there is any workaround, please let me know. Thanks Lukas ---------------------------------------------------------------------- >Comment By: Marcelo Vanzin (mvanzin) Date: 2011-10-31 15:57 Message: I think it's clear so far that this is an issue with the Debian packages, so I'll set this to pending. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-10-17 10:38 Message: This is looking like a Debian package issue from chip's comments. Also, you should run "vmware-user-suid-wrapper" instead of running "vmtoolsd -n vmusr" directly, or drap & drop won't work. ---------------------------------------------------------------------- Comment By: Chip Salzenberg (chip) Date: 2011-10-16 21:32 Message: I meant, I upgraded my vmware *tools* installation to 8.8.0 inside the guest OS. My vmware host was not upgraded, and is not an issue. I don't know if 7.x vmware tools have the same issues, I haven't tried it. ---------------------------------------------------------------------- Comment By: Lukas Ruf (lukas_ruf) Date: 2011-10-16 15:12 Message: Chip, thanks for your reply. Does this work with older VMware installations too? Or do I run into backward compatibility problems with VMware v7? Thanks Lukas ---------------------------------------------------------------------- Comment By: Chip Salzenberg (chip) Date: 2011-10-16 14:42 Message: I've got it working with 8.8.0 and a little debian packaging fu. The trick is to observe that vmware-user is still present, but hidden inside another program. Run "/usr/bin/vmtoolsd -n vmusr" instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3424368&group_id=204462 |
58 messages has been excluded from this view by a project administrator.
