New versions of Liferea refuse to parse any feed that fails to validate,
even for relatively “minor” problems (the libxml2 recovery facility is
no longer used; besides, it abandons the rest of the feed when it hits
such problems). I don’t want to use Google Reader, since I don’t like
Typically bad feeds have things like high-bit chars or bare ampersands.
Thankfully, there’s a “conversion filter” feature that you can use to
work around the bad feeds. On the two bad feeds, I run this filter:
[[email protected] ~]$ cat bin/fix-ampersands
sed 's/\o226/&/g' | sed 's/& /\&/g' | sed 's/\o243/GBP/g'
“The main indicators of egotism as I intend it here are are loud
self-display, insecurity, constant approval-seeking, overinflating one’s
accomplishments, touchiness about slights, and territorial twitchiness
about one’s expertise. My claim is that egotism is a disease of the
incapable, and vanishes or nearly vanishes among the super-capable.”
“I’m the crippled kid who became a black-belt martial artist and teacher
of martial artists. I’ve made the New York Times bestseller list as a
writer. You can hardly use a browser, a cellphone, or a game console
without relying on my code. I’ve been a session musician on two records.
I’ve blown up the software industry once, reinvented the hacker culture
twice, and am without doubt one of the dozen most famous geeks alive.”
No prizes for guessing who this was.
Another significant usability improvement that landed in build 126 is Gary and Bill's work
on enabling Xen. Now, running xVM should be as simple as:
# pkg install xvm-gui
# echo 'set zfs:zfs_arc_max = 0x10000000' >>/etc/system # yes, you still need this, sadly
# svcadm enable -r milestone/xvm
There's also a new Visual Panel for doing this if you prefer a graphical method. More in
the flag day message.
As part of our ongoing work on improving the ease of use of xVM, the newly available build 126 of OpenSolaris
has my putback for:
6878952 Would like dry-run migration
This feature is useful for doing a simple check as to whether a guest can successfully migrate to another dom0 host. For example, domu-221 here is using a disk path that doesn't exist on the remote host hiss:
# virsh migrate --dryrun domu-221 xen:/// hiss
error: POST operation failed: xend_post: error from xen daemon:
(xend.err 'Remote server error: Access to vbd:768 failed: error: "/iscsi/nevada-hvm" is not a valid block device.')
This works both with running and shutdown guests. Currently, the checks are fairly limited: are disks of the same path available on the remote host (note there is no checking of GUIDs or whatever to verify they really are the same piece of shared storage); is there enough memory on the remote host; and is the remote host the same CPU vendor. We expect these checks to improve both in scope and in reliability in the future.
What does this print:
from lxml import etree
doc = etree.fromstring('<a><b><c/></b></a>')
newdoc = etree.ElementTree(doc.find('b'))
The answer is:
[<Element a at 817548c>]. The first point to note is
xpath() against an element is only relative to that element: any
absolute XPaths enumerate from the top of the containing tree. The
second point is that the shallow copying of
etree means that
_ElementTree::xpath, evaluates absolute
paths from the top of the original underlying tree! So even though
newdoc, an absolute XPath on a child element can
still reach it.
How much time would it really take to order multi-part videos, so the
suggestion at the end of the video is the next part? Please!
I recently had cause to try out COMSTAR for the first time, and I thought I'd write up the steps needed. Unfortunately,
it's considerably more complex than the fall-over-easy shareiscsi=on
Configuring the COMSTAR server
First install the storage-server packages and enable the services:
# svcadm enable -r stmf
# svcadm enable -r iscsi/target
We want to create a target group for each of our xVM guests, each of which will have one LUN in it. After creating
the LUN, we define a "view" that allows that LUN to be visible for that target group:
# stmfadm create-tg domu-226
# zfs create -V 15G export/domu-226
# stmfadm create-lu /dev/zvol/rdsk/export/domu-226
Logical unit created: 600144F0C73ABF0F00004AD75DF2001A
# stmfadm add-view -t domu-226 600144F0C73ABF0F00004AD75DF2001A
Now we need to create the iSCSI target for this target group, that has our single LUN in it.
# itadm create-target -l domu-226
Target iqn.1986-03.com.sun:02:b8596bb9-9bb9-40e9-8cda-add6073ece46 successfully created
Here (finally) is our iSCSI Alias we can use in the clients. But we're not done yet. By default, this target
will be able to see all LUNs not in a target group. So we need to make it a member of our domu-226 target group:
# stmfadm add-tg-member -g domu-226 iqn.1986-03.com.sun:02:b8596bb9-9bb9-40e9-8cda-add6073ece46
# stmfadm list-tg -v
Target Group: domu-226
Configuring the iSCSI initiator (client)
We do this in the usual manner:
# svcadm enable -r svc:/network/iscsi/initiator:default
# iscsiadm add discovery-address 10.6.70.43:3260
# iscsiadm modify discovery --sendtargets enable
Installing a guest onto the LUN
We went through the above gymnastics so we can have a human-readable Alias for each of the domu's root LUNs. So now we can do:
# virt-install --paravirt --name domu-226 --ram 1024 --os-type solaris --os-variant opensolaris \
--location nfs:10.5.235.28:/export/nv/x/latest --network bridge,mac=00:14:4f:0f:b5:3e \
--disk path=/alias/domu-226,driver=phy,subdriver=iscsi \
Imagine you have this in mod.py:
Seems fine right? In fact, there’s a nasty bug here. If I try to use
this module in client.py like so:
mybar = bar()
Then you’re likely to get an exception when the program exits. This is
because Python, for some bizarre reason, Nones out the globals in
mod.py when taking down the interpreter. The actual
can be called sometime after this, and it ends up trying
None.cleanup(), with the resultant
AttributeError. It seems
extremely bizarre that it happens in this order, but it does (a real
Exactly that’s the point. Adding dom0 makes life easier for a group of
users who decided to use Xen some time ago, but what Ingo wants is
technical improvement of the kernel… The kernel policy always was
and still is to accept only those features which have a technical
benefit to the code base.
It boggles the mind that someone could get things so backwards. The
kernel exists to provide services to the outside world, not the other
way around. By all means criticise the details of the Xen dom0 code, but
this argument makes zero sense. How precisely did x86_64 support
provide a technical benefit to the code base?
Just a quick note: you can follow the instructions I provided for the 2008.11
release, with one change. On a 64-bit machine, replace any instances of /boot/x86.microroot
. As of 2009.06, the boot archive is split into 32-bit and 64-bit variants. If you get a message like this:
krtld: failed to open '/platform/i86xpv/kernel/amd64/unix'
Then you've probably given the wrong combination of unix and microroot.
By the way, in my previous entry, I mentioned we were working on upstreaming our virt-install
changes. During the Xen 3.3 work (more on which soon), I updated to the latest versions and got the needed parts into the upstream version. We've still some ZFS changes to push, but if you're running a recent enough version of Xen on Linux, you may well be able to use virt-install
and skip all this horrible hacking!