Mind Download
Tuesday, September 7, 2010
Common problems when trying to install Windows on KVM with virt-manager
September's issue of the Linux Gazette is out. My article this month is about running Windows on KVM w/ virt-manager. Enjoy.
Labels:
kvm,
linux,
linuxgazette,
windows
Tuesday, August 10, 2010
MindUpload: CPU Load Average
Today's mindupload will be a citation because I don't think I'd be able to write up a better explanation on CPU load average than this guy, check it out: http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
The wikipedia entry is pretty good too.
The wikipedia entry is pretty good too.
Labels:
linux,
mindupload
Monday, August 9, 2010
MindUpload: kill command
If you've used a Unix or Unix-like operating system, you've probably heard of (even used) the kill command.
The kill command is basically a cli interface to the kill() system call, and it basically sends a signal to a running process. The types of signals are defined on the signal header file (signal.h) under the linux operating system (in Fedora I found it under /usr/include/asm/signal.h instead of /usr/include/linux/signal.h as part of the kernel-headers RPM) or you can list them by running kill -l.
Since I can remember using Linux, I've used the kill command in 3 different ways:
kill SOME_PID
SIGTERM is the default signal if you don't pass the signal number to the command, it will send signal 15, which requests the process to terminate, if the process doesn't terminate, than we usually have to force it with:
kill -9 SOME_PID
The above sends the SIGKILL signal that forces the application to terminate right now.
kill -1 SOME_PID
The -1, aka SIGHUP, is a signal sent to an application when a terminal closes, but if the application does "not require a controlling terminal, such as daemons, would re-purpose SIGHUP as a signal to re-read configuration files, or reinitialize. This convention survives to this day in packages such as Apache and Sendmail." Source: http://en.wikipedia.org/wiki/SIGHUP -- Being that reloading config files was the main reason I've used -1 for.
The interesting part about all this is that one can write an application to intercept theses signals from the kill command when sent to it and do different things with it other than actually 'killing' the process. The only 2 signals that cannot be intercepted are: SIGTERM (15) and SIGKILL (9).
The kill command is basically a cli interface to the kill() system call, and it basically sends a signal to a running process. The types of signals are defined on the signal header file (signal.h) under the linux operating system (in Fedora I found it under /usr/include/asm/signal.h instead of /usr/include/linux/signal.h as part of the kernel-headers RPM) or you can list them by running kill -l.
[ansilva@carioca ~]$ kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
...
Since I can remember using Linux, I've used the kill command in 3 different ways:
kill SOME_PID
SIGTERM is the default signal if you don't pass the signal number to the command, it will send signal 15, which requests the process to terminate, if the process doesn't terminate, than we usually have to force it with:
kill -9 SOME_PID
The above sends the SIGKILL signal that forces the application to terminate right now.
kill -1 SOME_PID
The -1, aka SIGHUP, is a signal sent to an application when a terminal closes, but if the application does "not require a controlling terminal, such as daemons, would re-purpose SIGHUP as a signal to re-read configuration files, or reinitialize. This convention survives to this day in packages such as Apache and Sendmail." Source: http://en.wikipedia.org/wiki/SIGHUP -- Being that reloading config files was the main reason I've used -1 for.
The interesting part about all this is that one can write an application to intercept theses signals from the kill command when sent to it and do different things with it other than actually 'killing' the process. The only 2 signals that cannot be intercepted are: SIGTERM (15) and SIGKILL (9).
Labels:
kill,
linux,
mindupload
Sunday, August 8, 2010
MindUpload: Hubs vs Switches
Yes... embarrassing. Hubs and Switches. Someone asked me what the difference was between the two network devices, and the only thing that went through my mind was: "A dumb device." The second thought was: "Don't ask me, just Google for it..."
That's when it hit me: Yes, using Google to look up information is great, but should I be so dependent on it that I am unable to answer such a basic networking question?"
And that is why I decided to start writing 'mindupload' notes to myself... So, here's what I learned (re-learned, actually, since I learned this in College, and eventually forgot).
A hub takes data (aka packets) arriving at the incoming port, and transmits it to all outgoing ports with a connected device to it. If more than one computer receives the data and try to respond, it could generate network collisions because they are responding to the same data at the same time, this could slow down your network due to processing of the collision and re-transmission of the data. Related to this same issue, the network devices connected to the hub will be running in half-duplex mode because they have to be constantly listening for data collisions, which means, they can't send and receive data at the same time. Think of it like a walkie-talkie where one person can either talk or listen at a time, instead of full-duplex, which is like a telephone. And the reason for the devices to be running in half-duplex mode is because they have to be listening for collisions on the network.
A network switch on the other hand, uses an internal table that keeps track of the connected network devices addresses and its ports, and by reading the headers of the incoming data it creates temporary connections between the source and destination ports eliminating collisions on the network, and decreasing traffic overhead, therefore allowing network devices to work in full-duplex mode, since they don't have to listen for collisions any longer... Giving you a more efficient (faster) network.
That's when it hit me: Yes, using Google to look up information is great, but should I be so dependent on it that I am unable to answer such a basic networking question?"
And that is why I decided to start writing 'mindupload' notes to myself... So, here's what I learned (re-learned, actually, since I learned this in College, and eventually forgot).
A hub takes data (aka packets) arriving at the incoming port, and transmits it to all outgoing ports with a connected device to it. If more than one computer receives the data and try to respond, it could generate network collisions because they are responding to the same data at the same time, this could slow down your network due to processing of the collision and re-transmission of the data. Related to this same issue, the network devices connected to the hub will be running in half-duplex mode because they have to be constantly listening for data collisions, which means, they can't send and receive data at the same time. Think of it like a walkie-talkie where one person can either talk or listen at a time, instead of full-duplex, which is like a telephone. And the reason for the devices to be running in half-duplex mode is because they have to be listening for collisions on the network.
A network switch on the other hand, uses an internal table that keeps track of the connected network devices addresses and its ports, and by reading the headers of the incoming data it creates temporary connections between the source and destination ports eliminating collisions on the network, and decreasing traffic overhead, therefore allowing network devices to work in full-duplex mode, since they don't have to listen for collisions any longer... Giving you a more efficient (faster) network.
Labels:
mindupload,
networking
Introducing MindUpload
During the past few weeks, I've found myself in 2 or 3 situations where someone asked me a somewhat technical question, and I struggled so hard trying to answer and even having to admit that I couldn't recall the answer.
I was ashamed of myself.
Unlike riding a bike, information sometimes can be easily forgotten specially if you don't use it often enough. So, I've decided to start writing up technical notes to myself on this blog.
I will not discriminate between complex or trivial notes. I will try to keep them short, and I will always read up about the subject before writing about it, but I will always write using my own words. If I quote, I will cite sources. If I make I mistake, I expect you to leave a comment.
All posts related to this idea will be tagged as: mindupload.
I was ashamed of myself.
Unlike riding a bike, information sometimes can be easily forgotten specially if you don't use it often enough. So, I've decided to start writing up technical notes to myself on this blog.
I will not discriminate between complex or trivial notes. I will try to keep them short, and I will always read up about the subject before writing about it, but I will always write using my own words. If I quote, I will cite sources. If I make I mistake, I expect you to leave a comment.
All posts related to this idea will be tagged as: mindupload.
Labels:
mindupload
Sunday, August 1, 2010
Linux Gazette: Goodbye iPhone, Hello Palm Pre Plus
Labels:
article,
iphone,
linux,
linuxgazette,
palmpreplus,
webos
Wednesday, July 28, 2010
'That's It!' for WebOS version 1.0.3
The Changelog:
1.0.3
- The 'stop' function is now 'pause' therefore the scene doesn't start from scratch every time the button is pressed.
- New app icon
- When the audio is over the button resets itself so it can be played again.
1.0.2
- New version has dynamic play/stop button. Silly, but it took some time to figure out how to do it exactly how I wanted it :-)
App URL: http://www.precentral.net/homebrew-apps/thats-it
1.0.3
- The 'stop' function is now 'pause' therefore the scene doesn't start from scratch every time the button is pressed.
- New app icon
- When the audio is over the button resets itself so it can be played again.
1.0.2
- New version has dynamic play/stop button. Silly, but it took some time to figure out how to do it exactly how I wanted it :-)
App URL: http://www.precentral.net/homebrew-apps/thats-it
Labels:
linux,
palmpreplus,
webos
Sunday, July 25, 2010
'That's it!' app for Palm Pre Plus available on Preware
I added the app to the PreCentral.net store, which makes it show up under Preware!
The app: http://www.precentral.net/homebrew-apps/thats-it
The app: http://www.precentral.net/homebrew-apps/thats-it
Labels:
palmpreplus,
webos
Windows XP KVM guest on Fedora 13 No Sound Solution
I don't know how long I've been trying to get sound working on my Windows guest under KVM. It's been at least one year (at least since Fedora 11). I 'googled' here, I 'googled' there, I found a lot of people having issues, and a lot of half-assed answers that never really solved my problem.
My biggest problem was that I kept trying to get sound working using VNC as the Virtual Display. I decided to switch to SDL instead, and sound worked great.
Here's what I've done:
First I tried to follow these directions:
https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#SDL_Graphics
You may encounter the issue where your $XAUTHORITY is a file under a session based directory like this: /var/run/gdm/auth-for-ansilva-4kdkMG/database
Therefore, you would probably have set the permissions described on that file every time you reboot on your machine.
What I ended up doing was to edit the /etc/libvirt/qemu.conf, and get qemu-kvm to run as my user:
user = "ansilva"
group = "ansilva"
Then, I did the following:
1. Turn off selinux. (edit /etc/selinux/config and reboot) # or set selinux to permissive
2. Restart libvirtd.
3. Under virt-manager, remove your "Display 0".
4. Still under virt-manager, add a new "Display 0" (called 'Graphics' under 'Add Hardware'), choose Type: Local SDL window
Sound just works now, and I can watch Netflix on my laptop.
Getting Windows XP installed on KVM under Fedora 13 + virt-manager
On a separate note, if you try to install Windows XP via virt-manager, and have an issue after the installation that VM can't boot, the way to fix that is by creating your disk image using the qcow2 format. It worked for me.
Oh, and to get better Resolution selection under windows, use the 'VGA' graphics driver, instead of whatever else virt-manager picks for you automatically.
My biggest problem was that I kept trying to get sound working using VNC as the Virtual Display. I decided to switch to SDL instead, and sound worked great.
Here's what I've done:
First I tried to follow these directions:
https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#SDL_Graphics
You may encounter the issue where your $XAUTHORITY is a file under a session based directory like this: /var/run/gdm/auth-for-ansilva-4kdkMG/database
Therefore, you would probably have set the permissions described on that file every time you reboot on your machine.
What I ended up doing was to edit the /etc/libvirt/qemu.conf, and get qemu-kvm to run as my user:
user = "ansilva"
group = "ansilva"
Then, I did the following:
1. Turn off selinux. (edit /etc/selinux/config and reboot) # or set selinux to permissive
2. Restart libvirtd.
3. Under virt-manager, remove your "Display 0".
4. Still under virt-manager, add a new "Display 0" (called 'Graphics' under 'Add Hardware'), choose Type: Local SDL window
Sound just works now, and I can watch Netflix on my laptop.
Getting Windows XP installed on KVM under Fedora 13 + virt-manager
On a separate note, if you try to install Windows XP via virt-manager, and have an issue after the installation that VM can't boot, the way to fix that is by creating your disk image using the qcow2 format. It worked for me.
Oh, and to get better Resolution selection under windows, use the 'VGA' graphics driver, instead of whatever else virt-manager picks for you automatically.
Labels:
fedora 13,
kvm,
linux,
virt-manager,
virtualization
Thursday, July 22, 2010
'That's it! Back to Winnipeg!' App for the Palm Pre Plus
I wrote my first WebOS application today. I called it: "That's it!' and it is basically a silly little sound player that plays one of my favorite 'The Simpsons' scene ever.
Download it at: http://n07.us/s/Il
I've sent a request to PreCentral.net and see if they will let me submit my crummy app to Preware. Let's see what happens.
The framework itself is pretty sweet, and somewhat intuitive, but I found the documentation on the Palm website somewhat poor and confusing.
Developed the app on Fedora 13 using Palm's Plugin for Eclipse.
Download it at: http://n07.us/s/Il
I've sent a request to PreCentral.net and see if they will let me submit my crummy app to Preware. Let's see what happens.
The framework itself is pretty sweet, and somewhat intuitive, but I found the documentation on the Palm website somewhat poor and confusing.
Developed the app on Fedora 13 using Palm's Plugin for Eclipse.
Labels:
palmpreplus,
programming,
webos
Subscribe to:
Posts (Atom)