Menu
▾
▴
open-vm-tools-devel
|
From: Jim <jim...@ho...> - 2011-02-08 19:32:08
|
Hi, I am using open-vm-tools 8.4.2 stable release but my linux other 2.6.x guest will not clone due to failure of a reported pre-freeze script returning non zero. Similar error to report in Tracker-3107225. I have also tried with 2010.12.19-339835 release which is working but I would prefer to only stay with stable releases for a "production" environment. Some time ago I was also testing a monthly release (exact one unknown) and cloning with those was also failing with those so I switched to the stable release. Cloning was working for a period with the stable code but I think that changed after moving the vmtoolsd start to a later point in the boot process. Can someone explain the data flow from starting the clone operation in the vSphere client through to the VM processing the request? How is a snapshot different from the clone operation when it comes to quiescing operation? I think the clone operation starts with a snapshot to get a stable/quiesced disk prior to cloning. So what's different that snapshot works but clone does not? I am comfortable examining code but I'm not sure where to start looking. Grepping/cscope has only led me to the vmbackup stateMachine which has anything related to quiescing. Is the vmbackup plugin required for cloning? Any pointers appreciated. Thanks. Jim |
|
From: Marcelo V. <mv...@vm...> - 2011-02-09 01:07:43
|
On 02/08/2011 11:33 AM, Jim wrote: > I am using open-vm-tools 8.4.2 stable release but my linux other 2.6.x guest > will not clone due to failure of a reported pre-freeze script returning > non zero. > Similar error to report in Tracker-3107225. First, a disclaimer: the 8.4.2 release is a stable release, but was only tested with Workstation and Fusion; so not all features that are used by ESX (such as quiescing) are necessarily stable in that release. I know, this is kinda non-optimal, but it's something we're trying to fix internally, and when we get there it will trickle down to open-vm-tools naturally. With that out of the way... For ESX releases up to 4.1, quiescing for non-Windows VMs is quite simple; it just tries to run a script in the guest (the "freeze" script, normally /usr/sbin/pre-freeze-script), and after the snapshot is taken, tries to run another script (the "thaw" script, normally /usr/sbin/post-thaw-script). On Linux, if the vmsync driver is loaded, it will try to use it; but since that driver hasn't really received that much testing (despite its age...), if you have it loaded I'd recommend you unload it. Since that code hasn't really changed in a while, I believe it should work. So I suggest you check the two paths mentioned above, make sure they exist and are executable, and are not returning a non-zero value. If that doesn't help, I'd need logs from your VM to know exactly what's going on when you try to clone (which creates a quiesced snapshot as part of cloning). Let me know if you need instructions on how to set up logging. -- - Marcelo |
|
From: James Ko <jim...@ho...> - 2011-02-09 19:25:04
|
Hi Marcelo, I've added the scripts, made it +x and confirmed they exit 0 but it did not help. No debug logs (vmtoolsd nor vmsvc) on the guest indicate any requests from the host. The vmware.logs for this guest shows and Unknown Command for VIX. Feb 09 11:30:50.627: vmx| DISKLIB-VMFS : "/vmfs/volumes/2eba8c1e-3d2a3850/VM1/VM1-flat.vmdk" : open successful (21) size = 4294967296, hd = 0. Type 3 Feb 09 11:30:50.629: vmx| DISKLIB-VMFS : "/vmfs/volumes/2eba8c1e-3d2a3850/VM1/VM1-flat.vmdk" : closed. Feb 09 11:30:50.635: vmx| DISKLIB-VMFS : "/vmfs/volumes/2eba8c1e-3d2a3850/VM1/VM1_1-flat.vmdk" : open successful (21) size = 536870912000, hd = 0. Type 3 Feb 09 11:30:50.636: vmx| DISKLIB-VMFS : "/vmfs/volumes/2eba8c1e-3d2a3850/VM1/VM1_1-flat.vmdk" : closed. Feb 09 11:30:51.603: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue for guestUserName=hostd-quiescedsnap Feb 09 11:30:51.603: vmx| VMAutomation: VMAutomation_ReadGuestOperationPolicies fails. hostPolicyString is NULL. Feb 09 11:30:51.603: vmx| VMAutomation: VixAutomation_IsGuestOperationAllowed fails. No policy for this operation. Feb 09 11:30:51.603: vmx| VMAutomation: VixAutomation_IsGuestOperationAllowed returns result=0 Feb 09 11:30:51.603: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue checking global refcount Feb 09 11:30:51.604: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue featureRefCount=1. Feb 09 11:30:51.604: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue loading dictionary /vmfs/volumes/2eba8c1e-3d2a3850/VM1/VM1.vmx Feb 09 11:30:51.605: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue reading secret at guest.commands.sharedSecretLogin.hostd-quiescedsnap Feb 09 11:30:51.605: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue found shared secret value Ofj7tz1Pcf+WDsZzgU+A0soxFzn1QLPkATsXOGuP/Gk= Feb 09 11:30:51.605: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue for guestUserName=hostd-quiescedsnap Feb 09 11:30:51.606: vmx| VMAutomation: VMAutomation_ReadGuestOperationPolicies fails. hostPolicyString is NULL. Feb 09 11:30:51.606: vmx| VMAutomation: VixAutomation_IsGuestOperationAllowed fails. No policy for this operation. Feb 09 11:30:51.606: vmx| VMAutomation: VixAutomation_IsGuestOperationAllowed returns result=0 Feb 09 11:30:51.606: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue checking global refcount Feb 09 11:30:51.606: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue featureRefCount=1. Feb 09 11:30:51.606: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue loading dictionary /vmfs/volumes/2eba8c1e-3d2a3850/VM1/VM1.vmx Feb 09 11:30:51.607: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue reading secret at guest.commands.sharedSecretLogin.hostd-quiescedsnap Feb 09 11:30:51.607: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue found shared secret value Ofj7tz1Pcf+WDsZzgU+A0soxFzn1QLPkATsXOGuP/Gk= Feb 09 11:30:51.618: vcpu-1| Vix: [48586254 guestCommands.c:2488]: Error VIX_E_UNRECOGNIZED_COMMAND_IN_GUEST in VMAutomationTranslateGuestRpcError(): Tools failed to recognize guest command op code=4, result string="Unknown Command". Feb 09 11:30:51.619: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue for guestUserName=hostd-quiescedsnap Feb 09 11:30:51.619: vmx| VMAutomation: VMAutomation_ReadGuestOperationPolicies fails. hostPolicyString is NULL. Feb 09 11:30:51.619: vmx| VMAutomation: VixAutomation_IsGuestOperationAllowed fails. No policy for this operation. Feb 09 11:30:51.619: vmx| VMAutomation: VixAutomation_IsGuestOperationAllowed returns result=0 Feb 09 11:30:51.619: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue checking global refcount Feb 09 11:30:51.619: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue featureRefCount=1. Feb 09 11:30:51.619: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue loading dictionary /vmfs/volumes/2eba8c1e-3d2a3850/VM1/VM1.vmx Feb 09 11:30:51.620: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue reading secret at guest.commands.sharedSecretLogin.hostd-quiescedsnap Feb 09 11:30:51.620: vmx| VMAutomation: VMAutomation_CheckSharedSecretValue found shared secret value Ofj7tz1Pcf+WDsZzgU+A0soxFzn1QLPkATsXOGuP/Gk= Feb 09 11:30:51.628: vcpu-1| Vix: [48586254 guestCommands.c:2488]: Error VIX_E_UNRECOGNIZED_COMMAND_IN_GUEST in VMAutomationTranslateGuestRpcError(): Tools failed to recognize guest command op code=87, result string="Unknown Command". I restarted vmware tools and see this in the logs at startup Feb 09 11:52:01.172: vcpu-1| TOOLS completing request from tools to set option 'synctime' -> '0' Feb 09 11:52:01.174: vcpu-1| VMXVmdb_LoadRawConfig: Loading raw config Feb 09 11:52:01.234: vcpu-1| GuestRpc: Reinitializing Channel 0(toolbox) Feb 09 11:52:01.234: vcpu-1| GuestRpc: Channel 0 reinitialized. Feb 09 11:52:21.544: vcpu-1| GuestRpc: application toolbox already registered, id: -1 Feb 09 11:52:21.544: vcpu-1| GuestRpc: Channel 0, guest application toolbox. Feb 09 11:52:21.544: vcpu-1| Vix: [48586254 guestCommands.c:2488]: Error VIX_E_UNRECOGNIZED_COMMAND_IN_GUEST in VMAutomationTranslateGuestRpcError(): Tools failed to recognize guest command op code=62, result string="Unknown Command". Feb 09 11:52:21.545: vcpu-1| TOOLS ToolsCapabilityGuestConfDirectory received /etc/vmware-tools Feb 09 11:52:21.545: vcpu-1| ToolsSetVersionWork did nothing; new tools version (2147483647) matches old Tools version Feb 09 11:52:21.545: vcpu-1| Vix: [48586254 guestCommands.c:2488]: Error VIX_E_UNRECOGNIZED_COMMAND_IN_GUEST in VMAutomationTranslateGuestRpcError(): Tools failed to recognize guest command op code=62, result string="Unknown Command". Feb 09 11:52:21.545: vcpu-1| Vix: [48586254 guestCommands.c:2488]: Error VIX_E_UNRECOGNIZED_COMMAND_IN_GUEST in VMAutomationTranslateGuestRpcError(): Tools failed to recognize guest command op code=62, result string="Unknown Command". Feb 09 11:52:21.545: vcpu-1| Vix: [48586254 guestCommands.c:2488]: Error VIX_E_UNRECOGNIZED_COMMAND_IN_GUEST in VMAutomationTranslateGuestRpcError(): Tools failed to recognize guest command op code=62, result string="Unknown Command". Feb 09 11:52:21.545: vcpu-1| TOOLS unified loop capability requested by 'toolbox'; now sending options via TCLO Feb 09 11:52:21.545: vcpu-1| Guest: toolbox: Version: build-261024 Feb 09 11:52:21.566: vcpu-0| TOOLS completing request from tools to set option 'synctime' -> '1' Feb 09 11:52:21.566: vcpu-0| VMXVmdb_LoadRawConfig: Loading raw config Is VIX really required for quiescing? I would actually prefer to have VIX disabled as I see it as a potential security risk for the guest. James > Date: Tue, 8 Feb 2011 17:05:53 -0800 > From: mv...@vm... > To: ope...@li... > CC: jim...@ho... > Subject: Re: cloning and pre-freeze script question > > On 02/08/2011 11:33 AM, Jim wrote: > > I am using open-vm-tools 8.4.2 stable release but my linux other 2.6.x guest > > will not clone due to failure of a reported pre-freeze script returning > > non zero. > > Similar error to report in Tracker-3107225. > > First, a disclaimer: the 8.4.2 release is a stable release, but was only tested > with Workstation and Fusion; so not all features that are used by ESX (such as > quiescing) are necessarily stable in that release. > > I know, this is kinda non-optimal, but it's something we're trying to fix > internally, and when we get there it will trickle down to open-vm-tools naturally. > > With that out of the way... > > For ESX releases up to 4.1, quiescing for non-Windows VMs is quite simple; it > just tries to run a script in the guest (the "freeze" script, normally > /usr/sbin/pre-freeze-script), and after the snapshot is taken, tries to run > another script (the "thaw" script, normally /usr/sbin/post-thaw-script). > > On Linux, if the vmsync driver is loaded, it will try to use it; but since that > driver hasn't really received that much testing (despite its age...), if you > have it loaded I'd recommend you unload it. > > Since that code hasn't really changed in a while, I believe it should work. So I > suggest you check the two paths mentioned above, make sure they exist and are > executable, and are not returning a non-zero value. > > If that doesn't help, I'd need logs from your VM to know exactly what's going on > when you try to clone (which creates a quiesced snapshot as part of cloning). > Let me know if you need instructions on how to set up logging. > > -- > - Marcelo |
|
From: Marcelo V. <mv...@vm...> - 2011-02-09 19:34:33
|
On 02/09/2011 11:24 AM, James Ko wrote: > Is VIX really required for quiescing? I would actually prefer to have VIX disabled as I see it as a potential > security risk for the guest. VIX is needed for quiescing on Linux, yes; that's how the freeze / thaw scripts are executed. There are a few other operations from the UI that also need VIX support in the guest, although I don't remember more details. VIX requires guest authentication for most, if not all, of its operations. An exception exists when the request comes from hostd, in which case VIX assumes that hostd / VC are properly authenticating / authorizing the user to perform that operation. So unless you have some concern regarding the latter, VIX doesn't really add any security risks to the VM. -- - Marcelo |
|
From: James Ko <jim...@ho...> - 2011-02-10 08:18:37
|
I have a restricted shell which limits the user from the underlying linux apps and filesystem but authorization is using the usual mechanisms. VIX would allow access to the underlying filesystem bypassing the restricted shell. As for the logs, the user is showing guestUserName=hostd-quiescedsnap but VMAutomation_ReadGuestOperationPolicies fails. hostPolicyString is NULL VixAutomation_IsGuestOperationAllowed fails. No policy for this operation Is this the reason for the failure? What is the required policy and how does this need to be set? Jim > Date: Wed, 9 Feb 2011 11:32:38 -0800 > From: mv...@vm... > To: jim...@ho... > CC: ope...@li... > Subject: Re: cloning and pre-freeze script question > > On 02/09/2011 11:24 AM, James Ko wrote: > > Is VIX really required for quiescing? I would actually prefer to have VIX disabled as I see it as a potential > > security risk for the guest. > > VIX is needed for quiescing on Linux, yes; that's how the freeze / thaw scripts > are executed. There are a few other operations from the UI that also need VIX > support in the guest, although I don't remember more details. > > VIX requires guest authentication for most, if not all, of its operations. An > exception exists when the request comes from hostd, in which case VIX assumes > that hostd / VC are properly authenticating / authorizing the user to perform > that operation. So unless you have some concern regarding the latter, VIX > doesn't really add any security risks to the VM. > > -- > - Marcelo |
|
From: Marcelo V. <mv...@vm...> - 2011-02-11 22:56:46
|
On 02/10/2011 12:18 AM, James Ko wrote: > > I have a restricted shell which limits the user from the underlying linux apps and filesystem > but authorization is using the usual mechanisms. VIX would allow access to the underlying > filesystem bypassing the restricted shell. > > As for the logs, the user is showing guestUserName=hostd-quiescedsnap but > VMAutomation_ReadGuestOperationPolicies fails. hostPolicyString is NULL > VixAutomation_IsGuestOperationAllowed fails. No policy for this operation > > Is this the reason for the failure? > What is the required policy and how does this need to be set? The logs you sent earlier seem to imply that you don't have the VIX guest components running (see all VIX_E_UNRECOGNIZED_COMMAND_IN_GUEST). If that's the case, it's the first problem you need to fix. As far as the policy, I've been told that no configuration is needed for things to work. So make sure you have the VIX components running inside the VM if you want that to work, and let me know if you still get failures. Unfortunately your use case (restricted shell) wasn't really envisioned when this system was designed; so either you run VIX or, with the current version of ESX, lose the cloning functionality. On ESX 5.0 (yet to be released) the code path is different and doesn't use VIX anymore. -- - Marcelo |
|
From: Jim <jim...@ho...> - 2011-02-12 16:39:16
|
On 11-Feb-11 14:54, Marcelo Vanzin wrote: > On 02/10/2011 12:18 AM, James Ko wrote: >> I have a restricted shell which limits the user from the underlying linux apps and filesystem >> but authorization is using the usual mechanisms. VIX would allow access to the underlying >> filesystem bypassing the restricted shell. >> >> As for the logs, the user is showing guestUserName=hostd-quiescedsnap but >> VMAutomation_ReadGuestOperationPolicies fails. hostPolicyString is NULL >> VixAutomation_IsGuestOperationAllowed fails. No policy for this operation >> >> Is this the reason for the failure? >> What is the required policy and how does this need to be set? > The logs you sent earlier seem to imply that you don't have the VIX guest > components running (see all VIX_E_UNRECOGNIZED_COMMAND_IN_GUEST). If that's the > case, it's the first problem you need to fix. > > As far as the policy, I've been told that no configuration is needed for things > to work. So make sure you have the VIX components running inside the VM if you > want that to work, and let me know if you still get failures. > > Unfortunately your use case (restricted shell) wasn't really envisioned when > this system was designed; so either you run VIX or, with the current version of > ESX, lose the cloning functionality. On ESX 5.0 (yet to be released) the code > path is different and doesn't use VIX anymore. > I loaded the missing libraries and was able to get cloning working. Am I correct in my thinking that if I don't include the /etc/pam.d/vmtoolsd file then guest user authentication cannot take place which effectively blocks unintended guest user operation through VIX? The quiesce operation of cloning does not require guest authorization correct? Jim |
|
From: Marcelo V. <mv...@vm...> - 2011-02-14 19:14:32
|
On 02/12/2011 08:40 AM, Jim wrote: > I loaded the missing libraries and was able to get cloning working. > Am I correct in my thinking that if I don't include the /etc/pam.d/vmtoolsd > file then guest user authentication cannot take place which effectively > blocks unintended guest user operation through VIX? The quiesce operation > of cloning does not require guest authorization correct? I believe that would work, although I've never tested it. I know removing that file will block VIX operations, I just never tried quiescing with that file out of the way... -- - Marcelo |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X