(i posted this question on VMware community forums, with no response)
All of my developers use VMware workstation 11 for running their Visual Studio development environments in Windows. I originally created a base VM, and then simply shared it around to all the users, unbeknown to all the issues it would cause with computer name conflicts, joining the domain, etc. Apparently I didn't 'sysprep' it. Someone with some VMware knowledge tried to help me out to set it up, but im still not sure if it is 100% correct.
I am now at a point where I need to make changes/updates to the base VM (new VS, run Windows Updates, etc) and distribute a new one around to all the developers again, and I need some help to make sure I do it properly this time:
I have 2 VM images currently: 1) a ‘base’ one that opens up to this screen http://screencast.com/t/tBO0IUvwtpbY and 2) one that opens up to this screen http://screencast.com/t/DLV71PeNygrk . I’m assuming it is the ‘base’ one that I make the ‘edits’ to?
If I do edit the ‘base’ VM, what option(s) should I choose in that sys prep dialog?
Once I make the necessary updates to the base VM, what do I need to do to 'prepare' it for distribution to my developers (do I need to run sys prep, do I need to make a copy of VM beforehand, etc)?
Currently the VM has 2 HD's: 1) used for the OS and applications (Persistent and non-Independent), and 2) used to store data files (Persistent and Independent) . Is this the best way to set it up and use the VM (and then use 'snapshots' to revert back to previous states), or should the OS disk be set up as 'non-persistent' after the user has set up the VM for first use (i.e. joined the domain, set up VS Workspace, etc) ? Basically we have had a few scenarios recently where the OS and VS have been corrupted and it took the devs a while to fix it, so I want them to have some sort of way to revert back to a known clean working state.
Thank you
In answer to your questions you are on the right track.
the first screen that opens is correct, customise everything you require in the OS then run the OOBE before distribution
Choose OOBE and tick Generalise, then choose shutdown.
Once the VM is shutdown export it and pass it round your developers. they will need to complete the wizard and then join to the domain if required, this will ensure all the sids are different on each server, remember they must still change the Servers name before joining the domain
Snapshots are best, if your dev needs to reboot etc he doesn't want to loose his changes, he then has the option to revert to a snapshot.
Hopefully this has answered your question, let me know if there is anything else you need :)
Related
I've been trying for quite a while now to get the following thing to work - without success. I know that my approach is a bit of a dirty hack, so I'm always open for suggestions about how to do this in a better way.
We're running VirtualBox on Linux machines in a school environment. There are a couple of applications that absolutely need to be run under Windows, which is why there's no way around VirtualBox (forget wine!). So we put a Virtual Machine image on every local hard drive which the students can run if they need to. This image really ought to be "read only" in one way or another. Obviously, even running the machine will make changes to that image, so we need a mechanism that automatically reverts those changes. We're somewhat flexible about when this is supposed to happen. To me, doing this at each reboot seems to be the best approach but I wouldn't mind it being done at, say, logoff.
Right now we're using rsync on the image every time the computer boots which works as long as the virtual machine isn't started until that process is finished. Despite the fact that it works, it's a pain for the administrator as it may lead to various kinds of errors that are hard to reproduce, so there must be a better way.
My idea was to use a snapshot which I automatically revert to. Since simply deleting the Snapshot VDIs won't work, I wanted to create a "template snapshot vdi" (around 180MB) which is copied to a world writeble location (e.g. /tmp) at boot time. I know there's still a race condition but copying 180MB on a local hard drive should be significantly faster and predictable than rsyncing some 15GB. I then configure the virtual machine to use that snapshot.
Doing this VirtualBox produces error
Parent UUID {00000000-0000-0000-0000-000000000000} doesn't match UUID {12345678-1234-1234-1234-123456789012} in the xml file.
A possible cause is this issue with VirtualBox, though I'm not sure about this.
What came to my mind right now while writing those lines is using a script to copy/rsync the snapshot VDI template to the "right" path within the home directory just before the machine is being started by that script.
Are there any other suggestions?
Build time of XPages application containing several JARs, Java sources and ~50 XP/CC elements takes about minute to build on server via WAN. I have replicated application to local, build time dropped to ~10s.
Since few days ago build of local application is extremely slow, about 2-5 minutes. After some experiments there is workaround: to disable TCP port in location document - it drops build times to just few seconds. Even tho it works, it does not help much - testing requires user to be authenticated, so I need to replicate design changes to remote or local server - and that means to change location (online/offline) every time.
UPDATE 2013-04-04: I have duplicated my current location document and removed home and directory servers. To my surprise, with this location build times went back to few seconds - with TCP port enabled so replication is possible. Bigger surprise was the fact, that returning home/directory servers back to new location did not reproduce the problem - in fact they do not affect performance. I know it because I have renamed current location document and everything went to normal. From my understanding, "something" in client configuration was connected to location name. Thanks to Simon's tips I will investigate further.
The question is still open: I am looking for some (eclipse) preference controlling this behavior - unintended communication with server during build of local application.
Solution:
Teamstudio CIAO hooks into designer and checks for every update of design element. Seems to be lack of code optimization to me: it checks whether currently built design element (every single one, one by one) should be controlled in CIAO config database.
This explains why the problem was solved by renaming of location document. I was disappointed yesterday, when performance problems started again. Fortunately, I recalled CIAO setup to that location document about that time. CIAO uses teamstudio.ini file in DATA directory to configure what CIAO configuration database is used for every location document. Look for entry:
CIAOConfigDb[location name]=server name;CIAO\CIAOConfig.nsf
For development on local replicas with connection to server (for replication or local server), use location document with CIAO disabled.
This works only with property ForceConfigLocation=0.
Not a solution (yet!), but may help in the investigation. I'll update further if you post results later.
Debug instructions.
Add the following to the shortcut that launches the Designer client.
-RPARAMS -console -debug -separateSysLogFiles -consoleLog
Start the designer client. This will also open up the OSGi console.
Reproduce the issue. While it is still in progress in the OSGi console type the following:
dump threads
Do this three times, with a small amount of time between completion of each dump. Once done open the three heap dumps (in the IBM_TECHNICAL_SUPPORT folder) in the Heap Dump Analyser.
It will show you what threads are consistent through all three dumps. Take a look at those and look for package names/calls which may appear to be a functional area. Once you have that then you can try adding the debug for the related class.
For example: Let's say you notice "com.ibm.designer.domino.ui.commons." in the thread, then you would edit the rcpinstall.properties file. It will be in:
<Notes Install>\Data\workspace\.config\rcpinstall.properties
and you would add (start with FINE, then FINEST if nothing):
com.ibm.designer.domino.ui.commons.level=FINE
Now when you restart the designer client it will generate debug output in the workspace\logs folder for that package. You need to then go through the trace logs looking for the time when the delay occurred and see if it makes any references to related design elements.
Other open applications may get built at the same time (which looks like a bug top me). Be sure to close all other applications and the server based replica. Open applications have their icon showing in the application list and they stay open even if you close and reopen the Designer. In Designer 9 right click application and select "Close Application". In 8.5 you need to use Package Exprorer for closing.
Another good way is to use Working Sets. Only applications in open Working Set will be built (AFAIK). Have a Working Set with this one app only (and the app only in this Working Set).
update 1
If these don't help I would delete/rename bookmark.nsf, Cache.NDK and desktop8.ndk. Then open just this one app and see what happens.
update 2
Check that there are no referenced projects. Right click the application and select "Project Properties". From there "Project Referencies" and make sure no check boxes are checked.
update 3
Based on your update I would check the item names starting with $ in location document. Sometimes there are saved IP addresses etc. which could cause this problem. All those items can be removed.
If possible (and if You are not using it yet) try to use version 9 of the Domino designer (You do not have to use Domino 9 to do that - it works fine with Domino 8.5.3).
For our projects build times went down to only few seconds from few minutes. I guess that they finally noticed at IBM that the build process used to heavily relay on connection to server and done something with it.
With new designer You don't event have to replicate to local. You can directly work on Your local server.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm trying to migrate an existing VM from VMWARE to VirtualBox. I've made a copy of the Virtual Machine folder for the VM (so I can experiment and not destroy the original) and have successfully created a VM in VirtualBox. I've got everything booting and running, but the issue is that VM is using the "flat" disk image instead of the correct disk image causing the disk image to be from the past (I know this because all the files on the machine have a timestamp of 2009).
To elaborate, in the VM's folder i have the following vmdk files:
Win2003.vmdk (1 K)
Win2003-flat.vmdk (15 gigs)
Win2003-000002.vmdk (10 gigs)
NOTE: the disk is dynamic.
Looking in the configuration of the VM under VMWARE, it says that it's using the win2003-000002.vmdk as the disk image.
When I import the disk image into VirtualBox (the Win2003.vmdk file), it uses the Win2003-flat.vmdk disk image.
My question is, what can I do to either combine or import the Win2003-000002.vmdk disk image into the Win2003-flat.vmdk disk image so that VirtualBox will use the correct disk image?
I've some instructions on using vmware-vdiskmanager.exe to accomplish this, but I get an error stating "The parent of this virtual disk could not be opened."
After many attempts I was finally able to get this working. Essentially what I did was download and use the vmware converter to merge the two disks into one. After that I was able to attach the newly created disk to VitrualBox.
The steps involved are very simple:
BEFORE YOU DO ANYTHING!
1) MAKE A BACKUP!!! Even if you follow these instruction, you could screw things up, so make a backup. Just shutdown the VM and then make a copy of the directory where VM resides.
2) Uninstall VMware Tools from the VM that you are going to convert. If for some reason you forget this step, you can still uninstall it after getting everything running under VirtualBox by following these steps. Do yourself the favor and just do it now.
NOW THE FUN PART!!!
1) Download and install the VMware Converter. I used 5.0.1 build-875114, just use the latest.
2) Download and install VirtualBox
3) Fire up VMWare convertor:
4) Click on Convert machine
6) Browse to the .vmx for your VM and click Next.
7) Give the new VM a name and select the location where you want to put it. Click Next
8) Click Next on the Options screen. You shouldn't have to change anything here.
9) Click Finish on the Summary screen to begin the conversion.
10) The conversion should start. This will take a LOOONG time so be patient.
11) Hopefully all went well, if it did, you should see that the conversion is completed:
12) Now open up VirtualBox and click New.
13) Give your VM a name and select what Type and Version it is. Click Next.
14) Select the size of the memory you want to give it. Click Next.
15) For the Hard Drive, click Use and existing hard drive file and select the newly converted .vmdk file.
16) Now Click Settings and select the Storage menu. The issue is that by default VirtualBox will add the drive as an IDE. This won't work and we need as we need to put it on a SCSI controller.
17) Select the IDE controller and the Remove Controller button.
18) Now click the Add Controller button and select Add SCSI Controller
19) Click the Add Hard Disk button.
20) Click Choose existing disk
21) Select your .vmdk file. Click OK
22) Select the System menu.
23) Click Enable IO APIC. Then click OK
24) Congrats!!! Your VM is now confgiured! Click Start to startup the VM!
I will suggest something totally different, we used it at work for many years ago on real computers and it worked perfect.
Boot both old and new machine on linux rescue Cd.
read the disk from one, and write it down to the other one, block by block, effectively copying the dist over the network.
You have to play around a little bit with the command line, but it worked so well that both machine complained about IP-conflict when they both booted :-) :-)
cat /dev/sda | ssh user#othermachine cat - > /dev/sda
QEMU has a fantastic utility called qmeu-img that will translate between all manner of disk image formats. An article on this process is at http://thedarkmaster.wordpress.com/2007/03/12/vmware-virtual-machine-to-virtual-box-conversion-how-to/
I recall in my head that I used qemu-img to roll multiple VMDKs into one, but I don't have that computer with me to retest the process. Even if I'm wrong, the article above includes a section that describes how to convert them with your VMWare tools.
Note: I am not sure this will be of any help to you, but you never know.
I found this link:http://www.ubuntugeek.com/howto-convert-vmware-image-to-virtualbox-image.html
ENJOY :-)
This error occurs because VMware has a bug that uses the absolute path of the disk file in certain situations.
If you look at the top of that small *.vmdk file you'll likely see an incorrect absolute path to the original VMDK file that needs to be corrected.
If I already have an image that exists, can I create an image based on the existing one, except I want to make changes to the exisiting one (mainly configurations).
I do this all the time. I actually keep each of my VMs in a separate directory and duplicate the entire directory to make a copy. All references within the VMX file (configuration) are relative to the current directory.
One thing you need to watch out for. The VMX file has a line with the MAC address of the virtual network card:
ethernet0.generatedAddress = "00:0c:29:ff:1f:c7"
You'll need to change that if you want to run both VMs at the same time - I usually just bump the final digit up by 1 (to c8).
I also change the displayName in that file so I can tell the difference between them when they're running.
Yes, you can just copy the image off to external storage. Just find the image file(s) on your drive and do the copy when the image is not running. You can then change the original all you want. Is this what you are after?
What I do is create a base "clean" VM which I then run Sysprep on before cloning. You can run into a few problems when you don't reset the 'unique' elements of a windows installation and you're trying to run them simultaneously.
I'm running ~20 VMs at the moment and if any one gets seriously messed up (they're used for testing) I've got clean base images of Windows 2000, Windows XP, Vista and Server 2003 at the ready so I can be back up and running in 20mins or less.
Depending on what your needs are, you might try the (free) VMWare Converter. It lets you change drive sizes and other image parameters.
As others have said, this is exactly how you implement full backups for your VMs.
When the VM is not running, merely copy the virtual disks into a different location, then restart the VM.
Trying to honor a feature request from our customers, I'd like that my application, when Internet is available, check on our website if a new version is available.
The problem is that I have no idea about what have to be done on the server side.
I can imagine that my application (developped in C++ using Qt) has to send a request (HTTP ?) to the server, but what is going to respond to this request ? In order to go through firewalls, I guess I'll have to use port 80 ? Is this correct ?
Or, for such a feature, do I have to ask our network admin to open a specific port number through which I'll communicate ?
#pilif : thanks for your detailed answer. There is still something which is unclear for me :
like
http://www.example.com/update?version=1.2.4
Then you can return what ever you want, probably also the download-URL of the installer of the new version.
How do I return something ? Will it be a php or asp page (I know nothing about PHP nor ASP, I have to confess) ? How can I decode the ?version=1.2.4 part in order to return something accordingly ?
I would absolutely recommend to just do a plain HTTP request to your website. Everything else is bound to fail.
I'd make a HTTP GET request to a certain page on your site containing the version of the local application.
like
http://www.example.com/update?version=1.2.4
Then you can return what ever you want, probably also the download-URL of the installer of the new version.
Why not just put a static file with the latest version to the server and let the client decide? Because you may want (or need) to have control over the process. Maybe 1.2 won't be compatible with the server in the future, so you want the server to force the update to 1.3, but the update from 1.2.4 to 1.2.6 could be uncritical, so you might want to present the client with an optional update.
Or you want to have a breakdown over the installed base.
Or whatever. Usually, I've learned it's best to keep as much intelligence on the server, because the server is what you have ultimate control over.
Speaking here with a bit of experience in the field, here's a small preview of what can (and will - trust me) go wrong:
Your Application will be prevented from making HTTP-Requests by the various Personal Firewall applications out there.
A considerable percentage of users won't have the needed permissions to actually get the update process going.
Even if your users have allowed the old version past their personal firewall, said tool will complain because the .EXE has changed and will recommend the user not to allow the new exe to connect (users usually comply with the wishes of their security tool here).
In managed environments, you'll be shot and hanged (not necessarily in that order) for loading executable content from the web and then actually executing it.
So to keep the damage as low as possible,
fail silently when you can't connect to the update server
before updating, make sure that you have write-permission to the install directory and warn the user if you do not, or just don't update at all.
Provide a way for administrators to turn the auto-update off.
It's no fun to do what you are about to do - especially when you deal with non technically inclined users as I had to numerous times.
Pilif answer was good, and I have lots of experience with this too, but I'd like to add something more:
Remember that if you start yourapp.exe, then the "updater" will try to overwrite yourapp.exe with the newest version. Depending upon your operating system and programming environment (you've mentioned C++/QT, I have no experience with those), you will not be able to overwrite yourapp.exe because it will be in use.
What I have done is create a launcher. I have a MyAppLauncher.exe that uses a config file (xml, very simple) to launch the "real exe". Should a new version exist, the Launcher can update the "real exe" because it's not in use, and then relaunch the new version.
Just keep that in mind and you'll be safe.
Martin,
you are absolutely right of course. But I would deliver the launcher with the installer. Or just download the installer, launch it and quit myself as soon as possible. The reason is bugs in the launcher. You would never, ever, want to be dependent on a component you cannot update (or forget to include in the initial drop).
So the payload I distribute with the updating process of my application is just the standard installer, but devoid of any significant UI. Once the client has checked that the installer has a chance of running successfully and once it has downloaded the updater, it runs that and quits itself.
The updater than runs, installs its payload into the original installation directory and restarts the (hopefully updated) application.
Still: The process is hairy and you better think twice before implementing an Auto Update functionality on the Windows Platform when your application has a wide focus of usage.
in php, the thing is easy:
<?php
if (version_compare($_GET['version'], "1.4.0") < 0){
echo "http://www.example.com/update.exe";
}else{
echo "no update";
}
?>
if course you could extend this so the currently available version isn't hard-coded inside the script, but this is just about illustrating the point.
In your application you would have this pseudo code:
result = makeHTTPRequest("http://www.example.com/update?version=" + getExeVersion());
if result != "no update" then
updater = downloadUpdater(result);
ShellExecute(updater);
ExitApplication;
end;
Feel free to extend the "protocol" by specifying something the PHP script could return to tell the client whether it's an important, mandatory update or not.
Or you can add some text to display to the user - maybe containing some information about what's changed.
Your possibilities are quite limitless.
My Qt app just uses QHttp to read tiny XML file off my website that contains the latest version number. If this is greater than the current version number it gives the option to go to the download page. Very simple. Works fine.
I would agree with #Martin and #Pilif's answer, but add;
Consider allowing your end-users to decide if they want to actually install the update there and then, or delay the installation of the update until they've finished using the program.
I don't know the purpose/function of your app but many applications are launched when the user needs to do something specific there and then - nothing more annoying than launching an app and then being told it's found a new version, and you having to wait for it to download, shut down the app and relaunch itself. If your program has other resources that might be updated (reference files, databases etc) the problem gets worse.
We had an EPOS system running in about 400 shops, and initially we thought it would be great to have the program spot updates and download them (using a file containing a version number very similar to the suggestions you have above)... great idea. Until all of the shops started up their systems at around the same time (8:45-8:50am), and our server was hit serving a 20+Mb download to 400 remote servers, which would then update the local software and cause a restart. Chaos - with nobody able to trade for about 10 minutes.
Needless to say that this caused us to subsequently turn off the 'check for updates' feature and redesign it to allow the shops to 'delay' the update until later in the day. :-)
EDIT: And if anyone from ADOBE is reading - for god's sake why does the damn acrobat reader insist on trying to download updates and crap when I just want to fire-it-up to read a document? Isn't it slow enough at starting, and bloated enough, as it is, without wasting a further 20-30 seconds of my life looking for updates every time I want to read a PDF?
DONT THEY USE THEIR OWN SOFTWARE??!!! :-)
On the server you could just have a simple file "latestversion.txt" which contains the version number (and maybe download URL) of the latest version. The client then just needs to read this file using a simple HTTP request (yes, to port 80) to retrieve http://your.web.site/latestversion.txt, which you can then parse to get the version number. This way you don't need any fancy server code --- you just need to add a simple file to your existing website.
if you keep your files in the update directory on example.com, this PHP script should download them for you given the request previously mentioned. (your update would be yourprogram.1.2.4.exe
$version = $_GET['version'];
$filename = "yourprogram" . $version . ".exe";
$filesize = filesize($filename);
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: post-check=0, pre-check=0");
header("Content-type: application-download");
header('Content-Length: ' . $filesize);
header('Content-Disposition: attachment; filename="' . basename($filename).'"');
header("Content-Transfer-Encoding: binary");
This makes your web browser think it's downloading an application.
The simplest way to make this happen is to fire an HTTP request using a library like libcurl and make it download an ini or xml file which contains the online version and where a new version would be available online.
After parsing the xml file you can determine if a new version is needed and download the new version with libcurl and install it.
Just put an (XML) file on your server with the version number of the latest version, and a URL to the download the new version from. Your application can then request the XML file, look if the version differs from its own, and take action accordingly.
I think that simple XML file on the server would be sufficient for version checking only purposes.
You would need then only an ftp account on your server and build system that is able to send a file via ftp after it has built a new version. That build system could even put installation files/zip on your website directly!
If you want to keep it really basic, simply upload a version.txt to a webserver, that contains an integer version number. Download that check against the latest version.txt you downloaded and then just download the msi or setup package and run it.
More advanced versions would be to use rss, xml or similar. It would be best to use a third-party library to parse the rss and you could include information that is displayed to your user about changes if you wish to do so.
Basically you just need simple download functionality.
Both these solutions will only require you to access port 80 outgoing from the client side. This should normally not require any changes to firewalls or networking (on the client side) and you simply need to have a internet facing web server (web hosting, colocation or your own server - all would work here).
There are a couple of commercial auto-update solutions available. I'll leave the recommendations for those to others answerers, because I only have experience on the .net side with Click-Once and Updater Application Block (the latter is not continued any more).