How to change CD ISO in Xen

I was setting up some virtual machines by using Xen and virt-manager, but was stuck with being unable to change CDs when the installer asked to put in the CD number 2.

After some googling and dead-ends I found finally this approach that worked. First find out the ID of your virtual machine
root@cardolan:/var/lib/libvirt# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4886 4 r----- 402051.2
mosaic 800 1 123.6
test-i386-redhat-7.2-template 27 800 1 -b---- 103.6
test-i386-ubuntu-8.04-firefox-1.0 24 800 1 --p--- 132.8
test-ubuntu8.04-mozilla19990128 800 1 115.8
ubuntu804-template 800 1 7.8
winxp 1024 1 18674.4

The one that we are setting up is the ID 27. Then check out what disks the host is using:
root@cardolan:/var/lib/libvirt# xm block-list -l 27
(768
((backend-id 0)
(virtual-device 768)
(device-type disk)
(state 1)
(backend /local/domain/0/backend/vbd/27/768)
)
)
(832
((backend-id 0)
(virtual-device 832)
(device-type cdrom)
(state 1)
(backend /local/domain/0/backend/vbd/27/832)
(eject eject)
)
)

We are interested of the find out wich device-type cdrom. Copy the backend path i.e. /local/domain/0/backend/vbd/27/832 . Then add /params to the end to see the current mounted iso
root@cardolan:/var/lib/libvirt# xenstore-read /local/domain/0/backend/vbd/27/832/params
/home/downloads/seawolf-i386-disc2.iso

Change the ISO
xenstore-write /local/domain/0/backend/vbd/27/832/params /home/downloads/seawolf-i386-disc2.iso

and voilà you can continue the installation!

Failed to read last sector (2930272255): Invalid argument

Today I tried to fix a broken NTFs hard disk. I was able to read parts of the disk by
dd if=/dev/sdc1 of=rescue.dd.img conv=noerror,sync

When the disk started to give too many errors, I skipped some gigabytes and continued to read from further away (note by default dd reads 512bytes at a time)
dd if=/dev/sdc of=rescue.dd.img skip=10000000 seek=10000000 conv=noerror,sync

To make the rescue.dd.img equal size to the original (added 1.3TB), I ran truncate, which was instant unlike dd
truncate -s +1329705307136 rescue.dd.image

Then I ran
ntfsfix -f rescue.dd.img
But then I got error
> mount rescue.dd.img /media/windows
Failed to read last sector (2930272255): Invalid argument
HINTS: Either the volume is a RAID/LVM but it wasn't set up yet,
or it was not setup correctly (e.g. by not using mdadm --build ...).
or a wrong device is tried to be mounted,
or the partition table is corrupt (partition is smaller than NTFS),
or the NTFS boot sector is corrupt (NTFS size is not valid).
Failed to mount '/dev/loop0': Invalid argument
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

Thanks to this article I managed to mount the disk

sudo ntfs-3g -o force,rw rescue.dd.img /media/windows

Success!

Nagios NRPE check_disk complains .gvfs is not accessible Permission denied

We are using Nagios to monitor our desktop machines running Ubuntu 11.10. However, the check_disk compains DISK CRITICAL – /home/usr/.gvfs is not accessible Permission denied .

Also our servers are complaining because we had a tmpfs and udev mounted as read-only with 0% free space.

Then I found from this page fix for the problem. You need to add the following flags to your check_disk command:

command[check_disk]=/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ -X fuse.gvfs-fuse-daemon

and it works like a charm again!

Another approach found from this blog is to add

-A -i .gvfs

but then you can’t anymore use -X flag, and generally I find the -X file system type list better. You find out the file system types by command

root@server:/etc/nrpe# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/md3 ext3 987992 715116 223084 77% /
varrun tmpfs 208920 360 208560 1% /var/run
varlock tmpfs 208920 0 208920 0% /var/lock
procbususb usbfs 208920 272 208648 1% /proc/bus/usb
udev tmpfs 208920 272 208648 1% /dev
devshm tmpfs 208920 0 208920 0% /dev/shm
/dev/sdh1 ext3 3968468 143312 3625152 4% /boot
/dev/sdh3 ext3 7937056 148800 7388240 2% /tmp
/dev/sdi7 ext3 7588436 1719252 5486740 24% /usr
/dev/sdh5 ext3 14535584 1414540 12388484 11% /var
/dev/mapper/h ext3 284237628 64132532 217240152 23% /home
/dev/mapper/b ext3 1453591612 1152203976 286736288 81% /mnt/backup1
/dev/mapper/a ext3 1453591612 958723680 480216584 67% /mnt/backup2
backup@backup.:/mnt/backup1/incoming fuse.sshfs 1048576000 0 1048576000 0% /mnt/backup

By combining the non-wanted file system types from all the machines we have, I also added to the ignore list the following:

-X tmpfs -X udev -X usbfs -X fuse.sshfs -X fuse.gvfs-fuse-daemon

Editor Fascism to promote Pair Programming

At PHZ.fi we have been recently listing our software engineering practices to find out a better overview how we should improve our Extreme Programming process adoption. In 2008 we managed to reach a near perfect XP process by having 28.5/29 practices in use, evaluated by a bi-weekly self-assessment. On this week I added yet six more practices to the list, which were previously not listed or regarded as a practice, but were actively used.

Editor Fascism to promote Pair Programming

This is our latest addition to our process description, but it was actually taken in to use already in 2005. The idea of Editor Fascism is to force all developers to use the same development environment and especially text editor. When we started to use XP in 2004, the main obstacle for adopting pair programming was that each and every developer used his own text editor of choice. For example we had coders who preferred vim, others who were emacs -fanatics, I like pico/nano and Textpad (it’s the only editor that can open 1GB file in a second and not to crash that I know). Today we have people using Aptana studio, Netbeans etc. Anyway, the picture is clear: it is difficult to pass the keyboard to your pair if he doesn’t know vim commands, or if the vim -coder doesn’t know Netbeans shortcuts. While it would nice to learn how to use all editors, I thought that we receive a better ROI by investing in standardization of the routine tasks so that we can focus our learning energy to more complicated and value adding activities (such as test automation).

Our Editor Fascism currently means that all office development machines that are used for Pair Programming should have Eclipse installed and properly configured with all required plugins. We should have debugger working, a common configuration loaded with coding convention settings and auto-format, templates, common keyboard shortcuts etc. All programming must be done by using Eclipse, there are no alternatives. Period.

If you want to use another editor, you can not. That’s it. If you don’t like that it’s the reason why we call the practice Editor Fascism :)

In 2005 we quickly learned that this was a very quick way to promote pair programming, at least it abolished most of the technical and practical obstacles. Secondly I have noticed as a manager that the productivity of the team has simultaneously increased since everybody are using an advanced IDE instead of a basic text editor. Recently I have been also thinking about Zero Quality Control and Eclipse is a very good to provide the quickest possible Feedback cycle to prevent defects by providing immediate in-line syntax error warnings. By using a text editor it takes a minute or two to get the same feedback from the compiler, the browser or the server, which grinds down the development productivity on the small scale.

Eclipse A class file was not written. The project may be inconsistent, if so try refreshing this project and building it

For some time I have received this Java compile error in Eclipse Helios SP2

A class file was not written. The project may be inconsistent, if so try refreshing this project and building it MyClass.java
Unknown Java Problem

After Googling and some debugging I found out that this is caused by Eclipse having a 138 character limit (or something like that) for main class + inner class names. It might also be 256 character limit for the full path, I am not 100% sure. First I tested if it makes any difference whether you use OpenJDK or Sun JDK, but it had no difference. You can resolve the problem simply by making your inner class names shorter.

Coffea Chat released for Android

PHZ.fi submitted and published today the Coffea video communications application for the Ericsson Application Awards 2013 -competition. The application is targeted for elderly people and is running on Android API 16 tablets.

Please watch the introduction video:

The prototype is available for testing at the Play Market.

We’d like to hear your comments how do you like the app :)

Blockers First in Daily Scrum

Today we revised our Daily Stand Up Meeting practices. This is the same as the Daily Scrum i.e. 15minute meeting every morning to check out the current status of the project. We noticed that we should put the number one emphasis on blockers and always go through them first. You should go through the blockers first in daily scrum.

In Extreme Programming the Daily Stand up meeting the team should revise 1. what was accomplished (DONE) yesterday, 2. what will be attempted today (WIP) and 3. what problems are causing delays (Blockers).

In Scrum the daily scrum has the same meeting agenda, but the problems are called Impediments. I call Impediments and Problems as Blockers since they are things that block your progress, such as pending firewall requests, missing specification or instruction, some major bug, or missing feature developed by an external party not yet completed. According to my 10 year experience as project manager, I have realized that the blockers are almost always on the critical path of having the project completed, so the project management should be first made aware of them and secondly put all available effort and resources on them to resolve them in the quickest possible manner. Otherwise the whole team (from a few developers to hundreds) might be waiting without having much else to do, resulting in huge waste. Escalation of the blockers is always the number one task for the Project Manager.

Unfortunately there importance of blockers is many times not understood, and thus ignored. In almost all task management systems I have used at customer projects (such as Jira, Redmine, Trello etc) setting a task as a blocker (or impediment) is made very difficult or the functionality is well hidden in menus and thus not used. In many customer projects where Scrum or some other method is being used (PHZ.fi uses XP internally) I have noticed that even the official documentation might have omited from the daily scrum practice. For example this is a one real life example of the Daily Scrum -flow in use at one company:
Per task in WIP (in priority order)
1. Tell what you have DONE
2. Tell what you are going to do next (WIP)
3. Other things outside the task list
4. If you haven’t spoken out, do so now (so that everybody talks).

As you can note, there is no mention that the blockers should be separately mentioned, or that they have any particular importance. This real life example is also in stark contrast to the both Extreme Programming and Scrum official instruction. While both methods say that you should adapt the method to your own needs, it’s not a good practice to make the practices inferior to the original, if you don’t understand their meaning.

Thus, our conclusion was to revise the Daily Stand Up Meeting practice so that instead of going through DONE, WIP and Blockers, we go now it through in this order
1. Blockers
2. Done
3. WIP

To achieve this we had to actually redraw our Task Board columns to the same order, so that we have the Blockers first. Luckily we are using the http://tee.do Pure Lean Task Management Tool, which has the Blockers -column first by default, so this was easy to manage.

We noticed an immediate boost in our awareness of project status. The Blockers that had haunted us for weeks, vaporised almost instantly when attention was put on them. The project velocity also increased. We realized that going through the blockers first is a far superior method than the original order, so this change come to stay.

Usage of Private and Final in Java discouraged

Recently I got stuck on an old consideration of mine related to usage of private and final in Java. The Private -visibility declaration limits the methods’ or properties’ visibility to the class itself only, and declaring something as final prohibits declaration of any further sub-classes. Final might also allow some minor performance optimizations on some Java JDKs.

While this is not a programming language specific problem, I have learned since that declaring everything to final is almost considered as a best practice in Java (see http://www.javapractices.com/topic/TopicAction.do?Id=23 ). Eclipse often auto-suggests declaring variables as final, so it might seem like a good thing to do (but is not).

Personally I have thought about the usage of private and final in Java and Object Oriented programming, and found little use for them. Declaring methods or classes final makes code-reuse by inheritance difficult. Similarly the default usage of private makes code-reuse to require always a change to the super class (you need to re-declare it as protected). If you are using a framework or a library (such as Apache Wicket) with final classes or methods, or the java.lang.String, you might be out of luck unless you fork and recompile the whole dependency tree and related libraries. Thus, I personally strongly favor declaring everything as non-final and protected instead, by default. This leaves the future extensions and code re-use possibilities open, and doesn’t artificially undermine the core promises of Object Oriented programming (of code re-use and encapsulation).

The second downside of overly usage of privates and finals is making the unexpected future usages of your code much harder. Recently I got excited about LambdaJ and the possibility to use functional programming style in Java to make the iteration over Java Collections to look nicer and shorter. The rise of functional programming was probably not something that Java core architects or Apache Wicket’s developer had seen in advance when they initiated their projects. However, a major hindrance of the otherwise excellent LambdaJ library came from the Java practice of declaring everything as private and final in Java. For example you cannot use LambdaJs basic select() -operation to String, because it is declared as final. See my other article on LambdaJ. I hope that Java 8 brings some relief to this problem, but it is also a matter of coding convention.

Do not declare anything as final or private, unless there is a REALLY good reason for it. Use non-final methods and protected visibility instead.