Dec 14th 2011 by primalmotion

No comments

I notice that most of people don’t know how to deal with errors in Archipel. This post will try to help people to know how to manage problems in Archipel, track the origin of the errors, and how to fix them, or at least being able to report a correct issue. First let’s see how I organize my desktop. This is my personal preference, but I guess it’s a good starting point. I have two screens, and this is sincerely the bare minimum for me. Screen 1: Screen 2: As you can see, on the first screen, I have my browser, with debugger opened, the source code (this is obviously optional if you are just a user) and on the second screen I have opened two terminals. One connected to the hypervisors through SSH, with the archipel.log displayed with tail (I use one tab per hypervisor) and another one, in my local computer, to send update. As you can see, to update the archipel agent code, a simple scp + restart archipel is sufficient because I have the source installed with buildAgent -d. This allows to optimize the code’n’try way. I also usually have another terminal SSH’ed to the hypervisors to send simple commands, or fix some stuff quickly. If you use Mac OS X, you can create a Terminal profile to open this workspace with one click. There are basically two main errors users are complaining about. Their hypervisors are offline They get some 501 errors Usually, there are only few things that could cause these issues. it’s mostly always due to : some missing library like python-libvirt or xmpppy or stuff like that a misconfiguration in archipel.conf A problem with the ejabberd configuration The basics When you are debugging Archipel, you need to know that most of the errors are logged in the archipel.log. In case they are not logged, there is great chance you run into a new issue we are not aware of. To be sure you will see every kind of errors, do not start archipel with the init script! it will redirect all output to /dev/null. You should start and restart archipel like this # killall runarchipel; runarchipel; tailf /var/log/archipel/archipel.log Do not hesitate to grep! for example: # killall runarchipel; runarchipel; tailf /var/log/archipel/archipel.log | grep -i error # only displays error lines # killall runarchipel; runarchipel; tailf /var/log/archipel/archipel.log | grep -i “uuid@fqdn” # only displays logs from a the vm with given UUID Be creative, and try to always filter the log, because it can be very verbose. most of the functions prefixes the logs with an identifier. for example, if you want to get logs for only migration related stuff, grep on “MIGRATION” or only for VMParking feature, grep on “VMPARKING”. This will help you to track down where your problem comes from. The 501 errors You have to note that 501 errors are not logged into archipel.log! Errors 501 mean the agent hasn’t react to the command, so obviously, nothing will be [...]

Nov 24th 2011 by primalmotion

No comments

It’ been a while since the last post. A lot of stuff have been added to Archipel since. So I guess it’s time to explain what changed. First of all, we worked hard on UI overall performance. Archipel has grown in complexity, and some modules were just to resource greedy. We have added some controls to be sure a given request is not already waiting for a response, and if it is, Archipel just replaces it with the new one, instead of receiving two answers, one useful, one ignored. The majority of these improvements have been implemented at the lowest possible level. We also worked on optimization of the permissions caching. The result is a really smoother user experience. Also, all the possible very big tables, like the XMPP users one, are now using a lazy loading system. Archipel UI will only ask the small chucks of data it needs to display, and ask the rest later if needed. This allows you to have virtually any number of XMPP users you like, without impacting the performances. (there is still some places to optimize, though) Now about features, we have several new stuff: Dynamic platform administrators: it’s now super easy to grant any user the full platform admin permissions: one click, real time. Support for bandwidth limitation per virtual machine. VMParking: You can “park” a virtual machine in a PubSub node. The VM doesn’t exist anymore anywhere. Then you can un-park it on any hypervisor you like. (you can also change the XML description of a parked VM) Support for character devices: manage the serial/parallels/channel devices for your VMs. Auto group: If you use XMLRPC API, you can set Archipel to automatically add VMs and hypervisors into shared roster groups. The dependency to python-magic, which caused a lot of installation problems, has been removed. A correct version is now embedded in the agent. Lot of bug fixes in the roster management All these features are now available in the master head. But you have to note that you need to update everything. Older versions of agents/GUI are not compatible anymore with these changes. Enjoy,

Oct 12th 2011 by primalmotion

No comments

On 2011/11/24 at 17h45, Emmanuel Blindauer will give a talk about Archipel at french event JRES2011 in Toulouse. You certainly virtually meet him in #archipel IRC channel as Mooby. He will make an overall presentation about Archipel, what it does, how it does it, what are the advantages and the inconvenient (but there is no inconvenient). It will be a short talk, but if you are around Toulouse, feel free to go.

Sep 30th 2011 by primalmotion

No comments

The beta 4 of Archipel, named “Vesta” is now available. It includes a lot of bug fixes, and we would like to thanks all the people who have sent crash reports and open issues. This has really helped us to track and fix the bugs. But it’s not only a maintenance release. It includes some cool new features. Here is the important ones: Easy support of additional admin accounts in GUI Manage existing libvirt domains directly from GUI Support for macvtap networking Support for multiple selection from the roster XML Editor for networks Support for inbound/outbound bandwidth limitation Display libvirt version and driver version of hypervisors Updated versions of external components New optimized push center The full change log is available here. As always, you can download the beta 4 of the GUI from the download page. The online version of the beta 4 is here. To update the agent, run, as usual: # easy_install -U archipel-agent If you have already a previous beta installed, check carefully the log for missing conf tokens. If you need any help, ask us on the chat. Hope you will enjoy it!

Sep 28th 2011 by primalmotion

No comments

Until now, the most easy way to give virtual machines LAN connectivity is to use bridges. The standard workflow is to create a bridge first (manually or from Hypervisor Networks module), then log on your hypervisor, add a physical NIC in the bridge. This needs to shut down the network, configure some stuff etc. It’s pretty annoying and as libvirt doesn’t manage adding/removing NICs to/from bridges, most of the time, the Archipel’s Hypervisor Network module is pretty useless. Well this time is over. The Linux Kernel supports a new driver named “macvtap” since 2.6.34 and Libvirt supports it since 0.9.4 . Here is the definition: “Macvtap is a new device driver meant to simplify virtualized bridged networking. It replaces the combination of the tun/tap and bridge drivers with a single module based on the macvlan device driver. A macvtap endpoint is a character device that largely follows the tun/tap ioctl interface and can be used directly by kvm/qemu and other hypervisors that support the tun/tap interface. The endpoint extends an existing network interface, the lower device, and has its own mac address on the same ethernet segment. Typically, this is used to make both the guest and the host show up directly on the switch that the host is connected to.” (source) We are happy to announce that Archipel now supports this driver. It’s very easy to use. Select a hypervisor, go to the “Networks” tab, then create a network. Name it as you want, select the mode named “Bridge” or “Private”, and select the forward device (eth0 for instance): The “Bridge” mode will act like a standard bridge. The virtual machines in the network will have a standard LAN access. The “Private” mode is the same, but it won’t be able to communicate to the rest of the VM on the host. What you need to do on your hypervisor to support this feature is to load the “macvtap” driver # modprobe macvtap You also need to be sure the ethX you will use as forward device is not already in a bridge and you must use Libvirt 0.9.4+. You may also notice there are more fields in the Network Edition Popover. You can now set the Inband / Outband traffic shaping! And last but not, least, we have added a manual XML editor for the networks, just like the Virtual Machine Definition: All of this should be already available in the master at the time you read this. We hope you will enjoy it!

Sep 26th 2011 by primalmotion

No comments

Last saturday, we were to the Open World Forum 2011, in Paris, to speak about Archipel. It was pretty interesting, but they were less people than the organizers expected. I don’t know for you guys, but here in France, in a Saturday morning at 11h, people are mostly sleeping :) Anyway, it was cool, the demo runs fine (only one crash!) and we were able to present everything we wanted to show. We also have been interviewed by Intelli-n.tv (the video is not published yet, we’ll update this entry when they will release it). If you are interested, you can have a look at the keynote used for the presentation here.

Aug 24th 2011 by primalmotion

No comments

The issue #130 of Linux Magazine has a great cover story about Archipel. There are 5 pages describing the solution in details and how to get it working (even if it is already a bit outdated as we have simplified a lot since the writing). If you haven’t this magazine, you can buy it here (plus, there are a lot of other interesting articles about virtualization in general). The article is pretty nice and fair about Archipel, and we would like to thanks Andrej Radonic for it.

Jul 26th 2011 by primalmotion

No comments

The beta 3.2 of Archipel has just been published. It is a minor release that fixes several bugs found in beta 3.1: In any case, the GUI should not crash anymore if problem occurs while reading a corrupted plist from XMPP Server Fix a bug with XMPP Server that doesn’t display users if using XMLRPC API mode Several other minor fixes. As usual, the GUI is available in the download section, and you can update the agent using: # easy_install -U archipel-agent Please report any problem!

Jul 22nd 2011 by primalmotion

3 comments

Two versions in less than one week! Ok this one mainly contains only fixes, but also allow you to not need ejabberd-xmlrpc module anymore. The Change Log is here. The eggs are on PyPi so you can update as usual. You can try the GUI of the beta 3.1 using this URL http://nightlies.archipelproject.org/beta3.1. Enjoy and report any problem!

Jul 22nd 2011 by primalmotion

No comments

In beta 3, we have reintroduced the crash reporting system. It is the very annoying thing that stops the execution of GUI at any uncaught exception. In previous betas, some of these exceptions occurs, and they were not critical (i.e. GUI can continue to work without any problem), but we now want to track down all of them. So if error occurs, please send the crash report, or open an issue with copying the System information text displayed in the crash report (prefer this solution actually). In other hand, the crash reporter system helped us to track down some very serious bugs. One of the most critical has been analyzed just now: We know the reason why the GUI crash at startup sometimes, saying something about ‘maker XXX is not recognized’. This one was particularly tricky to find out but thanks to the all the crash reports, it is now tracked down and fixed. We also are bored by supporting people having problem with installing ejabberd_xmlrpc. This not standard module helped us to access the admin of XMPP Server in a pretty fast way (first version where using ejabberdctl as subprocess). Making this module correctly working is quite a pain. Build always seems to goes fine, but it’s actually messed up, resulting strange error in ejabberd log, and (most important) making Archipel not working correctly. Seriously, 90% of problem reported by users are related to their install of this module, and most of the time, they lost hours to make it work. Well, now this is over. As we want user experience to be the most smooth as possible, from installation to usage, the need of this module is no more required. Users management is done by using XMPP and shared groups management is using the ejabberd subprocess for now (we will discuss about change on this later). And as we don’t like to drop functional code, you now have the choice to use it if you want to. Isn’t life great? All these changes will be published in a Beta 3.1 that *should* be release this afternoon.