Re: [Xen-users] "Boot loader did not return any data" to make HVM to PV

[Alexandre Kouznetsov <alk@xxxxxxxxxx>]

Hi.

El 23/10/12 18:27, Flako escribió:
>    What you say is true about following tutorials, I try to follow one
> that "works" :). (sometimes it is difficult to follow when they are
> based on different Linux)
Well, I expected a URL, to take a look on it...

> When you say "consider moving to a more 'native' storage backend" What
> do you mean?
> What is the most native backend?
I guess "raw" (file, or device like LVM's volume) is a better term then 
"native". It allows you to do all sort of things with the storage 
outside of your DomU, like snapshots for backups, access to individual 
partitions, pygrub...
> Normally use tap: qcow2 by the reduction of disk space, is slower than
> raw but for basic use of linux root I think is acceptable.
I just searched for some more reference, and found that apparently 
pygrub does not supports qcow disk images:
https://wiki.heprc.uvic.ca/twiki/bin/view/Main/QCOWSupport
(they have expired SSL cert).
Maybe that's the root of your troubles.

> For intensive use (database or file server) use disk phy+lvm
> Bad idea to combine qcow2 phy and the way I'm doing? which option
> would be better?
I use raw "phy" storage type.

Never tried to combine different storage types (actually, only worked 
with "file" and "phy" over lvm), but it seems to be a good idea to 
maintain this things homogeneous unless there is a *good* reason not to 
do so.
The root FS on my typical Linux PV instance takes less then 2GB. Even if 
a qcow could cut that to the half, I believe it does not worth it.
I guess there are tools to convert from qcow2 to raw image.

--
Alexandre Kouznetsov


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