Игорь Олемской — практические заметки по системному администрированию Linux CentOS

Самый простой способ «войти» в гостевую систему на Xen это

xm console guest-vm

где guest-vm это нужная гостевая ОС, но тут нам понадобится рутовый или иной административный пароль. Если таким богатством не обладаем то есть вариант такой:
1. останавливаем гостевую машину:

xm shutdown -H guest-vm

2. проверяем остановлен ли гость через несколько минут:

xm list

3. Монтируем образ гостевой ОС и чрутимся в него:

mkdir /root/temp/
mount -o loop /mnt/vm_stor/domains/guest-vm/disk.img /root/temp/
mount -o bind /dev /root/temp/dev/
mount -t proc none /root/temp/proc/
chroot /root/temp/

После выполнения работы, например смены рутового пароля на Xen guest, нужно выйти из чрута, размонтировать и стартануть гостя:

umount /root/temp/dev
umount /root/temp/proc
umount /root/temp
xm create guest-vm

Ну и обязательно проконтролировать загрузку:

xm console guest-vm

If you haven't noticed already, full Xen dom0 support was added in the Linux 3.0 kernel. This means there's no longer a need to drag patches forward from old kernels and work from special branches and git repositories when building a kernel for dom0.

Something else you might not have noticed is that the Fedora kernel team has quietly slipped Linux 3.0 into Fedora 15's update channels in disguise. Click that link, scroll down, and you'll see «Rebase to 3.0. Version reports as 2.6.40 for compatibility with older userspace.» Although I'm not a fan of calling something what it isn't (2.6.40 doesn't exist on kernel.org), I can understand some of the reasoning behind the choice.

This change makes the Xen installation on Fedora 15 pretty trivial. To get started, update your kernel to the latest if you're not already on Fedora's 2.6.40 kernels:

yum -y upgrade kernel

We need three more packages (quite a few dependencies will roll in with them):

yum -y install xen libvirt python-virtinst

The xen package reels in the hypervisor itself along with libraries and command line tools (like xl and xm). Libvirt gives us easy access to VM management with the virsh command and python-virtinst gives us the handy virt-install command to make OS installations easy.

Once those packages are installed, we need to make some adjustments in your grub configuration. Open /boot/grub/menu.lst in your text editor of choice and add something like this at the bottom:

title Fedora + Xen (2.6.40-4.fc15.x86_64)
        root (hd0,1)
	kernel /boot/xen.gz
        module /boot/vmlinuz-2.6.40-4.fc15.x86_64 ro root=/dev/sda1
        module /boot/initramfs-2.6.40-4.fc15.x86_64.img

Ensure that the root (hd0,1) is applicable to your system (adjust it if it isn't). Also, check the kernel version to ensure it matches your installed kernel and adjust the root= portion to match your root volume. Flip the default line to a value which will boot your new grub entry and ensure the timeout is set to a reasonable number if you need to temporarily switch back to your original grub entry at boot time. (Hey, we all make mistakes.)

I take one extra precaution and change the UPDATEDEFAULT=yes line to no in /etc/sysconfig/kernel. This ensures that future kernel updates don't trample the entry you've just made. Keep in mind that you'll need to manually update your grub configuration when you do kernel upgrades later.

Cross your fingers and reboot. If your system doesn't reboot properly, reboot it again and choose your old kernel from the grub menu. Double-check your configuration for fat-fingering and give it another try. If your system boots and pings but you have no output via a monitor, don't fret. There's a patch for the problem which should appear soon in Linux 3.0. The impatient can snag a kernel source RPM, add the patch file, and build a local kernel (or you can download my local build from when I did it).

Log in and verify that you booted into the dom0:

[root@xenbox ~]# xm dmesg | head -n 5
 __  __            _  _    _   _   ____     __      _ ____
 \ \/ /___ _ __   | || |  / | / | |___ \   / _| ___/ | ___|
  \  // _ \ '_ \  | || |_ | | | |__ __) | | |_ / __| |___ \
  /  \  __/ | | | |__   _|| |_| |__/ __/ _|  _| (__| |___) |
 /_/\_\___|_| |_|    |_|(_)_(_)_| |_____(_)_|  \___|_|____/

Once you're done with that, make sure libvirtd is running:

/etc/init.d/libvirtd start; chkconfig libvirtd on

Try installing a VM:

virt-install \
  --paravirt \
  --name=testvm \
  --ram=512 \
  --vcpus=4 \
  --file /dev/vmstorage/testvm \
  --graphics vnc,port=5905 --noautoconsole \
  --autostart --noreboot \
  --location=http://mirrors.kernel.org/debian/dists/squeeze/main/installer-amd64/

You should have a VM installation underway pretty quickly and it will be visible via port 5905 on the local host. Enjoy the power and freedom of your brand new type 1 hypervisor.

Xen 4.1 on Fedora 15 with Linux 3.0 is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Installing Xen can be a bit of a challenge for a beginner and it's made especially difficult by distribution vendors who aren't eager to include it in their current releases. I certainly don't blame the distribution vendors for omitting it; the code to support Xen's privileged domain isn't currently in upstream kernels.

However, href="http://www.xen.org/community/spotlight/pasi.html">Pasi Kärkkäinen has written a href="http://wiki.xensource.com/xenwiki/Fedora13Xen4Tutorial">detailed walkthrough about how to get Xen 4 running on Fedora 13. Although there are quite a few steps involved, it's worked well for me so far.

href="http://rackerhacker.com/2010/09/10/installing-xen-4-on-fedora-13/">Installing Xen 4 on Fedora 13 is a post from: Major Hayden's href="http://rackerhacker.com">Racker Hacker blog. style="display: none; visibility: hidden;">c0b6ad7e-f251-11df-b20b-4040336e00ef

The discussions about the paravirt_ops, or «pvops», support in upstream kernels at Xen Summit 2010 last month really piqued my interest.

Quite a few distribution maintainers have gone to great lengths to keep Xen domU support in their kernels and it's been an uphill battle. Some kernels, such as Ubuntu's linux-ec2 kernels, have patches from 2.6.18 dragged forward into 2.6.32 and even 2.6.33. It certainly can't be enjoyable to keep dragging those patches forward into new kernel trees.

The paravirt_ops support for Xen guests was added in 2.6.23 and continues to be included and improved in the latest kernel trees. However, there are two significant problems with these new kernels if you're trying to work with legacy environments:

• the console is on hvc0, not tty1
• block devices are now /dev/xvdX rather than /dev/sdX

If you only have a few guests, these changes are generally pretty easy. Switching the console just requires some changes to your inittab or upstart configurations. Changing the block device names requires changes to the guest's Xen configuration file and /etc/fstab within the guest itself.

Considering the amount of environments I work with daily at Rackspace, changing the guest configuration is definitely not an option. I needed a way to keep the console and block devices unchanged so that our customers could have a consistent experience on our infrastructure.

Luckily, Soren Hansen offered to pitch in and a solution became apparent. Through some relatively small patches, the legacy console and block device support was available in the latest 2.6.32 version (2.6.32.12 as of this post's writing).

So far, I've tested x86_64 and i386 versions of 2.6.32.12 with the console and block device patches. It's gone through its paces on Xen 3.0.3, 3.1.2, 3.3.0 and 3.4.2. All revisions of Fedora, CentOS, Ubuntu, Debian, Gentoo and Arch made within the last two years are working well with the new kernels.

Legacy tty1 and block device support for Xen guests with pvops kernels is a post from: Major Hayden's Racker Hacker blog.

c0b6ad7e-f251-11df-b20b-4040336e00ef

понадобилось мигрировать OpenVZ контейнер с одной физической машины на другую. Номер контейнера 140 используем vzmigrate

идем на destanation машину и смотрим, есть у нас там vzrst или нет

нету, ну так мы поставим, не проблема

ну вот собственна и всё, снова запускаем миграцию на соурс:

теперь идем на таргет сервер и проверяем

всё, наш контейнер без даунтаймов мигрировал на другой сервер.