- Details
Here's something I discovered while doing some exports and imports with Virtualbox appliances. I thought it would be useful for others to know.
Let's say that we have a virtual machine with a disk image in Virtualbox's native disk image format, VDI.
Now, if we export that disk image as an appliance in the OVA/OVF format, this new disk image in the OVA/OVF package will be a VMWare disk image file (VMDK). Why? I guess, beause at the time of the creation of that standard, VMWare was probably the dominant player in the VM field.
So, if we would now import the previously exported appliance, we would like the resulting new vitual machine to again have a VDI disk image. Unfortunately for us, the imported virtual machine has now a vmdk disk image file, instead. OK, but why is that important, you ask. Why do we want the disk image to be in the VDI format?
For one, I prefer to the disk image format to be native to the virtualization software in order to avoid any hickups. But the main reason for me, is that Virtualbox cannot do some things like resizing or shrinking on VMDK disk images, to date. Today, if you want to resize or shrink a VMDK image, you need to first clone it into a VDI image, then do whatever you want to do with it, and if you really want to stick with VMDK, clone the processed file back into the VMDK format. Not to forget the other steps like releasing and attaching the disk images to a VM. Better to stick with the native format in the first place, right?
The solution is quick and easy though:
While importing the appliance, just rename the extension of the resulting image file from .vmdk to .vdi (see screenshot below). The importer will then write the imported disk image in the VDI format.
I have confirmed this to work with the current version of Virtualbox, 5.1.26. The functionality seems to have been implemented with version 4.0.0 back in 2010 (changelog), though.
Reading the first few hundred bytes of the disk image with `less` or some equivalent tool, like so `less your_disk_image.vdi` should show something like this:
<<< Oracle VM VirtualBox Disk Image >>> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^?^Pھ^A^@^A^@^A^@^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
...while doing the same with an vmdk image would show something like this:
KDMV^A^@^@^@^C^@^@^@^@^@^@^E^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^T^@^@^@^@^@^@^@^@^B^@^@^U^@^@^@^@^@^@^@^_^T^@^@^@^@^@^@( ^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@# Disk DescriptorFile version=1 CID=ee763a6f parentCID=ffffffff createType="monolithicSparse" # Extent description RW 83886080 SPARSE "kubuntu test-disk001.vmdk" # The disk Data Base #DDB ddb.virtualHWVersion = "4" ddb.adapterType="ide" ddb.geometry.cylinders="16383" ddb.geometry.heads="16" ddb.geometry.sectors="63" ddb.geometry.biosCylinders="1024" ddb.geometry.biosHeads="255" ddb.geometry.biosSectors="63" ddb.uuid.image="47b2c3ed-b90d-4746-a4c7-103ce9b16f9a" ddb.uuid.parent="00000000-0000-0000-0000-000000000000" ddb.uuid.modification="00000000-0000-0000-0000-000000000000" ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000" ddb.comment="" ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
- Details
Sorry for the long title, just wanted to be as precise as possible :)
A quick bit of history...
I recently started experimenting with Docker and revamped some of my development environment with it.
So, I am in the middle of developing a kind of middleware that glues onto a low-level-driver in order to provide event-driven, non-blocking I/O with PHP (via Guzzle / ReactPHP) to communicate with the very versatile open-source NoSQL Database Server ArangoDB. BTW, you should try ArangoDB out! It's really great! My favorite Swiss Army knife in the NoSQL DB World!
Here is the problem that I faced:
When you tell ReactPHP to connect to some host, it does not honour host files (in any system, be it Linux-ish, Windows or any other). It only makes DNS lookups in order to resolve the host you told it to connect to. If you have not been bitten by this, consider yourself lucky!
There are some open GitHub issues in various parts of the ReactPHP library, that ask for some way of respecting the hosts file, but there has been no actual solution, yet.
Essentially, my problem was, that I could not connect from the docker PHP container to the linked ArangoDB Container, because there was no way to tell ReactPHP to read /etc/hosts... in order to find the IP address of the linked container.
Since each new docker container (at least in my environment) would be assigned a different ip address than what it had during its last run, a hardcoded ip address for testing would not be viable. Also, it would make testing it, with Travis-CI for example, very difficult.
- Details
I though I'd share this on my blog in case it helps someone...
Today, I installed PHP5.5 besides a PHP 5.4 installation on one of my development VMs. This VM host several development and testing sites.
All was well until I loaded the xdebug extension... Then suddenly I saw page loads of 7 to 15 seconds on a Joomla 2.5 site which I was testing.
By disabling xdebug, everything went back to normal...
So I went and disabled some extensions like ioncube, gd, imagick but nothing helped.
I then took a look at the output of phpinfo() where I noticed that by accident I hadn't installed the mbstring extension.
Turns out, the page load times were going up because of mbstring not being installed.
After this was installed, everything was running smoothly again.
Why it only had that unexpected behavior when xdebug was turned on? I don't know.
- OS: Centos 6.5 (64)
- PHP =>v5.5.6
- Joomla => v2.5.19
- libfml => 1.3.2
- xdebug v2.2.4
- Details
Here's a post on a lesson I learned today:
"If you don't need XDebug, do not load it at all!
Just disabling the relevant parts in the .ini file does not really disable it - and might, depending on what you're running, hurt your performance a lot."
What's this about?
This article is nothing against XDebug, which is a great tool for php developers. It's a presentation of the facts and why it's better to not load XDebug at all, instead of just disabling it, when it's not needed.
The "Issue":
I am currently working on a project where I am using RabbitMQ in order to distribute workload from front-end PHP scripts to back-end PHP-CLI scripts using essentially some modified PHP RabbitMQ RPC Examples.
The example scripts have a lot of loops and many calls to functions and language constructs.
They also are mostly long running cli scripts. "Long running" meaning, it's not your everyday script collection that gets loaded and executed in order to build a web-page and is discarded after being active for a very small amount of time (milliseconds - seconds).
In the scenarios below there is one producer and one consumer script. The producer, produces a few thousand messages, and for each of those, the consumer script returns a message. The consumer script also acknowledges the reception of the messages.
- Details
So, I updated EasyPHP from 12.1 to Devserver 13.1 on my local development environment.
I immediately noticed very long loading times on most requests in a Joomla project (from 7 to 17 seconds).
That was weird, as the machine has lots of reserves. While trying to fix this issue, I tried some solutions found on the net, without success.
Here's the solution that worked for me.
Put (or modify accordingly) the following directives in your httpd.conf
EnableMMAP off
EnableSendfile off
AcceptFilter http none
AcceptFilter https none
The AcceptFilter directive actually does most of the job, but setting the other directives, doesn't hurt.
Some background info: The AcceptFilter directive replaces the Win32DisableAcceptEx that was used for this purpose in Apache 2.0 and 2.2.