FUDCon India F2F Planning Meeting Minutes (Jul 26 2011)

In this edition of the planning meeting, Suchakra joined us at the Red Hat Pune office.  The others present were Rahul, PJP, Sathya, Shreyank, Saleem, Shakthi and me.

Having Suchakra attend the meeting was great, we made some good progress on the venue-related items that we needed some greater clarity on.

He clarified the bandwidth would be sufficient for our usage, identified a few students as volunteers (we will meet them soon), mentioned setting up a public Fedora mirror would not be difficult at all (bandwidth and storage are amply available).  All this is great news, and he’s also going to be around for the next 2 months to co-ordinate with any other venue-related matters.

Logs:

  • FUDCon website
    • Owner: Saleem
    • Most work has been done
    • Needs help from Rahul, Suchakra on content
    • Needs help from Tatica on design
    • Final website will be at: http://fudcon.fedoraproject.org
  • Catering
    • Owner: PJP
    • Got couple of more contacts from Murty
    • Will follow up with them this week
  • Hotel
    • Finalising between two options: Cocoon (within Magarpatta City, very close to Red Hat office) and Royal Orchid in Kalyani Nagar
    • Costs $40 (Cocoon) vs $90 (Royal Orchid)
    • We have a better deal with Cocoon: in addition to a special rate, we are also getting
      • laundry
      • breakfast
      • wi-fi
      • mineral water
      • better rate for FUDPub venue
  • Bus
    • More than one may be required depending on people
  • FUDPub
    • Don’t know rates yet
    • Will be decided this week
    • Min. legal drinking age in Maharashtra is 25.  How to filter people?
    • Microbrewery can supply beer at our chosen venue.
      • Deal has to be worked out such that we pay only for what we consume
  • Information on website (plus booklet)
    • Photos
      • Cocoon (accomodation)
      • Magarpatta city
      • FUDPub venue
      • COEP (event venue)
  • Videos
    • Shreyank didn’t receive input from Shravan at COEP
    • Rahul to follow up with PyCon people
  • Artwork
    • 3rd week of August deadline for 1st draft of all designs
      • t-shirts, posters, banners, website, etc.
  • Bandwidth
    • PJP hasn’t spoken with BSNL people yet
    • Suchakra mentions bandwidth at venue is sufficient (with failover)
      • Recent MITConf served 100 people without glitches
  • Volunteer team
    • Shravan will be heading team
    • Shravan handles routers and infrastructure at COEP
    • Suchakra and Shravan to perform a mock install
    • Saleem and Shravan to run a test install 1 month prior to event
      • Checking router capacity, bandwidth, plug points, etc.
  • Fedora Mirror
    • Owner: Suchakra, Rahul, Saleem
  • Canteen
    • Already open on Fri/Sat. Suchakra will confirm if they can stay open on Sunday
    • Can we host outside caterers at the venue (canteen or outside)? – Suchakra to confirm.
  • Scheduling FADs before FUDCon
    • Owners: Rahul, Shakthi
    • Oct 1st week and Oct end won’t clash with exam schedule
    • Suchakra says we can expect about 60 people
    •  Talk to Prof. Abhijit about this — Suchakra + Rahul
    • These FADs will be prep sessions for the FUDCon
      • Introduce Fedora terminology
      • Introductory / basic material as prelude to talks at FUDCon for the benefit of students
  • Sponsorship requests
    • Rahul officially opened sponsorship window.  Requests pouring in.
    • Deadline of Aug 5, can be extended depending on budget.
    • Review of requests will be done after the deadline
  • Content
    • This now takes 1st priority
    • Rahul to update wiki with hotel info
    • COEP pictures to be uploaded by Suchakra
    • Fill in all details; booklet data can be scraped from website.
  • COEP
    • Organisers to visit venue and meet student volunteers, prof Abhijit sometime in the next 1-2 weeks
    • Figure out which rooms are being allocated to us, check distance between them
    • Power point availability in the auditorium, labs and talk rooms
    • Backup power status
      • Projectors, wifi continue to work in case of power cut?

FUDCon India 2011 F2F Meeting 2

The second face-to-face meeting for the FUDCon India planning happened on Tuesday, July 19 at the Red Hat India office.

Shreyank, Saleem, Rahul, Satya, PJP, Kushal, Shakthi and me were present.

Discussion took off from where we were last time and what still needs to be done.  In addition, we now have tentative dates to get feedback on all outstanding items:

  • Confirmation on speakers flying in from outside India (who we are sponsoring)
    • Owner: Rahul
    • Few people have applied for sponsorships, including Kital, Eugene Teo, Buddhika Kurera.
    • We have to get word out to these and others who are considering flying in to book flights ASAP to get better deals.

 

  • Not everyone is blogging about the work they’re doing.
    • In addition to keeping everyone apprised of the situation, also helps future FUDCon planners to see what’s involved.

  • 1st priority: book hotels.
    • Murty is talking to vendors for deals.  He will have concrete answers by Thursday Jul 21st.

 

  • Visas
    • Items we can give guidance on / items required for obtaining a visa:
      • India gives visa on arrival for nationals of 16 countries.
      • Duration of stay?
      • Who can vouch for the individual?
      • Where will he/she stay?
      • Conference visas and tourist visas might be different for some countries
      • Ppreventive medication may be required.
    • Items we have to assist with:
      • Invitation letter
    • No progress on this till we get flights and hotel bookings sorted out.

 

  • Goodies
    • Owner: Kushal Das
    • Deadline: 31 Aug
    • Talk to Suchakra to co-ordinate posters and vendors.
    • Kushal will get estimates for T-shirts, posters, banners, buttons, stickers, lanyards (tags).
    • Tatica, bckurera working on design of t-shirts
    • Rahul will follow up with designers

 

  • Posters
    • Owner: Suchakra
    • Deadline: 31 Aug
    • Good progress; designs on India list
    • Co-ordinating with design team on logo guidelines and usage

 

  • Booklet
    • Owner: Ankur Sinha
    • Deadline: 31 Aug
    • Not much progress
    • Some details added, but many more needed
    • (Should mention speakers should be able to talk if projector conks off)
    • Rahul to follow up and write content

 

  • Caterers
    • Owner: PJP
    • Deadline: 10 Aug
    • Boxed lunches: INR 350-400 per box
      • Yellow Chillies
      • Makkhan Maarke
    • Buffet INR 75 lesser than that
    • PJP following up with other vendors

 

  • FUDPub
    • Owner: Kushal
    • Deadline: Kushal to have updates next week

 

  • Website + voting
    • Owner: Saleem
    • Deadline: next week (content, funnel, COD)
    • Saleem to set up own server / hosting
    • Kushal to look at funnel
    • Saleem looking at COD
    • Rahul doing content
    • No domain yet from Fedora Infrastructure — blocker!

 

  • Bandwidth
    • Owner: PJP
    • Deadline: next week
    • PJP to talk to BSNL for a wired line to the venue for about a week

 

  • COEP
    • Owner: Suchakra
    • Infrastructure
      • New routers added, can handle 400 users (40 users per router; 10 available)
    • Set up a mirror on campus — Rahul + Saleem + Shreyank
    • We need a student volunteer team to interact with – Shreyank to identify
    • One lab running Fedora (dual-boot should also be OK) — possible?  needed?
    • Canteen
      • Will they remain open on all days?  Serve food for people we’re expecting?  — Saleem
    • Need to identify one room as speaker’s lounge
      • Have water/tea/coffee/snacks available

 

  • Backup plans
    • 3G dongles for speakers (if we can’t get a dedicated ‘net connection)
    • Spare projectors if some go off

 

  • Misc.
    • Registration desk — identify people who will welcome people and distribute swag
      • Swag distribution can be held off till 2nd day
    • Volunteers necessary to guide people from Mumbai to Pune?

FUDCon India Planning: Weekly Meetings

If you want to keep track of how FUDCon India planning is shaping up, or want to lend a helping hand in deciding how it shapes up, there are two weekly meetings you should be aware of:

  1. The IRC meeting on #fudcon-planning on irc.freenode.net every Friday at 1300 UTC / 1830 IST.
  2. The weekly face-to-face meeting at the Red Hat office in Pune, India.  This happens every Tuesday at 1500 IST.  If you can’t attend these and if some other day works for you, drop us an email at the India list.

The preparations for the FUDCon are well under way, watch the India list for minute-by-minute details.

First FUDCon India meeting

A few of us at the Red Hat Pune office strolled into a conf room to discuss plans and fix responsibilities for organising the FUDCon India 2011 at Pune. It was an impromptu session; we couldn’t include non-RH organisers but we kept the details to what the people present in the room have already committed to, according to the list of organizers.

We agreed on a set of action items.  There are no dates attached yet; those should be discussed and decided in the next meeting.  Some clarity needs to come from others; the first planning meeting on IRC scheduled for the 15th of July should shed light over those matters.

In addition to all that’s listed below, we might get extra sponsorship money (in addition to the FUDCon budget) from some companies.

If there’s some budget surplus, who’d like a fully-sponsored elephant ride through the city?  (Or at least to the event venue?)  Be quick to nominate yourself!

  • All: blog about the activities you’re doing. Ensure your blog is aggregated on planet.fedoraproject.org.
    • (Rahul to contact other organisers to do this) 
    • Done: Rahul sent an email to the India list.

  • Banners – Suchakra taking care of this
  • Booklet – Ankur Sinha with others.
    • Rahul to take part in this too

  • 1st priority: get international speakers to book flights ASAP. Get them to submit ‘sponsorship needed’ tickets.
  • 2nd priority: contact HR, get invitation letters for foreign delegates
  • 3rd priority: book hotels

All these 3 depend on:

  1. who’s coming?
  2. who are we sponsoring for flights/hotels (visas are self-sponsored)
  3. other guidelines — should get clarified this friday on irc meet

  • People not listed on talks page but will come:
    • Members from the Red Hat Community Architecture team
    • They will come from their own budget. Confirm if stay is also from their budget.
    • Get them and their talks listed on Wiki page.

  • T-shirt design: Rahul to contact design team
    • Done: Rahul opened a ticket
  • Videos: Ramki to contact pycon people who have offered to videograph + host videos

  • Swag: Can come from Ambassadors budget, but we could put our money if we have enough sponsorships.
  • FUDPub: Kushal to contact pubs.

  • Lunch: Should we sponsor till a cut-off? All? Only speakers + outstation delegates?
    • Only sponsor speakers + outstation delegates, have for-pay counters for everyone else. Rahul says he hasn’t seen a conf where food is free.
    • If we get lunch out of the budget, we can do better things for fudpub (starters in addition to one round of drinks) and swag (for more people)

  • Website + online voting (for barcamp): Saleem
    • Rahul to send initial mail about website to fedora advisory board.
    • Done: Rahul sent initial mail.
  • Hotels + logistics: Satya + Murty
    • Get quotes
    • Book as soon as we know number of int’l / non-Pune delegates who we are sponsoring
    • We could book for people who are staying on their own budget, eg., self-sponsored delegates / speakers. 
  • Food/catering: PJP
    • multiple options
      • boxed set
      • stall
    • explore both for two days. 3rd day will be paid for by individuals (or adjusted if budget permits).
    • Check with COEP if they can keep canteens open for all three days
  • To check with COEP – Logistics team + Rahul
    • infrastructure – wireless
    • canteens remaining open for all 3 days
    • stalls for food allowed near conf rooms?
    • set up a fedora mirror
  • Barcamp voting
    • Need to have printers, stationery at site on first day.
    • Stick schedule per room and per day on each room.
    • Possibly display schedule on projector
    • Suggestion: Have 2-3 keynotes (talks w/o parallel tracks) on first day and ask participants to vote online or on a board somewhere before breaking for lunch. This can reduce confusion.

  • Fudcons generally have 4 parallel tracks
  • Keep a schedule ready 2 days before event; minor changes allowed after voting on first day.

FUDCon APAC 2011: Pune, Nov 4-6

Jared Smith, the Fedora Project Leader, has announced the Pune bid has won for the APAC FUDCon for 2011.

https://fedoraproject.org/wiki/FUDCon:India_2011

If you’re planning to attend, there’s information on travel and costs on the bid page above.  A few community volunteers who will speak at the event can be sponsored, subject to budget restrictions.

Make sure to get your proposed talks or hackfests listed on the link above.  We already have a healthy list of topics; I’m eagerly looking forward to the event.

For people local to Pune, you can help organising the event. Please contact Rahul Sundaram, the event owner, or send an email to the fedora-india mailing list for details.

Stay Healthy By Taking Breaks

Most of us lead sedentary lifestyles these days — most of our time is spent in front of computers. This slowly is causing a lot of problems people from previous generations haven’t experienced: back aches, knee problems, wrist pains, myopia, among others. And just going to a gym or putting in one hour of physical activity a day isn’t enough. It doesn’t help balance the inactivity over the entire day.

I recently wrote an article in the BenefIT magazine that talks about two tools: Workrave and RSIBreak. Thanks to the publishers, the article is available in pdf format under a CC license.

I’ve tried both the software but have been using Workrave for quite a while now and am quite happy with it. To briefly introduce them: both software prompt the user to take a break at regular intervals. They have timers that trigger at configured intervals asking the user to take a break. Workrave also has some stretching exercises suggested that can be performed in the longer breaks. The shorter (and more frequent) breaks can be used to take the eyes off the monitor and to relax them. Read the article for more details.

I’ve reviewed Workrave version 0.9.1 in the article, though the current version as of now is 0.9.3, which has a few differences from those mentioned in the article. The prime difference is the addition of a ‘Natural Rest Break’ that gets triggered when the screen-saver gets activated, which is nice since if the user walks away from the computer for a prolonged period of time, the rest break in effect has been taken, and the next one is scheduled after the configured duration once the screen-saver is unlocked.

Both software are available in the Fedora repository: Workrave is based on the GTK toolkit (and integrates nicely with the GNOME desktop), whereas RSIBreak is based on the Qt toolkit (and integrates nicely with the KDE desktop). Give these software a try for a cheap but effective way of staying healthy!

Idea: Faster Metadata Downloads With Yum and Git

The presto plugin for yum has worked great for me so far.  It’s been very useful, not for the lack of download limits, but for the time saved in getting the bits downloaded.  The time saved is significant if the bandwidth is not too good (it never is).

However, I’ve observed in some cases the presto metadata is larger than the actual package size in some cases — e.g., a font.  If a font package, say 21KB in size, has a deltarpm of 3KB in size, it results in a savings of 18KB of downloads.  This is a very impressive 85% of savings.  However, the presto metadata itself could be more than 400KB, nullifying the advantage of the drpm.  We’re effectively downloading, in this corner case, 418KB instead of 21KB.  That is 19 times of what of the actual package size.

So here’s an idea: why not let git handle the metadata for us?  The metadata is a text (or sqlite) file that lists package names, their dependencies, version numbers and so on.  Since text can be very easily handled by git, it should be a breeze fetching metadata updates from a git server.  At install-time (or upgrade-time), the metadata git repository for a particular Fedora version can be cloned, and on each update, all that’s necessary for yum to do is invoke ‘git pull’ and it gets all the latest metadata.  Downloads: a few KB each day instead of a few MBs.

The advantages are numerous:

  • Saves server bandwidth
  • Uses very less server resources when using the git protocol
  • Scales really well
  • Compresses really well
  • Makes yum faster for users
    • I think this is the biggest win — not having to wait ages for a ‘yum search’ to finish everyday has to get anyone interested.  Makes old-time Debian users like me very happy.

There are some challenges to be considered as well:

  • Should the yum metadata be served by just one canonical git server, while the packages get served by mirrors?  Not each mirror may have the git protocol enabled nor can the Fedora project ask each mirror to configure git on the server.
    • Doing this can result in slow mirrors not able to service package download requests for the latest metadata
    • This can be mitigated by using git over http over the server
  • The metadata can keep growing
    • This can be mitigated by having a separate git repository for the metadata belonging to each release.  Multiple git repos can be set up easily for extra repositories (e.g., for external repos or for multiple version repos while doing an upgrade).
  • The mirror list has to be updated to also include git repositories that can be worked on with ‘git remote’.

I’ve filed an RFE for this feature.  For someone looking for a weekend hack for yum in python, this should be a good opportunity to jump right in!  If you intend to take this up, get in touch with the developers, make sure no one else is working on this yet (or collaborate with others) and update the details on the Fedora Feature Page.

Fedora Miniconf and foss.in/2010

A very delayed post on the Fedora Miniconf and foss.in/2010.

foss.in/2010 was held on the 15th, 16th and 17th of this month in Bengaluru. I could confirm my attendance very late, so I missed out on the CfP and a chance at speaking in the main conference, but I could manage to get a speaking slot in the Fedora miniconf. Thanks to Rahul for accomodating me at a short notice.

One of the main things I was looking forward to was meeting my team-mate Juan Quintela. Though we met recently at the KVM Forum 2010, I was going to use this opportunity to catch him and discuss some of the things I’m working on that overlap with his domain, virtual machine live migration, and get things going.

The other thing was to get to know more people — Fedora users and developers from India who I’ve spoken with on the irc channel but not met, other developers and users of free software from around the world. Add to that a few people who I’ve worked with and not met and also people whose software I use daily and who I want to thank for working on what they do.  It was also nice meeting the old known faces from the IBM LTC in Bengaluru — Balbir Singh, Kamalesh Babulal, Vaidy, Aneesh K. V., et al.

It’s always a certainty that there will be users of virtualization (particularly kvm) stack and it’s nice to get a feel of how many people are using kvm, in what ways, how well it works for them, and so on. That’s always a motivation.

The Fedora miniconf was on the 16th. The schedules for talks for miniconfs aren’t published by the foss.in people, so it was left to us to do our advertising and crowd-pulling. Rahul had listed the speakers and the talks on the Fedora foss.in/2010 wiki page. I went ahead and took out a few print-outs for the talks and assigned time slots for each talk depending on the suggested length given by the speakers for their talks as well as the slot allotted to the Fedora Project for the miniconf. The print-outs of the schedules were meant to be pasted around the venue to attract attention to the remotest section that was to host the miniconf, Hall C. However, we just ended up keeping the printouts as handouts at the Fedora stall that we set up. The Fedora stall was quite a crowd-puller. And since it was set up on the second day, we didn’t have to compete with the other stalls since they had their share of attendance on the first day.

The other members of the Fedora crowd, Rahul, Saleem, Arun, Shreyank, Aditya, Suchakra, Siddhesh, Neependra, … have written about the Fedora stall and their experiences earlier (and linked to from the Fedora foss.in/2010 page).

The Fedora miniconf was a great success, going by the attendance and the participation we had. My talk was the first, and I could see we had a full house. I think my talk went quite well. It could have been a little disappointing for people who expected demos, but I wanted to aim this talk towards people who had a general sense of using and deploying Fedora virt as well as Fedora on the cloud and also at people who would go and do stuff themselves rather than being given everything on a silver platter. This does resonate also with the foss.in philosophy of recent years of being a contributor-oriented conference rather than a user-originted one, so I didn’t mind doing that. Gauging by the response I got after the talk, I believe I was right in doing that. (I even got one email mentioning it was a great talk by the CEO of a company).

The other talks from the Fedora miniconf were engaging, I learnt quite a bit from what the others are up to. Arun’s talk on packaging emacs extensions was entertaining. He connects with the audience, I liked that about him.

Aditya’s talk on Fedora Summer Coding was a good call to students to participate in the free software world via Fedora’s internship programme. He narrated his own experience as a Fedora Project intern, which touches the right chords of the intended audience. I think doing more such talks will get him over the jitters of presenting to a big crowd.

Suchakra’s doing good work on accessing an embedded Linux box via a console inside a browser tab — it’s a very interesting project.

Neependra’s talk was a good walk-through of using tracing commands to see what really happens in the kernel when a userspace program runs. He walked through the ‘mkdir’ command and showed the call trace. This was a good demo. He spoke about the various situations in which tracing tools could be used, not just for debugging, and that should have set people’s thoughts in motion as to how they could get more information on how the system behaves instead of just using a system.

Shreyank’s talk on creating a web tool for managing student projects and the Fedora Summer of Code was interesting as well. It was nice to see the way an actual student project was designed and developed and how it’s going to make future students’ and mentors’ lives easier. This talk should have served as a good introduction to the flow and process students have to go through in applying, starting, reviewing and completing their project.

Apart from the Fedora miniconf, I attended a few sessions in the main conf. James Morris’s keynote on the history of the security subsytem in the Linux kernel was very informative. Rahul’s keynote on the ‘Failures of Fedora‘ was totally packed with anecdotes and analyses of the decisions taken by the Fedora project and their impact on the users and developers. Fedora (earlier Red Hat Linux) is one of the oldest distributions around, and any insights into the functioning and data as to what works and what does not is a great source of information to look for building engaging communities of users and contributors.

Lennart‘s two talks on systemd and the state of surround sound on Linux were not very new to me. However, there were a few bits in there that provided some food for thought.

Juan‘s talk on live migration was packed full of experiences in getting qemu to a state where migration works fairly well. He also spoke about all the work that’s left to do. It was totally technical and I think the people who were misguided by it being labelled as a ‘sysadmin’ talk or by the title (expecting to migrate from an older physical machine to a newer physical machine w/o downtime) quickly left the hall. Whoever stayed back were either people who work on QEMU/KVM (esp. the folks from the IBM LTC) or people too polite to walk out.

Dimitris Glezos‘s talk on building large-scale web applications was a very informative one for me. I’ve never done web programming (except for html, css and a bit of php ages ago), and this was a good intro for me to understand what various web development frameworks there are, their pros and cons, the way to deploy them, the way to structure them, etc. It was evident he took a lot of effort to prepare the slides and the talk, it was totally worth it.

Danese Cooper‘s keynote on the Wikimedia Foundation was an equally informative talk. She spoke on a wide range of topics, including the team that makes up Wikimedia, their servers and datacentres, their load balancing strategy, their backup systems, their editing process, their localisation efforts, their search for a new mirror site in the APAC region, etc. I was interested in one aspect, machine-readable wikipedia content, to which they had a satisfactory answer: they’re migrating to semantic web content and would look at a machine-readable API once they’re done adding semantics to their content.

The other time was spent at the Fedora booth and talking to Juan and the other friends.

The foss.in team announced this would be the last foss.in, so thanks to them for hanging around so long. To fill the void, we’re going to have to step up and organise a platform for like-minded people from the free/open source software community around here. I’ve been part of organising some events earlier in different capacities, and I’m looking forward to being part of an effort that provides such a platform. There’s a FUDCon being planned for next year in Pune, I’ll be involved in it, and will take things along from there.

Communication between Guests and Hosts

Guest and Host communication should be a simple affair — the venerable TCP/IP sockets should be the first answer to any remote communication.  However, it’s not so simple once some special virtualisation-related constraints are added to the mix:

  • the guest and host are different machines, managed differently
  • the guest administrator and the host administrator may be different people
  • the guest administrator might inadvertently block IP-based communication channels to the host via firewall rules, rendering the TCP/IP-based communication channels unusable

The last point needs some elaboration: system administrators want to be really conservative in what they “open” to the outside world.  In this sense, the guest and host administrators are actively hostile to each other.  Also, rightly, neither should trust each other, given that a lot of the data stored in operating systems are now stored within clouds and any leak of the data could prove disastrous to the administrators and their employers.

So what’s really needed is a special communication channel between guests and hosts that are not susceptible to being blocked out by guests or hosts as well as being a very special-purpose low-bandwidth channel that doesn’t look to re-implement TCP/IP.  Some other requirements are mentioned on this page.

After several iterations, we settled on one particular implementation: virtio-serial.  The virtio-serial infrastructure rides on top of virtio, a generic para-virtual bus that enables exposing custom devices to guests.  virtio devices are abstracted enough so that guest drivers need not know what kind of bus they’re actually riding on: they are PCI devices on x86 and native devices on s390 under the hood.  What this means is the same guest driver can be used to communicate with a virtio-serial device under x86 as well as s390.  Behind the scenes, the virtio layer, depending on the guest architecture type, works with the host virtio-pci device or virtio-s390 device.

The host device is coded in qemu.  One host virtio-serial device is capable of hosting multiple channels or ports on the same device.  The number of ports that can ride on top of a virtio-serial device is currently arbitrarily limited to 31, but one device can very well support 2^31 ports.  The device is available since upstream qemu release 0.13 as well as in Fedora from release 13 onwards.

The guest driver is written for Linux and Windows guests.  The API exposed includes open, read, write, poll, close calls.  For the Linux guest, ports can be opened in blocking as well as non-blocking modes.  The driver is included upstream from Linux kernel version 2.6.35.  Kernel 2.6.37 will also have asynchronous IO support — ie, SIGIO will be delivered to interested userspace apps whenever the host-side connection is established or closed, or when a port gets hot-unplugged.

Using the ports is simple: when using qemu from the command line directly, add:

-chardev socket,path=/tmp/port0,server,nowait,id=port0-char
-device virtio-serial
-device virtserialport,id=port1,name=org.fedoraproject.port.0,chardev=port0-char

this creates one device with one port and exposes to the guest the name ‘org.fedoraproject.port.0‘.  Guest apps can then open /dev/virtio-ports/org.fedoraproject.port.0 and start communicating with the host.  Host apps can open the /tmp/port0 unix domain socket to communicate with the guest.  Of course, there are other qemu chardev backends that can be used other than unix domain sockets.  There also is an in-qemu API that can be used.

More invocation options and examples are given in the invocation and how to test sections. 

There is sample C code for the guest as well as sample python code from the test suites.  The original test suite, written to verify the functionality of the user-kernel interface, will in the near future be moved to autotest, enabling faster addition of more tests and tests that not just check for correctness, but also regressions and bugs.

virtio-serial is already in use by the Matahari, Spice, libguestfs and Anaconda projects.  I’ll briefly mention how Anaconda is going to use virtio-serial: starting Fedora 14, guest installs of Fedora will automatically send Anaconda logs to the host if a virtio-serial port with the name of ‘org.fedoraproject.anaconda.log.0‘ is found.  virt-install is modified to create such a virtio-serial port.  This means debugging early anaconda output will be easier with the logs available on the host (and not worrying about guest file system corruptions during install or network drivers not available before a crash).

Further use: There are many more uses of virtio-serial, which should be pretty easy to code:

  • shutting down or suspending VMs when a host is shut down
  • clipboard copy/paste between hosts and guests (this is under progress  by the Spice team)
  • lock a desktop session in the guest when a vnc/spice connection is closed
  • fetch cpu/memory/power usage rates at regular intervals for monitoring

Upgrading from Fedora 11 to Fedora 13

Having already installed (what would be) F13 on my work and personal laptops the traditional way — by installing a fresh copy (since I wanted to modify the partition layout), I tried an upgrade on my desktop.

My desktop was running Fedora11 and I moved it to Fedora13. I wanted to test how the upgrade functionality works, does it run into any errors (esp. since it’s from 11 -> 13, skipping 12 entirely), if the experience is smooth, etc.

I started out by downloading the RC compose from http://alt.fedoraproject.org/. Since all my installs are for the x86-64 architecture, I downloaded the DVD.iso. I then loopback-mounted the DVD on my laptop:

# mount -o loop /home/amit/Downloads/Fedora-13-x86_64-DVD.iso /mnt/F13

I then exported the contents of the mount via NFS; edit /etc/exports and put the following line:

/mnt/F13 172.31.10.*

This ensures the mount is only available to users on my local network.

Then, ensure the nfs services are running:

# service nfs start
# service nfslock start

On my desktop which was to be upgraded, I mounted the NFS export:

# mount -t nfs 172.31.1.12:/mnt/F13 /mnt

And copied the kernel and initrd images to boot into:

# cp /mnt/isolinux/vmlinuz /boot
# cp /mnt/isolinux/initrd.img /boot

Then update the grub config with this new kernel that we’ll boot into for the upgrade. Edit /boot/grub.conf and add:

title Fedora 13 install
    root (hd0,0)
    kernel /vmlinuz
    initrd /initrd.img

Once that’s done, reboot and select the entry we just put in the grub.conf file. The install process starts and asks where the files are located for the install. Select NFS and provide the details: Server 172.31.1.12 and directory /mnt/F13.

The first surprise for me was to see the updated graphics for the Anaconda installer. They got changed in the time I installed F13 (beta) on my laptops. The new artwork certainly looks very good and smooth. More white, less blue is a departure from the usual Fedora artwork, but it does look nice.

I then proceeded to select ‘upgrade’, it found my old F11 install and everything after that ‘just worked’. I was skeptical about this while it was running: I had some rpmfusion.org repositories enabled and some packages installed from those repositories. I was wondering if those packages would be upgraded as well, or would they be left at the current state, which could create dependency problems, or if they would be completely removed. I had to wait for the install to finish, which took a while. The post-install process took more than half an hour, and when it was done, I selected ‘Reboot’. Half-expecting something to have broken or to not work, I logged in, and voila, I was presented the shiny new GNOME 2.30 desktop. The temporary install kernel that I had put in as the default boot kernel was also removed. Small thing in itself, but great for usability.

Everything looked and felt right, no sign of breakage, no error messages, no warnings, just some good seamless upgrade.

I can’t say really expected this. Coming from a die-hard Debian fan, distribution upgrades are something that was the forte of just Debian. For now. The Fedora developers have done a really good job of getting this process extremely easy to use and extremely reliable. Kudos to them!

While the Fedora 13 release has been pushed back a week for a install-over-NFS bug, it needs a certain combination of misfortunes to trigger, and luckily, I didn’t hit that bug. However, when trying the F13 beta install on my laptop, I had hit a couple of Anaconda bugs, one of which is now resolved for F14 (crash when upgrading without a bootloader configuration) and the other one (no UI refresh if I switch between virtual consoles until a package finishes install — really felt while installing over a slow network link) is a known problem with the design of Anaconda, and hopefully the devs get to it.

Overall, a really nice experience and I can now comfortably say Fedora has really rocketed ahead (all puns intended) since the old times when even installing packages used to be a nightmare. This is good progress indeed, and I’m glad to note that the future of the Linux desktop is in very good hands.

Cheers to the entire team!