Another potential way to import disks, would be to use HTTP PUT to /import_raw_vdi This destroys sparseness though
On Mon, Jan 25, 2010 at 11:13 PM, Dave Scott <[email protected]>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 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 > > Cheers, > Dave > > > _______________________________________________ > xen-api mailing list > [email protected] > http://lists.xensource.com/mailman/listinfo/xen-api >
_______________________________________________ xen-api mailing list [email protected] http://lists.xensource.com/mailman/listinfo/xen-api
