On logos:
"before you complain that it is not geeky enough, note that i have referenced both the logarithmic spiral and four-color theorem."
I'm not even saying it's a bad diagram as these things go -- just extremely boring and kind of cryptic.
Maybe that does make it bad. Nonetheless. We drafted the chapter with a placeholder for this figure because, when Luke and I were talking about traffic shaping, I needed to express the idea that all the traffic was "incoming" at some point in its travel through the dom0. I desperately wished, at that time, for a pen and a napkin. (I didn't wind up scribbling in soy sauce, but perhaps I should have.)
Anyway, I suppose it gets the point across -- that the network bridge, because of how it's positioned, can act equally well on incoming and outgoing traffic. Other figures help to expand on the subject.
This is a public service post informing the world at large: It is not possible to use socket AM2/940/939/754/whatever heatsinks on socket 1207 (also known as socket F) motherboards. At least, not on ones that use the 4.1" mounting pitch, such as those from Supermicro and Tyan. The clip is too short, although it seems the heatsink would physically fit if a longer clip could be found.
Anyway, someone had to try it. I hope that Google indexes this page so that others can avoid making the same mistake.
Anyway, someone had to try it. I hope that Google indexes this page so that others can avoid making the same mistake.
Well, looks like our HVM chapter will need a little bit of updating. Not a big deal, but we're still using the old "kernel=hvmloader" and the current design includes a "loader" option. (Thus moving the semantics of "kernel" back towards what you'd expect.) I'd like to know what Xen version introduced that.
Actually, the way that they've shifted the meaning of the kernel line around has been kind of interesting. One can almost imagine new generations coming in, redefining the kernel= directive, and then having the next generation come in and nudge it back where it used to be. We saw it here, with pygrub -- I wonder where else?
Actually, the way that they've shifted the meaning of the kernel line around has been kind of interesting. One can almost imagine new generations coming in, redefining the kernel= directive, and then having the next generation come in and nudge it back where it used to be. We saw it here, with pygrub -- I wonder where else?
Fairly good walkthrough on installing a CentOS domU. I like how they're using kickstart. Manual installs are for chumps. Other stuff from that wiki is also pretty good.
http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU
http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU
Here is how to mount a disk read-write in multiple domains. I was going to put this in "tips," but I think we've decided to take it out (and maybe put it in storage.) For now, it's a bit of an orphan:
Xen will try to protect you, but, like most good unix tools, it'll let you do terrible and dangerous things if you really want to.
If you're *certain* that you want to mount a block device read/write in multiple domains, you can add an exclamation point to its disk specifier. For example:
disk=['tap:aio:/xen/images/gertrude.img',xvda,w!]
And Xen will follow instructions. Don't do this. It is a Bad Idea.
Xen will try to protect you, but, like most good unix tools, it'll let you do terrible and dangerous things if you really want to.
If you're *certain* that you want to mount a block device read/write in multiple domains, you can add an exclamation point to its disk specifier. For example:
disk=['tap:aio:/xen/images/gertrude.img',xvda,w!]
And Xen will follow instructions. Don't do this. It is a Bad Idea.
Whenever I fail to respond to emails in a timely manner (by which I mean, all the time) I am reminded of the Japanese word 「黙殺」 for "ignore with contempt." Roughly. Unfortunately, it can also mean "no comment." This ambiguity sometimes leads to confusion.
(The wikipedia article, http://en.wikipedia.org/wiki/Mokusatsu , goes into much more detail. Take a look.)
(The wikipedia article, http://en.wikipedia.org/wiki/Mokusatsu , goes into much more detail. Take a look.)
Working more on troubleshooting, which is, as you might gather, an enormous chapter. I'm not saying that Xen doesn't work -- I'm just saying that you have to define 'work' carefully.
Anyway. Not that I am bothered. It's a lovely day.
Really, right now we're thinking about adding a bit on the vm.overcommit_memory and overcommit_ratio sysctls, and how they can be used to improve Xen's stability. The idea is that, if we make it impossible for the VM subsystem to overcommit memory, the oom-killer should never run. This will lead to improved stability, since the oom-killer has a regrettable habit of killing sshd.
We need to test that assertion, though, and that sounds suspiciously like work.
Anyway. Not that I am bothered. It's a lovely day.
Really, right now we're thinking about adding a bit on the vm.overcommit_memory and overcommit_ratio sysctls, and how they can be used to improve Xen's stability. The idea is that, if we make it impossible for the VM subsystem to overcommit memory, the oom-killer should never run. This will lead to improved stability, since the oom-killer has a regrettable habit of killing sshd.
We need to test that assertion, though, and that sounds suspiciously like work.
Another todo:
Currently the stuff related to /etc/xen/auto is in "tips," which has served as our catchall thus far. This is. . . tolerable, but I'd like to move it somewhere else, because the point of segregating the tips chapter is to keep the special-interest, possibly-broken stuff kind of isolated.
Unfortunately, there's no really great place for the information with the current structure. Probably "quick start," which bugs me because I didn't want that to contain any unique information.
On the other hand, anyone who's skipping quick start probably already knows how to symlink stuff into /etc/xen/auto, so it's not a big deal.
Currently the stuff related to /etc/xen/auto is in "tips," which has served as our catchall thus far. This is. . . tolerable, but I'd like to move it somewhere else, because the point of segregating the tips chapter is to keep the special-interest, possibly-broken stuff kind of isolated.
Unfortunately, there's no really great place for the information with the current structure. Probably "quick start," which bugs me because I didn't want that to contain any unique information.
On the other hand, anyone who's skipping quick start probably already knows how to symlink stuff into /etc/xen/auto, so it's not a big deal.
Thinking about the "tips" chapter. Here's the stuff that I can remember offhand, without looking, that we promised/planned we would explain in it:
framebuffer
serial console
kernel compilation (special reference to debugging knobs)
lilo
domu 3d (iffy. very iffy. i wonder if the new boxes will have iommu?)
xenbus/xenstore (our example used it _and_ the framebuffer, actually. it's really cool. or so I say, but I'm easily impressed.)
framebuffer
serial console
kernel compilation (special reference to debugging knobs)
lilo
domu 3d (iffy. very iffy. i wonder if the new boxes will have iommu?)
xenbus/xenstore (our example used it _and_ the framebuffer, actually. it's really cool. or so I say, but I'm easily impressed.)
Recent Comments