I have a few VMs in Parallels 11, running several different versions of OS X, for automated software builds.
I recently copied those VMs to a different host, so I'd have a second set to fall back on in case of a hardware failure.
The problem: the copied VMs have the same Hardware UUIDs as the corresponding originals, and that causes a problem backing up the VMs with Time Machine, since Time Machine links backup images to machines by their Hardware UUIDs. If you have two VMs with the same Hardware UUID, Time Machine running in those two VMs will try to write to the same sparsebundle file on the backup server.
I googled the issue and found this: http://kb.parallels.com/en/11197 -- but those instructions don't work for Parallels 11: when you double-click the pvm, it is imported immediately, without asking whether it was moved or copied. When I first imported the copies, Parallels asked me whether the VMs were moved or copied, and I answered that they were copied. The KB article makes it sound like that should have made Parallels assign new Hardware UUIDs to the VMs, but that didn't happen (it did assign new MAC addresses, though).
I'm going to try finding the Hardware UUID in the PVM using a hex search; if I can find it, maybe I can change it manually, using a hex editor. It seems like a very yucky procedure, though, for something you'd think Parallels should handle itself. Is there any better way of doing this? Is this a bug in Parallels 11, or did they deliberately remove the Hardware UUID reset functionality (and if so, why)?
I was able to change it by:
Shutting down the virtual machine
Find the virtual machine bundle located on disk in Finder, right click on it and "Show package contents" on the actual .pvm file.
Then find the config.pvs file inside and open it with a text editor.
Change an arbitrary digit in the <SourceVmUuid>
value
Start the virtual machine
You can then go to:
About this Mac -> System Report -> Hardware
and inspect that the Hardware UUID has changed.
Related
I am trying to install Linux in a computer that has Windows 7. The first step was shrinking the disk size but Windows did not allow any reduction. Thus I followed a number of steps to disable "unmovable" files
I disabled the Page File
I disabled hibernation
I disabled System Protection
After that nothing seemed to have changed so I checked the disk fragmentation and it was 11% fragmented. I have since then run at least 4 defrags and I have also defragged the free space using Defraggler.
As of now the disk looks like this
Right now, Windows refuses to shrink the partition by any amount (I imagine that the files at the end of the disk are the troublesome ones).
Coming from an Linux background I am unsure what else needs to be done in order to shrink the partition.
Are you using Windows disk management tool to do the shrink? Here's a link for that method.
https://www.howtogeek.com/howto/windows-vista/resize-a-partition-for-free-in-windows-vista/
Also make sure the recycle bin on that drive is empty.
I finally figured it out.
The easiest way is just to use a Live USB with GParted on it since that will allow you to move Windows protected files around (the windows OS is not loaded on the live distro).
If just defragmenting is concerned one can use Hiren's Boot CD and the included Defraggler for the same purpose.
I had the same problem on Windows 10. Turns out it was antivirus software that was running on the machine that prevented defragmentation happen properly. I actually had to temporarily uninstall antivirus. After that, the Disk Management tool was able to correctly shrink the volume.
Can we find if our software has been copied in an OS image (windows) and then deployed in another machine. The hardware details do change but it may be due to hardware upgrade or change.
Is there anything at software level which indicates that the OS image has been installed.
P.S the OS install date doesnt change after image deployment.It shows the date of original OS installation date and time and not that of the imaged one.
For example i tried to detect this using service tag,uuid and os install date changes . I thought the hardware and software details combined would result in correct detection. But the os install date dint change and hardware details changed or showed junk value during hardware upgrade . My software will be installed in the os . Then OS will be imaged. I want to detect the imaged installation
If your software is connected to the Internet this is relatively easy to solve. You arrange to 'call home': send occasional packets to a known server address containing enough information to identify the instance.
For this purpose UDP packets serve quite well. You include information about the build of your software, the operating system it is running on, some simple hardware details such as how much memory and disk, the IP address and the MAC address. From the packets logged by your server you will easily be able to tell an original instance from a clone, or an original with updated hardware in almost every instance. You may also be able to obtain highly distinctive information by a detailed inspection of hardware if you have sufficient privilege.
Please note that Windows does exactly this. If an activated copy is found running on a machine that is sufficiently different then it must be re-activated. The definition of 'sufficiently different' is not made public.
Just to be clear, what I'm describing is a heuristic, not an algorithm. I'll assume the original installation creates a GUID, and that a clone carries the same GUID. When you receive packets from installations with the same GUID containing enough information, in practice you will be able to tell the original from the clone in virtually every case. Two clones may start identical but very soon something will diverge: a network IP address, disk free space, active devices.
This may not fill all the requirements of the original question but it will work (it already does) and it's better than nothing.
Generate a GUID each time the computer boots, and include both the current GUID and the history of GUIDs previously generated each time you report to the server.
If a machine's report has a GUID missing, then you know the machine has been cloned and at least one new instance should be generated. You can determine when the cloning took place by looking for the last GUID that is remembered by both instances.
To determine which instance to consider "the same machine" as the original, if this matters, look for changes in the MAC address or computer name. If there is exactly one instance where neither of these have changed since the machine was cloned, that can be assumed to be the original. (If there are multiple instances with the same MAC address, something is badly wrong; bring it to the attention of the system administrators and let them sort it out.)
If none of the current instances has a matching MAC address and computer name, this might mean that the original machine has not been powered back up yet but will be eventually, or that it has been destroyed, or that it is permanently offline and only being used as a template. It could also mean that, by coincidence, the computer name and/or MAC address were changed after the machine was cloned but before the next report.
How best to deal with this depends on the context, but in most cases it would probably be sensible to show the original machine as a separate instance, even if you haven't had a report from it since the cloning took place, and let the system administrator manually delete it if appropriate.
How would you retrieve the BSOD text from a virtualbox vm??
As the BSOD is text, it should be stored in the VM's memory space somewhere and probably somewhere well defined.
I have several VMs that have been configured to stop on blue screens rather than rebooting, and code is in place to take screen shots at regular intervals.
At this point my plan is to difference two images, if there are no differences ( i.e. there have been no changes on the screen) and the pixels in the 4 corners are all blue ( and the right blue) then we attempt extraction of the BSOD text, search the text for the "* STOP:" sequence to confirm it as a BSOD.
I originally planed on a quick and dirty OCR solution to extract text from the image itself, however if we can relatively easily extract it from memory we would remove the possibility of OCR errors.
I've perused the manual and API reference and haven't seen anything that seems to immediately apply.
Is it possible to access the guests memory from the Virtual Box host and retrieve the BSOD text directly from memory?
UPDATE
Just to clarify, I've considered 4 different options at this time
1) Reverse engineering the windows debug protocol and building at least a basic debugger to listen on the vm's serial port
Requires reverse engineering serial protocol, suspect this would present a fair amount of difficulty
2) Reverse engineering the Virtualbox saved state file and extracting the text from the VESA memory area that I suspect is stored in that file after saving the VM on the BSOD
I haven't been able to find documentation on this file format outside the source code itself.
3) Running OCR on the output image retrieved using the API
This may be the best way to go, requires building or setting up and training an ocr solution of some kind, outside my experience. May be relatively simple to do, constant width font/ clean image, only two colours to deal with
4) Access the guests memory directly using either an API call or by creating an extension to access/expose it in some manner
As pointed out by Warren, there doesn't seem to be an API to access the memory, may be able to write an extension to expose the vm's memory in some manner, but would require understanding of Virtualbox internals.
This is running on Solaris hosts, and some may only have one Windows vm available that may or may not boot. This VM could be any relatively recent version of windows (XP, 2003, 2003 R2, 2008,Vista, 2008 R2). I can spawn an arbitrary number of Linux based VM's, however I cannot spawn additional windows VM's due to licensing concerns. My thought to this point has been that retrieving it directly from the guests memory would be the easiest to implement, perhaps I'm mistaken in that and one of the above methods, or one I haven't thought of, would be easier to implement
If you are trying to just get the information why not just enable kernel debugging and expose it over one of the virtual serial ports? I believe you should be able to use either Debugging Tools for Windows (WinDbg) or Kernel Debugger (KD) over an I/O port. The only unique requirement because this is a VM is that the virtual serial port should be mapped to a named pipe on the host, and then the debugger on the host (or other VM since your host isn't Windows) should be configured to communicate over that pipe. Your commands would look something like this:
windbg -k com:port=\\.\pipe\<pipe_name>,pipe
kd -k com:port=\\.\pipe\<pipe_name>,pipe
There is a great blog post by the legendary Mark Russinovich that describes how he used the debugger to alter the colors of the BSOD screen. Hopefully that will provide you some additional insight into using the tools as well as narrowing down the field and getting you to the right area to extract the info you are looking for.
Here are some references to help get you started:
KB Article 151981: How to set up a remote debug session using a null modem cable
http://support.microsoft.com/kb/151981
A Bluescreen By Any Other Color
http://blogs.technet.com/b/markrussinovich/archive/2010/12/14/3374820.aspx
Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/gg463009
It is possible to extract the guest (virtual) physical memory using VBoxManage and a debugger.
VBoxManage debugvm TestVm dumpguestcore --filename guest.dump
gdb --core guest.dump
# dump memory [phys-mem-file] 0x0 [size vm-memory]
Afterwards one can search the memory dump for string content.
See also: http://www.halfdog.net/Misc/TipsAndTricks/VirtualBox.html#ExtractGuestPhysicalMemory
I have the following setup for my daily/main/only development environment
Hardware/Tin = 4gb ram, 2.6ghz dual core CPU, 2x250gb HD's, usual array of periperhals
One the tin above, I currently have Windows XP installed, in Windows XP I have VMWare Workstation installed and I run a Windows Server 2003 deelopment environment. This includes,Visual Studio 2003/2005/2008, Sql Sever 2005/2008, Full MS Office suite, some producitivity tools (e.g. Redgate Sql/Data Compare, DevXpress Coderush, TestDriven.net etc).
I have problems with this, it runs slow (15 minutes to boot), the Watch/Autos windows in VS freeze up when debugging, I can't have more than 2-3 copies of VS open, the Errors window freezes up, WinGrep and COm+ constantly runs out of Virtual Desktop Memory and so forth (In fact, I would attribue most of the issues to Virtual Desktop Memory)
Now, I've tried every tweak in the book, I have second HD for VMWare, my paging file is on a differnt drive, I've adjusted my Ram split between guest and host, I've hacked the reg key for Virtual Desktop Memory and all of this to no avail.
Now, I could increase my Ram or CPU, but I'm not able to.
My question is, has anybody experienced the above, and if so, how did you solve it? Did you try ESXi? or shift your environment to raw tin?
IMHO, you've tried just about every tweak in the book. I'd suggest that you should just move to native for your main setup, and restrict VM use for testing.
I use a VM as my main dev env, but I don't run as much stuff as you, so I don't hit a big performance wall.
I guess the trick you didn't try was to run less things on your VM. 2-3 copies of VS are a recipe for slowness. Running Sql Server, same thing. Bump up memory would be good, but at least run services (iis, sql server) on another vm or better yet, another box. You are taxing your VM waay too much, it is not VM's fault.
The problem you run into most of the time on VPS is IO wait.
Do you run your virtual machine off of a disk image, if so try defragmenting your drive.
Or did you dedicate a partition to it?
Edit:
I would suggest to:
either try defragmenting the drive that has the disk image
either try dedicating a partition to the virtual machine, instead of using a disk image all together. (ideally the first partition on the drive, since this will have the lowest random access time)
Running off a disk image works, but since you're working on top of a filesystem, the disk image might be fragmented throughout the disk.
Good luck, hope it helps...
To make things easier when switching between machines (my workstation at the office and my personal laptop) I have thought about trying an external hard drive to store my working directory on. Specifically I am looking at Firewire 800 drives (most are 5400 rpm 8mb cache). What I am wondering is if anyone has experience with doing this with Visual Studio projects and what sort of performance hit they see.
It depends on the size of the project. The throughput is low and the latency is high, so you're going to get hit every which way, but due to the latency you'll be hit harder if you have a lot of little files rather than a few large ones.
Have you considered simply carrying around a GIT or other distributed repository and updating the machine repositories as you move around? Then you can compile locally and treat the drive and a roving server. Since only changes will be moved across, it should be faster, and your code will be 'backed up' in more places.
If you forget the drive, it breaks, or is lost/stolen, then you can still sit down at a PC and program with no code missing if you're at the last PC you used, or very little code missing (which will be updated later with a resync anyway).
And it's just a hop skip and a jump away from simply using the network to move the changes between the systems if you don't want to carry the drive around later.
I use vmware and the virtual machines are on an external usb drive. Performance is fine. You might have some issues with the drive name changing - not an issue if you use virtual machines.
Granted I work in an industry were Personal Information and Intellectual Property are king, but I don't like that idea at all. That hard drive disappears and you have a big problem.
Why not Remote Desktop into the work machine?
EDIT Stipud Spelingg