I have here a Windows distribution server that runs an ANT task to build enterprise software. What I need to do is to have the ANT task copy and run a VM image (Linux), and then...talk to that Linux VM through the host operating system (through the ant task itself). We need to be able to send files and/or commands to it.
Is there a practical way to go about this? I know that we already have a way to send commands to VMs that are also running Windows (so windows-windows interaction) -- but is there a way to do a windows-linux interaction?
I've implemented the thing you wanted. Of course, for my own purposes, and then just found this question by googling on keywords "vmware" and "ant".
https://github.com/zhuravlik/ant-vix-tasks
This is the taskset for Ant to manage VMWare VMs.
It works via VIX API, so Linux guests should be supported by it.
I did not test it with VMWare Server, though. Only with Workstation.
But the API is common, so it should work.
Using ssh is probably the simplest. There is an ant task for that. Scp task is also there to copy files
It will depend on what you need to do, but:
The Linux system could expose an SSH server, and the host can do just about anything it needs to via SSH.
The Linux system could expose a web service that the host consumes.
The Linux system could expose a Samba share which the host then connects to and reads/writes from (if all you need to do is deal with some files, but that seems unlikely).
There are probably dozens of options.
Related
Here’s the question: When using Vagrant for a Java project (or any compiled language project for that matter), should you compile in the VM or on the host? Also, would you want your IDE and all your development tools to be run from inside the VM as well, or on the host?
It seems to be not very well defined exactly how a Java IDE and the compile/deploy process work with a Vagrant VM. Generally my impression is that code is edited on the host, and run on the VM, which works great for non-compiled languages. Other answers on Stackoverflow have implied that Vagrant is less useful for compiled languages because of the extra compile step, but I still want to see what can be done.
Some things I’ve thought through already:
Why compile on the VM
if compiling on host, java is one more piece of software to install
if compiling on host, the java version on host must be manually kept up to date with that on the VM
the corresponding java version on the host might be unavailable (say, on a Mac)
Why have IDE on the VM
tighter integration between environment and IDE, can use shortcuts to run the application
can connect debugger for java applications without remote debugging (one step run/debug)
Why compile on the host
faster compile times
want to keep the VM as close to what production looks like as possible
Why have IDE on the host
it’s the vagrant convention to edit code on the host and run it on the VM
better UI performance (X forwarding and VNC are slow)
What are your thoughts: should I run my IDE from inside the VM or the host? Should I compile from inside the VM or the host?
After much thought and experimentation, I've decided on where to use Vagrant and how it integrates with the Java development workflow.
For JavaEE / deployed applications, configuring a web server and a database server are definitely things that have "enough" complexity to warrant the use of Vagrant. With two servers and the myriad ways to configure them, it's easy for configuration to get out of sync from one developer to another, bringing about the "works on my machine" syndrome. For this kind of software, it would work best to edit and compile the code on the host, and deploy to a Vagrant VM that mimics your production environment. The deployment folder for the web server could even be symlinked to a compile target on the host, removing the need to manually redeploy. So Vagrant could be an important part of your development lifecycle, but the cycle time for code/compile/deploy from the host and run on the VM with Java would be longer than the cycle time for code on the host and run on the VM that we see with PHP/Ruby/Node/etc.
For standalone Java applications (like libraries or desktop applications) the story changes a bit. In this case it makes the most sense to edit, compile, and run on the host machine, eschewing the use of Vagrant altogether. If you're using one of the big Java IDE's (Eclipse, Netbeans, IntelliJ...), you already have Java installed on the machine. At that point there is very little advantage compared to the overhead of using Vagrant, and only serves to put an extra layer of complexity in your development process. This is because by the time you are able to edit Java with an IDE you are able to run everything on the host anyway. One issue is that the version of Java required for the project may not match the version running the IDE on the host. In general (hopefully) this is not too much of a problem; as of this writing JDK6 is end-of-lifed and JDK8 is not yet released (guess where that leaves us). But if you did need to run multiple versions, you should be able to set JAVA_HOME on the host as needed. Though this does introduce extra complexity, it is less complexity than maintaining a Vagrant runtime just to work with projects using different versions of Java.
The interesting question is what to do with containerless web applications. Should the web server (in this case internal to the application) be run inside the VM as we did for the external web server? Or run on the host as we did for the standalone application? For containerless web applications, there is no external web server to worry about, but there is still likely a database. In this situation we can take a hybrid approach. Running a containerless web app is essentially the same as running a standalone application, so it would be effective to compile and run your code on the host machine. But with a database involved there is still enough complexity and configuration there that it makes sense to have the database server be on its own Vagrant VM.
Hopefully this gives Java developers who are interested in Vagrant some context about how to use it.
I was interested to this topic during the last year :)
My solution is to have a vagrant machine configurable with flags.
For example one of this flag enable the desktop gui because some developer prefer to code on the host machine while others prefer to have a much more integrated environment with the desktop and the IDE in it.
To face the desktop slowness you should install a very useful vagrant plugin (yeah... vagrant has plugins that greatly improve the development environment) in this way: vagrant plugin install vagrant-vbguest
This plugin will install virtual box guest addition on every guest to make it usable while using the virtualbox interface.
Then to enable the gui edit the Vagrantfile in this way:
config.vm.provider "virtualbox" do |vb|
vb.gui = true
end
Instead to speed-up the shared folder performances I suggest to use rsync:
config.vm.synced_folder "./git", "/home/vagrant/git", type: "rsync", rsync__exclude: ".git/"
In this way the source code is edited on the host and then rsync-ed to the guest.
I need to determine the list of JVMs running on a remote machine, and once that is done, to connect to each of the JVMs using JMX. I am a newbie and have gone through the following concepts:
1. using jps and jstat: I read that these commands may not be available in the future jdk versions.
2. using the java class "virtualmachine().list" . The problem with this though is that it helps you fetch the list of JVMs but only for the local machine. I do not know how to connect to a remote machine and then obtain this list.
Can anyone please suggest how to use either "virtualmachine().list" or any other method to obtain a list of JVMs on a remote machine ?
The problem is that all the methods(including the way jconsole works) that I have studied to connect to a remote JVM are focused to a SPECIFIC JVM where I need to provide the port number(of the JVM process). But I need a list of all the JVMs running. How can I do this ? Is it even possible ?
One option would be to launch a small java application on the remote machine and have it run virtualmachine().list or similar and then send back the information or make it accessible using JMX. This application could be running all the time, or you could maybe launch it remotely.
Some other ideas mentioned here: Get System Information of a Remote Machine (Using Java).
You could add a java-agent or some other common component to each of the remote JVMs and have them "phone-home" their JMXServiceURLs to a central JVM clearing house. Other than that, I think your only options are derived broadly from monex0's suggestion.
I have a windows machine which connects to a remote Linux machine where my Java program is running. How could I run a command for example, "free -m" in the remote linux machine and collects data in the windows machine. Any strategy?
You can execute Linux command from java program remotely using Jsch and expect4j.
For example, look at this question.
You can use ssh user#host free -m. Just get some ssh client for windows. I personally prefer cygwin which will also give you a nice way to script it using bash.
If you use anything except jsch, you run the risk of blasphemy :)
I have previously used Trilead SSH which was great and simple to use. Unfortunately Trilead don't support it anymore, however according to this site (lots of SSH links there) the ex-Trilead version is now here.
I'm running a number of java processes on a windows XP professional machine. When i attempt to connect to these processes via a local JConsole the processes are grayed out.
However i can run the same processes on another machine and connect via a local JConsole on that machine.
Both machines are running java 1.6 version for the processes and jconsole.
Any ideas why these processes are grayed out?
I'm fighting with this issue right now and I found out a work around:
You can change the local user's temp dir to something that they can definitely access (e.g. D:\temp). Make sure to do this for the process you're trying to monitor and the jconsole process.
Another thing that can apparently cause issues are usernames with uppercase letters in them. The directory will always be created with all lowercase letters, but simply renaming it to exactly how it's being shown in the Task Manager made all the issues go away: http://planeofthought.com/wp/?p=75
if the processes are running as a different user (e.g. if you start them as services), then you won't be able to connect to them. also, if they are running under an older jvm, you most likely won't be able to talk to them either.
in some cases, the local jmx communication mechanism uses the local filesystem and may have issues if permissions are not defined correctly. are you possibly running any of these processes on networked filesystems (nfs, samba)?
Say your windows user name you use to start your java application seen in task manager is YOUR_USER_NAME.
Please check a folder whose name looks like hsperfdata_XXXXX (XXXXX should be your user name) in your temp folder and make sure YOUR_USER_NAME and XXXXX are exactly the same (be careful about the upper and lower case).
From http://download.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html:
Applications that are not attachable, with the management agent disabled. These include applications started on a J2SE 1.4.2 platform or started on a J2SE 5.0 platform without the -Dcom.sun.management.jmxremote or com.sun.management.jmxremote.port options. These applications appear grayed-out in the table and JConsole cannot connect to them. In the example connection dialog shown in Figure 3-1, the Anagrams application was started with a J2SE 5.0 platform VM without any of the management properties to enable the JMX agent, and consequently shows up in gray and cannot be selected.
(source: oracle.com)
Despite what's being written in the documentation, most likely your process is running under a different user. You can run jconsole as an administrator and try then.
Here is what worked for me. I changed my %TEMP% and %TMP% environment variables to point to a folder I created in my %HOME% location (like C:\Users\[YOUR_NAME]\Temp). Once I did this, all problems vanished.
I had the problem as described earlier, but was advised a simpler solution: just close all programs using Java ("IntelliJ IDEA", "SoapUI", etc. - to unlock the temporary folder) and then delete %TMP%\hsperfdata_<user.name> folder. Then, after opening any Java program, this folder will be recreated but this time with correct name (most likely %TMP%\hsperfdata_<User.Name>). And after that, local Java processes can be monitored through "JConsole" or "VisualVM" (now runs without starting error with a link to VisualVM: Troubleshooting Guide) again.
instead of this steps you can just goto the CMD and then type in jconsole.exe (PID)
Remember to go to the path where jconsole is present and then run the executable file.
Change the name of the hsperfdata folder which for me was found at C:\Users\pmimgg0\AppData\Local\Temp\hsperfdata_pmimgg0 to match the User name found on task manager. Once I changed hsperfdata_pmimgg0 to hsperfdata_PMIMGG0 my local process was no longer greyed out on jconsole.
Change your TEMP paths in Environment Variables to something like D:\temp as it could be a permission issue. Fixed this issue for me
The best way is to run local process like a remote process.
Add these conditions in runtime arguments -
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=6001
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.rmi.port=6001
Then select Remote Process and point to localhost:6001 as shown
Click Connect and Jconsole is connected successfully.
For me this fixed as I had some admin constraints.
I have a cluster of 32 servers and I need a tool to distribute a Java service, packaged as a Jar file, to each machine and remotely start the service. The cluster consists of Linux (Suse 10) servers with 8 cores per blade. The application is a data grid which uses Oracle Coherence. What is the best tool for doing this?
I asked something similar once, and it seems that the Java Parallel Processing Framework might be what you need:
http://www.jppf.org/
From the web site:
JPPF is an open source Grid Computing
platform written in Java that makes it
easy to run applications in parallel,
and speed up their execution by orders
of magnitude. Write once, deploy once,
execute everywhere!
Have a look at OpenMOLE: http://www.openmole.org/
This tool enables you to distribute a computing workflow to several resources: from multicores machines, to clusters and computing grids.
It is nicely documented and can be controlled through groovy code or a GUI.
Distributing a jar on a cluster should be very easy to do with OpenMOLE.
Is your service packaged as an EJB? JBoss does a fairly good job with clustering.
Use Bit Torrent. Using Peer to Peer sharing style on clusters can really boost up your deployment speed.
It depends on which operating system you have and how security is setup on your network.
If you can use NFS or Windows Share, I suggest you put the software on an NFS drive which is visible to all machines. That way you can run them all from one copy.
If you have remote shell or secure remote shell you can write a script which runs the same command on each machine e.g. start on all machines, or stop on all machines.
If you have windows you might want to setup a service on each machine. If you have linux you might want to add a startup/shutdown script to each machine.
When you have a number of machines, it may be useful to have a tool which monitors that all your services are running, collects the logs and errors in one place and/or allows you to start/stop them from a GUI. There are a number of tools to do this, not sure which is the best these days.