On Mon, 2010-01-25 at 13:13 -0800, Dave Scott wrote:
> Hi Anthony,
>
> > Thanks for your quick response,
> >
> > my understanding is driver (maybe in user space) behind /dev/xvda
> > translates raw disk image format to VHD image format on demand, when
> > pygrub works on /dev/xvda
>
> That's correct. When a vhd-based VDI is attached to a domain,
> blktap(kernel-space) + tapdisk(user-space) do the translation from raw disk
> block accesses to vhd read/writes.
What you are talking about is how VM accesses vhd-based disk image. What
I want to know is how pygrub grabs kernel and initrd from vhd-based disk
image, pygrub is running on dom0, there is no /dev/xvda, which is inside
VM.
Anthony
>
> > What I'm doing is,
> >
> > 1. Create a lvm vdi on iscsi SR,
> > 2. dd a vhd file to this vdi,
> > 3. attach this vdi to a (empty)PV vm as device 0(vbd),
> > 4. mark this vbd bootable,
> > 5. then start this vm
>
> Unfortunately this isn't going to work. The choice of whether to use blktap
> (vhd-capable) or blkback (raw device only) is a function of the SR's
> content_type. The 'iscsi' SR uses blkback :(
>
> To see what I mean, try something like this instead:
>
> 1. Create an 'lvmoiscsi' SR
> 2. create a VDI in the new SR
> 3. look inside the new LV -- it should have vhd metadata
>
> Are you trying to import disks in .vhd format? The most future-proof way of
> doing this is to:
> * create a VDI using the API
> * hotplug the VDI into a VM (eg dom0 or a domU)
> * decode the .vhd data, write() it to the raw block device and use seek() to
> preserve sparseness
>
> Simply dd'ing an existing .vhd is risky because XCP is expecting the .vhd to
> have a particular, optimized layout. In particular:
> * extra space is left at the beginning of the file for later resizing
> * parent locators have a particular naming convention
> * blocks are carefully aligned for performance
I understand all you said, but the volume in lvmoiscsi SR seems have the
exact format as VHD file. I'll get back to you after some experimentals
- Anthony
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
|
Home