Get informed about what the US government is trying to accomplish with SOPA and PIPA. Get involved and do what you can to prevent it from moving any further.
You may need a little humor after all of that reading. Head on over to (warning: NSFW language in certain areas) for a laugh.
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
If you want to forward e-mail from root to another user, you can usually place a .forward file in root's home directory and your mail server will take care of the rest:
echo "user@example.com" > /root/.forward
With SELinux, you'll end up getting an AVC denial each time your mail server tries to read the contents of the .forward file:
type=AVC msg=audit(1325543823.787:7416): avc: denied { open } for pid=9850
comm="local" name=".forward" dev=md0 ino=17694734
scontext=system_u:system_r:postfix_local_t:s0
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
The reason is that your .forward file doesn't have the right SELinux contexts. You can set the correct contest quickly with restorecon:
# ls -Z /root/.forward -rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 /root/.forward # restorecon -v /root/.forward restorecon reset /root/.forward context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:mail_forward_t:s0 # ls -Z /root/.forward -rw-r--r--. root root system_u:object_r:mail_home_t:s0 /root/.forward
Try to send another e-mail to root and you should see the mail server forward the e-mail properly without any additional AVC denials.
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
Before we get started, I really ought to drop this here:
Upgrading Fedora via yum is not the recommended method. Your first choice for upgrading Fedora should be to use
preupgrade. Seriously.
This begs the question: When should you use another method to upgrade Fedora? What other methods are there?
You have a few other methods to get the upgrade done:
rpm, and yum upgrade: This is the really old way of doing things. Don't try this (read the next bullet).yum's distro-sync functionality: If you can't go the preupgrade route, I'd recommend giving this a try. However, leave plenty of time to fix small glitches after it's done (and after your first reboot).Personal anecdote time (Keep scrolling for the meat and potatoes)
I have a dedicated server at (love those folks) with IPMI and KVM-over-LAN access. The preupgrade method won't work for me because my /boot partition is on a software RAID volume. There's a over on Red Hat's site about this problem. I'm really only left with a live upgrade using yum.
Live yum upgrade process
Before even beginning the upgrade, I double-checked that I'd applied all of the available updates for my server. Once that was done, I realized I was one kernel revision behind and I rebooted to ensure I was in the latest Fedora 15 kernel.
A good practice here is to run package-cleanup --orphans (it's in the yum-utils package) to find any packages which don't exist on any Fedora mirrors. In my case, I had two old kernels and a JungleDisk package. I removed the two old kernels (probably wasn't necessary) and left JungleDisk alone (it worked fine after the upgrade). If you have any external repositories, such as Livna or RPMForge, you may want to disable those until the upgrade is done. Should the initial upgrade checks bomb out, try adding as few repositories back in as possible to see if it clears up the problem.
Once you make it this far, just follow the instructions available in Fedora's documentation: . I set SELinux to permissive mode during the upgrade just in case it caused problems.
I'd recommend skipping the grub2-install portion since your original grub installation will still be present after the upgrade. If your server has EFI (not BIOS), don't use grub2 yet. Keep an eye on the previously mentioned documentation page to see if the problems get ironed out between grub2 and EFI.
Before you reboot, be sure to get a list of your active processes and daemons. After your reboot, some old SysVinit scripts will be converted into Systemd service scripts. They might not start automatically and you might need to enable and/or start some services.
New to Systemd? This will be an extremely handy resource: .
I haven't seen too many issues after cleaning up some daemons that didn't start properly. There is a problem between asterisk and SELinux that I haven't nailed down yet but it's not a showstopper.
Good luck during your upgrades. Keep in mind that Fedora 15 could be EOL'd as early as May or June 20102 when Fedora 17 is released.
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
Fedora 15 was released with some updates to allow for . Once it's installed, you'll end up with network devices that are named something other than eth0, eth1, and so on.
For example, all onboard ethernet adapters are labeled as emX (em1, em2...) and all PCI ethernet adapters are labeled as pXpX (p[slot]p[port], like p7p1 for port 1 on slot 7). Ethernet devices within Xen virtual machines aren't adjusted.
This may make sense to people who swap out the chassis on servers regularly and they don't want to mess with hard-coding MAC addresses in network configuration files. Also, it should give users predictable names even if a running system's drives are inserted into a newer hardware revision of the same server.
However, I don't like this on my personal dedicated servers and I prefer to revert back to the old way of doing things. Getting back to eth0 is pretty simple and it only requires a few configuration files to be edited followed by a reboot.
First, add biosdevname=0 to your grub.conf on the kernel line:
title Fedora (2.6.40.4-5.fc15.x86_64) root (hd0,0) kernel /boot/vmlinuz-2.6.40.4-5.fc15.x86_64 ro root=/dev/md0 SYSFONT=latarcyrheb-sun16 KEYTABLE=us biosdevname=0 quiet LANG=en_US.UTF-8 initrd /boot/initramfs-2.6.40.4-5.fc15.x86_64.img
Open /etc/udev/rules.d/70-persistent-net.rules in your favorite text editor (create it if it doesn't exist) and add in the following:
# Be sure to put your MAC addresses in the fields below
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:10", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:11", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
Be sure to rename your ifcfg-* files in /etc/sysconfig/network-scripts/ to match the device names you've assigned. Just for good measure, I add in the MAC address in /etc/sysconfig/network-scripts/ifcfg-ethX:
... HWADDR=00:11:22:33:44:10 ...
Reboot the server and you should be back to eth0 and eth1 after a reboot.
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
SELinux isn't a technology that's easy to tackle for newcomers. However, there's been a lot of work to smooth out the rough edges while still keeping a tight grip on what applications and users are allowed to do on a Linux system. One of the biggest efforts has been around .
The purpose behind setroubleshoot is to let users know when access has been denied, help them resolve it if necessary, and to reduce overall frustration while working through tight security restrictions in the default SELinux policies. The GUI frontend for setroubleshoot is great for users who run Linux desktops or those who run servers with a display attached. Don't worry, you can configure setroubleshoot on remote servers to send alerts elsewhere when a GUI alert isn't an option.
Install a few packages to get started:
yum install setroubleshoot{-server,-plugins,-doc}
Open /etc/setroubleshoot/setroubleshoot.conf in your favorite text editor and adjust the [email] section to fit your server:
recipients_filepath = /var/lib/setroubleshoot/email_alert_recipients smtp_port = 25 smtp_host = localhost from_address = selinux@myserver.com subject = [MyServer] SELinux AVC Alert
You could probably see it coming, but you need to put the e-mail addresses for your recipients into /var/lib/setroubleshoot/email_alert_recipients:
echo "selinux@mycompany.com" >> /var/lib/setroubleshoot/email_alert_recipients
You'll notice that setroubleshoot doesn't have an init script and it doesn't exist in systemd in Fedora 15. It runs through the and a quick bounce of the messagebus via its init script brings in the necessary components to run setroubleshoot:
service messagebus restart
A really easy (and safe) test is to ask sshd to bind to a non-standard port. Simply define an additional port on in your /etc/ssh/sshd_config like this:
Port 22 Port 222
When you restart sshd, it will bind to port 22 with success, but it won't be allowed to bind to port 222 (since that's blocked by SELinux as a non-standard port for the ssh_port_t port type). DON'T WORRY! Your sshd server will still be listening on port 22. If you wait a moment, you'll get an e-mail (perhaps two) that not only notify you of the denial, but they make suggestions for how to fix it:
SELinux is preventing /usr/sbin/sshd from name_bind access on the tcp_socket port 222. ***** Plugin bind_ports (99.5 confidence) suggests ************************* If you want to allow /usr/sbin/sshd to bind to network port 222 Then you need to modify the port type. Do # semanage port -a -t PORT_TYPE -p tcp 222 where PORT_TYPE is one of the following: ...
For this particular example, the quick fix would be to run:
semanage port -a -t ssh_port_t -p tcp 222
Much of this post's information was gathered from the detailed documentation on as well as .
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
I'm using SELinux more often now on my Fedora 15 installations and I came up against a peculiar issue today on a new server. My PHP installation is configured to store its sessions in memcached and I brought over some working configurations from another server. However, each time I accessed a page which tried to initiate a session, the page load would hang for about a minute and I'd find this in my apache error logs:
[Thu Sep 08 03:23:40 2011] [error] [client 11.22.33.44] PHP Warning: Unknown: Failed to write session data (memcached). Please verify that the current setting of session.save_path is correct (127.0.0.1:11211) in Unknown on line 0
I ran through my usual list of checks:
Even after all that, I still couldn't figure out what was wrong. I ran strace on memcached while I ran a curl against the page which creates a session and I found something significant — memcached wasn't seeing any connections whatsoever at that time. A quick check of the lo interface with tcpdump showed the same result. Just before I threw a chair, I remembered one thing:
SELinux.
A quick check for AVC denials showed the problem:
# aureport --avc | tail -n 1 4021. 09/08/2011 03:23:38 httpd system_u:system_r:httpd_t:s0 42 tcp_socket name_connect system_u:object_r:memcache_port_t:s0 denied 31536
I'm far from being a guru on SELinux, so I leaned on audit2allow for help:
# grep memcache /var/log/audit/audit.log | audit2allow #============= httpd_t ============== #!!!! This avc can be allowed using one of the these booleans: # httpd_can_network_relay, httpd_can_network_memcache, httpd_can_network_connect allow httpd_t memcache_port_t:tcp_socket name_connect;
The boolean we're looking for is httpd_can_network_memcache. Flipping the boolean can be done in a snap:
# setsebool -P httpd_can_network_memcache 1 # getsebool httpd_can_network_memcache httpd_can_network_memcache --> on
After adjusting the boolean, apache was able to make connections to memcached without a hitch. My page which created sessions loaded quickly and I could see data being stored in memcached. If you want to check the status of all of the apache-related SELinux booleans, just use getsebool:
# getsebool -a | grep httpd | grep off$ allow_httpd_anon_write --> off allow_httpd_mod_auth_ntlm_winbind --> off allow_httpd_mod_auth_pam --> off allow_httpd_sys_script_anon_write --> off httpd_can_check_spam --> off httpd_can_network_connect_cobbler --> off httpd_can_network_connect_db --> off httpd_can_network_relay --> off httpd_can_sendmail --> off httpd_dbus_avahi --> off httpd_enable_ftp_server --> off httpd_enable_homedirs --> off httpd_execmem --> off httpd_read_user_content --> off httpd_setrlimit --> off httpd_ssi_exec --> off httpd_tmp_exec --> off httpd_unified --> off httpd_use_cifs --> off httpd_use_gpg --> off httpd_use_nfs --> off
If you're interested in SELinux, a good way to get your feet wet is to head over to the CentOS Wiki and review their
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
Standard e-mail etiquette is pretty obvious to most of us and if you're good at it, you'll get your point across more often without stepping on toes or causing unneeded confusion. Simple things like identifying yourself well, avoiding sarcasm and adding context to statements are all extremely beneficial. However, writing e-mails to highly technical developers, system administrators, and engineers is a little trickier. These types of e-mail recipients don't really enjoy handling e-mail (inbound or outbound) and most find that e-mail is just a speed bump which interrupts their productivity.
If you're not technical, you might be asking yourself: «I need to e-mail technical people and they need to take what I say seriously? How do I do it?» It's not impossible, but the rest of this blog post should help.
There are some people who thrive on receiving e-mail, sending e-mail, and talking about e-mail that they've sent or received. Most nerds don't feel this way.
You need to get your point across concisely and succinctly so that your e-mail is seen as less of a distraction. Avoid adding a lot of context where it isn't needed and try to summarize business needs and processes unless details are absolutely critical. If you need to send your e-mail to multiple recipients and some of those recipients need additional details, provide an abstract at the beginning of the e-mail.
I've heard quite a few conversations like these around the office:
Nerd 1: "Did you get that e-mail from [name here]?
"
Nerd 2: "The six page one with four PDF files attached?
"
Nerd 1: "Yeah. That one.
"
Nerd 2: "TL;DR dude, seriously. Did you read it?
"
Nerd 1: «Nah. I might read it later.»
If someone's ever mentioned «TL;DR» (too long; didn't read) when your e-mail was mentioned, don't fret. It's a quick fix. Just add a quick summary to the top of your e-mail prefaced with «TL;DR». Provide a really brief summary (bulleted lists are a plus) of your e-mail in the section and then start your e-mail right afterwards. Here's an example:
TL;DR * next software release deploys Monday * two bugs remaining to fix * we will get started at 8AM Saturday, yeaaaaah
Missed the joke? .
If one of the summary points interests a recipient, they'll scan your e-mail for the pertinent sections. Some recipients may only need to see what's in the summary and they won't bother reading the remainder. Either way, the effectiveness of your e-mail increases by leaps and bounds.
Users of mutt prefer plain text e-mails
If you only take away one thing from this entire post, let it be this section. Writing e-mails in plain text is *highly recommended* if you want a technical person to take your e-mail seriously. Many system administrators I know use , a text-based console-only e-mail reader. Click the thumbnail at the right and imagine what your e-mails would look like if they're full of images, stylesheets and background images. Better yet, imagine if your entire e-mail was in an image and the e-mail itself had no text.
Here are a few more tips under this category:
Brevity can definitely be applied to e-mail signatures, too. How many times have you seen e-mails that end like this:
Frank Frankelton MCSE, RHCSA, RHCE, CCNA, RHCA, LPIC-3, Ph.D., M.D., Esq., CMDBA Systems Adminstrator Extraordinaire, Database Administrator, All-around great guy Office: 210-555-1212 Mobile: 210-555-1213 Other Mobile: 210-555-1214 Fax: 210-555-1215 VOIP: 210-555-1216 AIM: frankeltonia Twitter: @frankyfrank Jabber: frankfurter@frankeltonisinthehouse.com Big Company, Inc
You might think that nobody would ever send out e-mails with a signature like the one above, but I've seen some that are actually worse. Keep the signature short and only put in the information that people really need to know. Generally, your name and title or department is sufficient for e-mail signatures (unless your local/federal laws require otherwise). Always preface it with a double dash «--» on a line by itself to signify that the remainder of the e-mail is the signature.
Keep it simple, keep it brief, and keep it relevant. While the suggestions above might not apply to every business or every person, following the suggestions will increase the effectiveness of your e-mails and ensure that your voice is heard on the other end.
I'm really interested to hear your comments. Are there some suggestions you have that I missed in the post? Did I make some suggestions which didn't make sense or don't apply to you? Let me know!
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
Before I get started, I'd like to give a big thanks to all of the visitors who dropped by and last week. Also, thanks to for offering to pay for (and double) one of the prizes!
Here are the list of winners:
with me since much of a sysadmin's job involves responding to crises regardless of how much planning you put forth:
Keep a cool head. Focus. Work methodically. Figure out what to do and get it done, and people will remember you as the person who performs under pressure. Once you can do that, you're a sysadmin.
about system administration:
Tell the truth. If you break something, 'fess up and fix it. If you don't know how to do something, admit it and learn how to do the task. Create your own culture of honesty on the job; others will respect and follow your example.
for system administrators stuck in frustrating situations:
I know, I know — dumb users, RTFM. Believe me, I've been there. In fact — one of your strategies should be to establish a trusted community where you can VENT about these issues, and get support for yourself. Ask for answers when you don't know them. Restock on the compassion and patience.
and what every system administrator should know to get started in a career. We probably take this for granted, but this is critical to keep in mind:
If you are starting in the system administration area, don't praise yourself only because you (blindly?) fixed an issue or helped that friend with his/her server. Ask yourself: Why what I did fixed the issue? Why that was happening in the first place? And more importantly, how to avoid it for all eternity? You won't but it doesn't hurt to aim high.
Even though it isn't a runner-up, certainly deserves an honorable mention. His comment is actually a true story (with a slight amount of embellishment, of course) and it serves as a reminder that system administrators and developers must stand up for their beliefs even if it goes against the beliefs of their superiors. If your managers don't value the feedback, it might be a sign that a career change is in order.
Once again, a big thanks goes out to everyone who submitted a comment. I'll reach out to the winners today and get the gift certificates sent out to them.
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
Quite a few people who couldn't make it to this year asked me to write a post summarizing my takeaways from the event. I'm not generally one to back down from peer pressure, so read on if you're interested about the discussions at this year's Summit.
The feeling I had at last year's summit is that Xen was on the verge of losing traction in the market. Very few distributions still had Xen support going forward and much of the discussion was around the lack of dom0 support in upstream Linux kernels. Distribution vendors were hesitant to drag patches forward into modern kernels and this made it much more difficult to get Xen working for many people.
This year was quite different. The number of attendees was up, the , and there was an obvious buzz of energy in the room. As many of the presenters noted, this excitement stemmed from the . This inclusion is a huge win and it helps to drive Xen forward since the developers don't have to worry about dragging patches forward. They can focus on improving performance, adding features, and tightening security.
Many of the discussions this year focused on security and performance. Ian Pratt discussed Xen's ability to view memory pages of virtual machines via an API to detect malware running inside the instance. Memory pages could be identified and marked as not executable or applications could be triggered when a VM attempts to touch a particular memory page. Also, the whole VM could be frozen if needed.
There's also a big push to bring code out of the dom0 and push it into utility VM's. Driver domains could manage the network or I/O infrastructure and this would further reduce the amount of privileged code actively running in dom0. There is already very little code required for the Xen hypervisor itself (much much less than the Linux kernel — I'm looking at you, ) and this reduces the attack surface for potential compromises of the hypervisor. Some projects even aim to restart driver domains multiple times per minute to ensure that any malicious code injected into those virtual machines can't exist for long periods.
Pradeep Vincent from talked about how Amazon uses Xen and the pain points they have with its current architecture. Much of his discussion was around scaling problems (and we see many of the same issues at ). Higher performance could easily be gained by multi-threaded operations in dom0 when attaching block devices and creating virtual network interfaces. He also saw some areas for performance gains in the pvops I/O code.
Quite a few of the talks centered on the ARM architecture and what Xen is able to do on those systems after . HVM is on the way for ARM and it might even show up in Xen 4.2. Some demos of Xen on mobile phones from Samsung were amazing. They showed how an attacker could compromise the web browser on the phone with a keylogger, but that application was running in a VM. Once the user switched back to the phone's main menu, the keylogger couldn't access the keystrokes any longer. After that, a simple close of the browser killed the VM and destroyed the malicious code.
Xen 4.2 should be available in early 2012 and the feature list is staggering. Improvements to libxenlight, pvops performance (even in HVM), and guest memory sharing should be available with the new release. Nested virtualization (run a hypervisor inside a hypervisor) is also coming in Xen 4.2 and I'm sure Xzibit will be a huge fan. This should streamline hypervisor testing, allow for embedded hypervisor options and extend the capabilities of client hypervisors. Remus should be available in 4.2 as well, but it might be marked as experimental. OVMF will be added as a BIOS option for UEFI (along with the standard SeaBIOS) and this should allow for Mac OS X guests. UEFI allows Windows to boot faster since it switches to PV mode sooner and it allows for simpler platform certification for software vendors.
Mike McClurg's presentation on was pretty important to me since Rackspace is a big consumer of . If you're not familiar with XCP, it's basically open-source XenServer which runs on bleeding edge (and sometimes unstable) components. XCP 1.5 and XenServer 6 should be available in November with Xen 4.1 and Linux 2.6.32. GPU passthrough, up to 1TB RAM, and disaster recovery will be available. Another goal for the XCP team is to work closely with OpenStack via Project Olympus. Mike's vision is to have XCP become the configuration of choice for open source clouds. was also extremely interesting. It's essentially XCP's XenAPI stack running on Debian and Ubuntu. You'd be able to install either OS on a physical server and run XCP's services on it for a fully OSS hypervisor.
Konrad Wilk gave an update on Linux pvops and it appears there is a shift to get Xen working well on a desktop. This includes 3D graphics support, S3/hibernate capabilities and various bug fixes. There's also a push to get PV functionality into HVM and get HVM functionality into PV. Driver/device domains were discussed again in Patrick Kolp's talk and he had plenty of graphs showing performance changes when regularly restarting device domains. The performance dips were almost negligible with 10 second restarts and the security gains were significant.
There were several other great presentations on other topics like , , and (from the NSA!). If these types of things interests you, keep your eyes peeled for Xen Summit 2012 next year. The is well worth the trip. 
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
If you haven't noticed already, was added in the . This means there's no longer a need to drag patches forward from old kernels and work from special branches and git repositories when building a kernel for .
Something else you might not have noticed is that the Fedora kernel team has into Fedora 15's update channels in disguise. Click that link, scroll down, and you'll see «Rebase to 3.0. Version reports as 2.6.40 for compatibility with older userspace.» Although I'm not a fan of calling something what it isn't (2.6.40 doesn't exist on kernel.org), I can understand some of the reasoning behind the choice.
This change makes the Xen installation on Fedora 15 pretty trivial. To get started, update your kernel to the latest if you're not already on Fedora's 2.6.40 kernels:
yum -y upgrade kernel
We need three more packages (quite a few dependencies will roll in with them):
yum -y install xen libvirt python-virtinst
The xen package reels in the hypervisor itself along with libraries and command line tools (like xl and xm). Libvirt gives us easy access to VM management with the virsh command and python-virtinst gives us the handy virt-install command to make OS installations easy.
Once those packages are installed, we need to make some adjustments in your grub configuration. Open /boot/grub/menu.lst in your text editor of choice and add something like this at the bottom:
title Fedora + Xen (2.6.40-4.fc15.x86_64)
root (hd0,1)
kernel /boot/xen.gz
module /boot/vmlinuz-2.6.40-4.fc15.x86_64 ro root=/dev/sda1
module /boot/initramfs-2.6.40-4.fc15.x86_64.img
Ensure that the root (hd0,1) is applicable to your system (adjust it if it isn't). Also, check the kernel version to ensure it matches your installed kernel and adjust the root= portion to match your root volume. Flip the default line to a value which will boot your new grub entry and ensure the timeout is set to a reasonable number if you need to temporarily switch back to your original grub entry at boot time. (Hey, we all make mistakes.)
I take one extra precaution and change the UPDATEDEFAULT=yes line to no in /etc/sysconfig/kernel. This ensures that future kernel updates don't trample the entry you've just made. Keep in mind that you'll need to manually update your grub configuration when you do kernel upgrades later.
Cross your fingers and reboot. If your system doesn't reboot properly, reboot it again and choose your old kernel from the grub menu. Double-check your configuration for fat-fingering and give it another try. If your system boots and pings but you have no output via a monitor, don't fret. There's a for the problem which in Linux 3.0. The impatient can snag a kernel source RPM, add the patch file, and (or you can from when I did it).
Log in and verify that you booted into the dom0:
[root@xenbox ~]# xm dmesg | head -n 5 __ __ _ _ _ _ ____ __ _ ____ \ \/ /___ _ __ | || | / | / | |___ \ / _| ___/ | ___| \ // _ \ '_ \ | || |_ | | | |__ __) | | |_ / __| |___ \ / \ __/ | | | |__ _|| |_| |__/ __/ _| _| (__| |___) | /_/\_\___|_| |_| |_|(_)_(_)_| |_____(_)_| \___|_|____/
Once you're done with that, make sure libvirtd is running:
/etc/init.d/libvirtd start; chkconfig libvirtd on
Try installing a VM:
virt-install \ --paravirt \ --name=testvm \ --ram=512 \ --vcpus=4 \ --file /dev/vmstorage/testvm \ --graphics vnc,port=5905 --noautoconsole \ --autostart --noreboot \ --location=http://mirrors.kernel.org/debian/dists/squeeze/main/installer-amd64/
You should have a VM installation underway pretty quickly and it will be visible via port 5905 on the local host. Enjoy the power and freedom of your brand new .
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.