The 2014 edition of KVM Forum is less than a week away. The schedule of the talks is available at this location. Use this link to add the schedule to your calendar. A few slides have already been uploaded for some of the talks.
As with last year, we’ll live-stream and record all talks, keep an eye on the wiki page for details.
One notable observation about the schedule is that it’s much relaxed from the last few years, and there are far fewer talks in parallel this time around. There’s a lot of time for interaction / networking / socializing. If you’re in Dusseldorf next week, please come by and say ‘hello!’
I participated in the OpenStack Meetup at the Red Hat Pune office a few weekends ago. I have been too caught up on the lower-level KVM/QEMU layers of the virt stack, and know there aren’t too many people involved in those layers in Pune (or even India); and was curious to learn more about OpenStack and also find out more about the OpenStack community in Pune. The event was on a Saturday, which means sacrificing one day of rest and relaxation – but I went along because curiousity got the better of me.
This was a small, informal event where we had a few talks and several hallway discussions. Praveen has already blogged about his experiences, here are my notes about the meetup.
The KVM Forums are a great way to learn and talk about the future of KVM virtualization. The KVM Forum has been co-located with the Linux Foundation’s LinuxCon events for the past several years, and this year too will be held along with LinuxCon EU in Dusseldorf, Germany.
The KVM Forums also are a great documentation resource on several features, and the slides and videos from the past KVM Forums are freely available online. This year’s Forum will be no different, and we’ll have all the material on the KVM wiki.
For a long time various people have been telling me there’s not much information on the low-level / plumbing details of the virt stack on Linux. Especially information related to qemu and its various settings, devices, and so on.
Documentation surely is difficult to come by, but a quick and straightforward solution is to syndicate all of the blog posts that people doing virt development write into a common stream: a planet virt. I started hosting and testing such an instance on openshift, but was quickly pointed to the existing Virt Tools Planet by Rich Jones and Dan Berrange. Dan added the list of people whose blogs I followed for virt development to that instance.
I updated the KVM and QEMU wikis to ensure the Planet gets more visibility, and hope this goes a small way to quell the complaints of not enough available information.
The Linux Plumbers Conf wiki seems to have made the discussion notes for the 2012 conf read-only as well as visible only to people who have logged in. I suspect this is due to the spam problem, but I’ll put those notes here so that they’re available without needing a login. The source is here.
Several applications need random numbers for correct and secure operation. When ssh-server gets installed on a system, public and private key paris are generated. Random numbers are needed for this operation. Same with creating a GPG key pair. Initial TCP sequence numbers are randomized. Process PIDs are randomized. Without such randomization, we’d get a predictable set of TCP sequence numbers or PIDs, making it easy for attackers to break into servers or desktops.
On a system without any special hardware, Linux seeds its entropy pool from sources like keyboard and mouse input, disk IO, network IO, and any other sources whose kernel modules indicate they are capable of adding to the kernel’s entropy pool (i.e .the interrupts they receive are from sufficiently non-deterministic sources). For servers, keyboard and mouse inputs are rare (most don’t even have a keyboard / mouse connected). This makes getting true random numbers difficult: applications requesting random numbers from /dev/random have to wait for indefinite periods to get the randomness they desire (like creating ssh keys, typically during firstboot.).
I’ve been using the Fedora 18 pre-release for a couple of months now, and am generally happy with how it works. I filed quite a few bugs, some got resolved, some not. Here’s a list of things that don’t work as they used to in the past, with workarounds so they may help others:
Avi Kivity announced he is stepping down as (co-)maintainer of the KVM Project at the recently-concluded KVM Forum 2012 in Barcelona, Spain. Avi wrote the initial implementation of the KVM code back at Qumranet, and has been maintaining the KVM-related kernel and qemu code for about 7 years now.
The 2012 edition of the Linux Plumbers Conference concluded recently. I was there, running the virtualization microconference. The format of LPC sessions is to have discussions around current as well as future projects. The key words are ‘discussion’ (not talks — slides are optional!) and ‘current’ and ‘future’ projects — not discussing work that’s already done; rather discussing unsolved problems or new ideas. LPC is a great platform for getting people involved in various subsystems across the entire OS stack in one place, so any sticky problems tend to get resolved by discussing issues face-to-face.
Updating a Fedora 16 guest to a Fedora 17 guest via preupgrade gave me the ‘Oh no, something has gone wrong!’ screen at the GDM login screen. It’s quite frustrating to see that screen because you can’t switch to a virtual terminal for troubleshooting, or even reboot or shutdown.
To send the key sequence Ctrl+Alt+F2 to the guest to switch to a virtual terminal, use the qemu monitor by pressing
and use sendkey to send the key sequence:
(qemu) sendkey ctrl-alt-f2
Then go back to the guest window by issuing
After logging in as root, I poked in the gdm log files in /var/log/gdm/ and saw the fprint daemon was causing some errors. Removing the fprintd package fixed this, but this is just a workaround, not a solution: