I am aware that autoit MouseClick() would not work when the system is locked.
My Question is ::
I have VsphereClient installed on my machine and i access VMs using this client. Now if autoit script is running on VM and i lock my pc (VM is not locked), then will the mouse interaction functions work on the VM?
VM is not located on my local pc. It is located on an ESX server.
So if the VM is not in locked mode and my pc is in locked mode, will the mouseclick() of AutoIT work on the VM?
vSphere is purely a configuration utility. It is not required for the virtual machines to run in anyway.
Therefore... If you have a script on your VM and that VM is not locked it would work exactly the same if you had it on a PC.
Don't make the mistake that vSphere is require for the machines on ESXi hypervisor to run.
Hope this helps :)
If your VM is not locked and Autoit is running on your VM, the MouseClick() will work perfectly as it will only occurs on your VM independently of your current local pc state. In fact you must see your VM as another PC and since it's running and not locked you can do everything you want, in your case an autoit script.
Related
I'm new to the WSL2 and wondering if it's possible to run the same WSL2 ubuntu instance on both my desktop and laptop.
Now I am able to use wsl --export and wsl --import method to save and load the system to/from my portable hard drive. But these methods takes a long time.
I notice that wsl --import load a file named ext4.vhdx. Is there a way to load straightly from this file?
Update v2.0:
I was able to get a workaround and it works great.
Thanks to Booting from vhdx here, I was able to load straightly from my vhdx file on my portable hard disk. Windows track down its subsystem with regedit, So we can write our own(p.s: make sure to get BasePath right, it starts with "\\\\?", or you will not be able to access the subsystem' filesystem on your host system.):
Windows Registry Editor Version 5.00
[HKEY_USERS\【your SID here】\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\{【UUID here】}]
"State"=dword:00000001
"DistributionName"="distribution name"
"Version"=dword:00000002
"BasePath"="vhdx folder path" 【 e.g. "\\\\?\\E:\\S061\\WSL\\ubuntu-20"】
"Flags"=dword:0000000f
"DefaultUid"=dword:000003e8
I suppose the best way to do this would be to store ext4.vhd on a network storage device accessible to both devices.
I have previosly mentioned how to move ext4.vhd. You can check that out here
Basically you need to export from one machine and import it while making sure the vhd file is configured for wsl to access from the network storage
Since this should *officially* not supported expect some performance hits
Another way would be to run WSL on one computer and ssh/remote desktop to it from another device on the network
I'm of the strong belief that sharing the same ext4 vhd between two VM's simultaneously would be a bad idea. See this and this Unix & Linux StackExchange, including the part about ...
note that sharing LVs/partitions on a single disk between the servers at the same time is NOT very safe. You should only access whole disks from any of the servers at one time.
However, as dopewind's answer mentioned, you can access the WSL instance on one computer (probably the desktop) from another (e.g. the laptop). There are several techniques you can use:
If you have Windows 10 Professional or Enterprise on one of the computers, you can enable Remote Desktop, which allows you to access pretty much everything on one computer from another. RDP ("Remote Desktop Protocol") even works from other devices such as an iPad or Android tablet (or even a phone, although that's a bit of a small screen for a "desktop"). That said, there are better, more idiomatic solutions for WSL ...
You could enable SSH server on the Windows 10 computer with the WSL instance (instructions). This may sound counterintuitive to some people, since Linux itself running in the WSL instance also includes an SSH server (by default). But by SSH'ing from (for example) your laptop into your desktop's Windows 10, you can then launch any WSL instance you have installed (if you choose to install more than one) via wsl -d <distroName>. You also avoid a lot of the network unpleasantness in the next option ...
You could, as mentioned above, enable SSH on the WSL instance (usually something like sudo service ssh start) and then ssh directly into it. However, note that WSL2 instances are NAT'd, so there's a whole lot more hackery that you have to do to get access to the network interface. There's a whole huge thread on the WSL Github about it. Personally, I'd recommend the "Windows SSH Server" option mentioned about to start out with, then you can worry about direct SSH access later if you need it.
Side note: Even though I have SSH enabled on my WSL instances, I still use Windows SSH to proxy to them, to avoid these networking issues.
Currently running Windows 10 (native) and VMware Workstation 12 Player. I am running various LTS releases of Ubuntu in VMware.
I am wondering if there is way for me to run SikuliX on my main OS, Windows 10, and have the script interact with a virtual machine, running an Ubuntu OS, that I have open.
The quickstart documentation on the download site isn't very specific about the limitations of SikuliX on this topic. It simply says that you can't run it on a headless system (which VMware is not), and you need to have a monitor - the only problem is that I have no idea if SikuliX considers VMware to be a legitimate monitor or not.
I am aware of the fact that you can install Sikulix on the virtual machine itself, but this is not preferable as I would have to possibly reconfigure my VM settings to allocate more memory OR just deal with running the script at a slower pace.
Any help would be greatly appreciated.
The answer is yes, if you run SikuliX on a native host, it is possible to interact with the the interface of the virtual machine the same as running SikuliX on the virtual machine itself.
Now that I think about it, I should have probably tested this out before posting the question, but hey, if anyone has the same question as I do, now you know.
I am trying to deploy a cent-os 7 VM on a vcenetr from pyvmomi python library and then before powering on the VM I am trying to setup static IP and DNS for the VM.
VM creation goes fine , but guest customization fails, givimg following error:
**Customization of the guest operating system 'rhel6_64Guest' is not sup
ported in this configuration. Microsoft Vista (TM) and Linux guests with Logical
Volume Manager are supported only for recent ESX host and VMware Tools versions
. Refer to vCenter documentation for supported configurations."
faultCause =
faultMessage = (vmodl.LocalizableMessage) []
uncustomizableGuestOS = 'rhel6_64Guest'
Now this customization problem goes away if the VM is just rebooted once. After that we can do the guest customization.
But this reboot takes around 30 seconds of time and for our case , we need to get VMs up and running faster than this time.
Any body who faces similar problem and has some context on it will be very helpful.
Also I don't understand how rebooting the VM solves this problem.
Please share your thoughts even if you don't have exact solutions .
On further Investigation I found that open-vm-tools does not work until the VM is powered on atleast once.
When Machine is powered on , the HOST system detects the open-vm-tools running on guest OS , and from there on open-vm-tools works.
So open-vm-tools can not be used for initial provisioning as it will just not work at the start up.
Cloud-init is the alternative solution which should be used for initial provisioning.
I want to creatre portable dev environment inside a Vagrant box. But faced a problem with ssh key access rights. On some target machines I haven't got enough rights to change them. Is it possible to configure Vagrant to have access maybe only with password to make box fully rights-independent?
You can have vagrant box running from USB (I do that a lot and its nice to take hard drive with you and go on another computer and everything is running the same)
If you run VMWare provider, this is all set as all the vagrant file and the VM files are within the .vagrant directory from your project so just run Vagrant init and vagrant up within your USB and all the files are there, you can take the USB drive with you and connect to another computer running vagrant/VMWare and you're good
When you run VirtualBox provider, its a bit different as the vagrant files will be stored within your vagrant directory but your VM files will likely be stored with your My Documents folder.
You can overcome that by forcing VirtualBox to store the files on the USB as well - see this answer https://stackoverflow.com/a/36343325/4296747 to have multiple options how you can do that
I am running a virtual machine in Bluemix and want to open the OS's desktop GUI. How do I do this? Thanks for your help.
I've edited your question to what I think you're asking: How can I open the desktop GUI on my virtual machine in Bluemix?
Assuming I understand the question correctly:
To open the desktop GUI on a remote virtual machine, use Virtual Network Computing (VNC). This solution is not specific to Bluemix; it'll work with a VM running on any platform, as long as the VM is running an OS that supports VNC.
To use VNC, you need to have a VNC server running in your VM's OS. You will then run a VNC client (a.k.a. viewer) on your computer to display the VM's desktop. The specific instructions depend on the OS running in the VM and on your computer.
For example, assuming your VM is running Ubuntu v14.04, these resources explain what to do (and a search will find other resources):
"How to Install and Configure VNC on Ubuntu 14.04" -- Installs XFCE4 as the VNC server
"How To Install And Configure VNC On Ubuntu 14.04" -- Also installs XFCE4.
"How to Install VNC Server on Ubuntu 14.04 LTS" -- Installs TightVNC as the VNC server
For a VNC client, I actually connect to remote VMs via a local VM running Ubutu 14.04, so I use Vinagre (a.k.a. the Remote Desktop Viewer app). Options listed by other authors include TightVNC, RealVNC, or UltraVNC.
Good luck and thanks for using Bluemix.
From what I understand, you need some remote desktop tool to get to the UI of the OS of your virtual machine. Some tools available: http://www.techradar.com/us/news/software/applications/7-of-the-best-linux-remote-desktop-clients-716346