[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] How to change VM from para-virtualization to full-virtualization?


  • To: xen-users@xxxxxxxxxxxxx
  • From: Alexandre Kouznetsov <alk@xxxxxxxxxx>
  • Date: Thu, 01 Nov 2012 11:21:41 -0600
  • Delivery-date: Thu, 01 Nov 2012 17:23:30 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

Hello.

El 31/10/12 18:54, Jerry Gao escribió:
"3. Re-write your .cfg file within Dom0 to make it start the DomU as HVM."
Which .cfg file are you referring to? Is there an example of it? Thanks.
HVM and PV guests needs different options in the config file. They share some basic variables, such as "name", "memory", etc, but, for example, "root" option has nothing to do in a config for HVM, and "builder" is not suitable for PV mode.

The PV configs I use are generated by Debian's xen-tools, and my HVM regular config has been copied from one place to another multiple times with minor changes, since I build it years ago.
As command reference, i have used this link back then:
http://wiki.prgmr.com/mediawiki/index.php/Appendix_B:_The_Structure_of_the_Xen_Config_File

A quick look around suggests this link as a good start to create own's HVM config:
http://www.virtuatopia.com/index.php/Configuring_and_Installating_a_Xen_Hardware_Virtual_Machine_%28HVM%29_domainU_Guest
(it is one of many, pick whatever you like)

About the 4th step:
"4. Install the boot loader into you DomU storage's MBR, watch the kernel command 
line for root= parameter. I would recommend doing this booting the HVM DomU with a 
LiveCD, Knoppix or systemrescuecd should do fine."
Are you talking about to change the menu.list file of grub? Would you please 
help to give me more details about this step.
A common PV DomU have no grub or menu.lst at all. The bootloader's function (obtain and execute kernel, unpack initrd in DomU's memory) is handled by the hypervisor and controlled from scripts within Dom0. In some cases it's desirable to allow DomU to control what kernel it shall boot, so a special tool "pygrub" is used: it is executed in Dom0, finds the DomU's disk image and extracts from it a minimalistic menu.lst file. That menu.lst mentions a kernel and initrd images that are usually stored in the same disk image, so pygrub extracts them as well. If that is your case, you already have a menu.lst but need to make it usable by a normal Grub.

Recently I had to do something similar, I has do change the paths to the kernel and initrd files, and add parameters "root=/dev/hda2 ro" to the kernel line. Note that menu.lst config is used by legacy Grub, while Grub2 (most commonly encountered this days) uses a completely different format and config filename.

In case of HVM, the boot loading process is more "normal", compared to a bare metal computer. Treat it as any other grub-enabled system. In case of Debian[-based] you might just use update-grub script and it will generate a nice config for you. I mention Grub because it is the most common. Strictly speaking, lilo or syslinux would work well here as well, but you will find less reference about them, specially related to Xen.

About the 5th step:
"5. Modify your /etc/fstab to reflect the change of the block devices naming (from 
/dev/xvdaN to /dev/hda or whatever)."
My previous VM is created on a virtual hard disk like /dev/drbd00. Then do I 
still need to change the storage device name?
Definitely yes.
Even if you pass /dev/drbd00 as is to HVM DomU, it will see it as /dev/hda or whatever you specified in your config file. Boot your DomU with a LiveCD and verify the correct device names.

Also take in account that the common baremetal installations does not put a FS directly on a block device. The block device are partitioned first. For sake of simplicity, Xen PV use to put FS directly on the device: for example, /dev/xvda1 is not the first partition of xvda, instead it's whole device named xvda1, which shares nothing with xvda2. If you use this approach within a HVM, you might confuse it, because it will expect to access FS on partitioned devices.

Another trick is, that legacy Grub can't read ext4 filesystem. Even better, it can't read ext3 filesystem if formatted with inode size of 256 bytes, which is the default for a modern mkfs.ext3. In my case, i had to use "mkfs.ext -I 128" in order to make it work with legacy Grub. Grub2 does not have this problem.


-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxx [mailto:xen-users-bounces@xxxxxxxxxxxxx] 
On Behalf Of Alexandre Kouznetsov
Sent: Wednesday, October 31, 2012 1:30 PM
To: xen-users@xxxxxxxxxxxxx
Subject: Re: [Xen-users] How to change VM from para-virtualization to 
full-virtualization?

Hi.

El 31/10/12 10:27, Jerry Gao escribió:
I've created a domU in para-virtualization. But now I need to change
it to full-virtualization.
Is it possible to upgrade/change the VM virtualization mode without
impact the OS+App in the VM? And How?

Yes, it is possible. Can be a bit tricky because there are many details to take 
care of, even if each of this details is trivial by itself.
  From DomU's point of view, the change will affect the kernel used in the 
DomU, the boot loader and the storage devices naming.

This is a small overview of what need to be done:
1. Make sure your DomU system has a regular kernel and a boot loader installed.
2. Make sure the storage is presented to the DomU as a partitioned block 
device(s).
3. Re-write your .cfg file within Dom0 to make it start the DomU as HVM.
4. Install the boot loader into you DomU storage's MBR, watch the kernel 
command line for root= parameter. I would recommend doing this booting the HVM 
DomU with a LiveCD, Knoppix or systemrescuecd should do fine.
5. Modify your /etc/fstab to reflect the change of the block devices naming 
(from /dev/xvdaN to /dev/hda or whatever).

Word of advice, in many cases it's preferable to re-install the guest system, 
then move data and configs. This way you get a more predictable result.

--
Alexandre Kouznetsov


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users



--
Alexandre Kouznetsov


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.