Posts Tagged xen

The importance of having ntpd configured

Ok, not really importance of having it configured, but at least a post to try and get myself to remember to do it.

I discovered that the Dreamhost server I’m hosting this blog on has bad clock drift. I’m not sure why it’s happening (I’d imagine that it should be one of the first things configured in a mass server environment, but hey…)

Anyway, having a ~5 minute clock drift broke the WordPress Google Authentication plugin – and anything else that’d rely on time. So I decided to quickly check my VPSes and just make sure they had ntpd up and running.

And oddly enough, the Xen instances didn’t, the ones where ntpd is the most necessary since it maintains an internal clock state disassociated from the wall clock. OpenVZ at least (appears to) inherit from the the container host, and both hosts I’m with appear to have ntpd enabled (or at least my clocks that are pretty close to the pool time.

In any case, getting ntpd setup on the Xen instances was painless:

yum install ntp
systemctl enable ntpd
systemctl start ntpd
ntpdate -q

By default ntpd uses the pool, so the extra ntpdate command is in theory unnecessary, but that just forced time to get in sync quickly.

Config credit goes to the Fedora official docs

, ,

No Comments

Specifying dom0 RAM in Xen – update

Another thing from the xen-users mailing list:

Apparently the way to specify the dom0 RAM at boot in Xen has changed. You should now specify the maximum memory – dom0_mem=2G,max:2G instead of dom0_mem=2G.

Also, a new addition to the Xen Best Practices suggests preventing Xen from auto-ballooning the dom0 memory down by changing autoballoon in /etc/xen/xl.conf to 0.


No Comments

Defining the dom0 memory limit in GRUB2

Before I upgraded my dom0 to Fedora 16 (and by association Grub2), I had the dom0 memory limit fixed as an argument in grub.conf. When I upgraded to Grub2, I initially added it manually to the Xen boot command line, but eventually stopped doing that.

Today while looking through the xen-users list, I found an email that mentioned how to get grub2-mkconfig to automatically add it for you – add GRUB_CMDLINE_XEN=”dom0_mem=1024M” to /etc/default/grub. It seems to be the same on both Debian and Fedora, so I don’t see why it wouldn’t work on dom0s built with other distros.


No Comments

Fedora 16 domUs – Update

So, I’ve wiped my test system with the intention of doing a tutorial on installing F16 + Xen. As part of this, I looked into installing a F16 domU with virt-install. When I tried it previously, I ran into this bug, and I ended up having to vnc into the dom0 and use virt-viewer to do the install.

Recently, there was some activity on the bug, centering around using “rd_NO_PLYMOUTH” to bypass the plymouth boot screen (the progress bar that scrolls across the screen, apparently – though why it’s in the installer I have no clue).

In any case, it seems to work – my revised install command of virt-install -p -r 1024 -n rawhide -f /dev/domU/rawhide -l -x "ks=\"http://hydrogen/~kyl191/ks/ks.php?hostname=rawhide\" rd_NO_PLYMOUTH serial" seems to do the trick – it gets into the console, at the very least.

That said, I get a nasty error using the partitioning scheme in my Kickstart file – grub2 wants a BIOS boot partition, a 1MB partition for storing files, and installation fails.

So, either I add the extra partition to the kickstart partitioning stanza, or I pass the installer an extra nogpt option when installing.

Guess which I chose. The BIOS boot partition makes no sense for Xen, because we’re booting with pygrub – we only care about grub.cfg, not what GRUB files are present or even if the bootloader is installed (which leads me to a question – can we get away with not specifying a bootloader to be installed in anaconda? I imagine not, since that probably means grub2 won’t be installed, but it might be something to look into.)

Though, it does seem to have completely fallen over – pygrub’s not returning any data on a (F14) Xen 4.0.2 system. xm create rawhide.cfg just returns an unhelpful “Error: Boot loader didn’t return any data!”, but trying pygrub directly gives a bit more detail – “RuntimeError: couldn’t find bootloader config file in the image provided.”

Trying with my F16 testbed now…

Also, apparently, radeontool, yum-pluginfastestmirror & ntpdate aren’t present in the F16 repos, so I have to remove them from my Kickstart file.

, ,

No Comments

Revised Fedora virt-install command

I got tired of having to muck around with kpartx and such whenever a domU went down.

So I decided to just go with 4 LVs per domU – root, home, swap and boot.

The command to create the LVs is just one really long one, the original command replicated 4 times:

lvcreate -L10G -n rawhide-root vg_caesium_domUs && lvcreate -L1G -n rawhide-swap vg_caesium_domUs && lvcreate -L10G -n rawhide-home vg_caesium_domUs && lvcreate -L512M -n rawhide-boot vg_caesium_domUs

The virt-install command is somewhat different too – It now specifies the 4 block drives:

virt-install -p -r 512 -n rawhide -f /dev/vg_caesium_domUs/rawhide-boot -f /dev/vg_caesium_domUs/rawhide-root -f /dev/vg_caesium_domUs/rawhide-home -f /dev/vg_caesium_domUs/rawhide-swap -l -x ks="http://hydrogen/~kyl191/ks/ks.php?hostname=rawhide"



No Comments

Win2K8R2 as HVM VM on Xen 4.1

Config file:

Also, it’s working fine without the Xen extensions, though there’s (at least) one unknown device in the device manager)

No Comments

Sudo broken on F16?

I haven’t been able to use sudo on F16Beta on both machines that I upgraded – even though I know sudo worked fine before I upgraded. Not sure why/how it broke…

Turns out SELinux broke it somehow.


No Comments

SELinux, Xen & LVMs

I discovered something new today: SELinux can and does prevent access to logical volumes. This is entirely unexpected for me, because I always thought SELinux only worked on files.

I was wondering why my test VM suddenly refused to start with the error “Disk is not accessible” after I upgraded it to F16Beta. I checked the dom0 logs, and read “couldn’t find bootloader”. At which I promptly went “Oh, crud, grub2 screwed up again!”, and promptly ignored it because it was after midnight.
Then I tried again today. The main difference being that I dropped out of X, and had the screen on when I started up the domU. So I caught these messages:

[  946.283648] avc:  denied  { read } for  pid=3193 comm="xend" name="dm-6"
[  946.690625] avc:  denied  { open } for  pid=3194 comm="pygrub" name="dm-6"

At which point I went “Oh, I see. Oops.”

Simple fix was to disable SELinux with a “setenforce 0” command. More extensive fix would be to:

  1. Find out why SELinux was suddenly enforced OR only just started blocking my Xen disk access
  2. Relabel the LVs so SELinux doesn’t throw a fit.

With regards to relabeling the LVs, the exact problem that SELinux has seems to be this:

scontext=system_u:system_r:xend_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0

The context xend is running under is xend, while the context of the LV is that it’s a fixed disk.

Research says

semanage fcontext -a -t xen_image_t "/dev/mapper/vg_caesium_domU*"

should work, but no guarantees – just did it, and ls -lZ was unchanged. =|

(Filed a bugzilla bug on this:


No Comments

Creating a new RAID 6 drive & attaching it to a Xen VM

I have 4 2TB drives in my NAS. They are split into 2 partitions, 500GB and the remaining ~1.5TB. The 1.5TB partitions were used in a RAID5 for media – music, backups of DVDs, etc. The remaining 500GB partitions were supposed to be for crucial documents, stuff that warranted double protection against disk failure.

Except for the past year, I never got around to creating the RAID6. That changed today.

Read the rest of this entry »

, ,

No Comments