Hello,
I think the relevant code from XendDomainInfo.py _configureBootloader() for
file: mounts looks like this:
mounted = devtype == 'tap' and taptype != 'aio' and taptype !=
'sync' and not os.stat(fn).st_rdev
if mounted:
# This is a file, not a device. pygrub can cope with a
# file if it's raw, but if it's QCOW or other such formats
# used through blktap, then we need to mount it first.
log.info("Mounting %s on %s." %
(fn, BOOTLOADER_LOOPBACK_DEVICE))
vbd = {
'mode': 'RO',
'device': BOOTLOADER_LOOPBACK_DEVICE,
}
from xen.xend import XendDomain
dom0 = XendDomain.instance().privilegedDomain()
dom0._waitForDeviceUUID(dom0.create_vbd(vbd, disk))
fn = BOOTLOADER_LOOPBACK_DEVICE
This is the code that I've mimiced. Here, "BOOTLOADER_LOOPBACK_DEVICE" is
always "/dev/xvdp". But, in the case of 'tap' devices, it gets destroyed later.
(I don't want to destroy it later since the iSCSI mount needs to be kept
around.)
finally:
if mounted:
log.info("Unmounting %s from %s." %
(fn, BOOTLOADER_LOOPBACK_DEVICE))
dom0.destroyDevice('tap', BOOTLOADER_LOOPBACK_DEVICE)
My parallel code is very similar in steps to the tap code, except I need to
read from xenstore after the iSCSI mount is created to find out what the real
device name it was given is. (I can search by its uuid.)
if (access_type == 'iscsi'):
log.info("Mounting %s using %s." % (access_location,
access_type))
from xen.xend import XendDomain
dom0 = XendDomain.instance().privilegedDomain()
# We need a bogus VBD at this point...
vbd = {
'mode': 'RO',
'device': '/dev/null'
}
vbd_uuid = dom0.create_vbd(vbd, disk)
# Now, we need to find out what the REAL device node is, to
pass to the
bootloader
from xen.xend.XendDomain import DOM0_ID
from xen.xend.xenstore.xsutil import GetDomainPath
dom_path = GetDomainPath(DOM0_ID)
real_device = 0
vbds = xstransact.List("%s/backend/vbd/0" % dom_path)
for x in vbds:
uuid = xstransact.Read("%s/backend/vbd/0/%s/uuid" %
(dom_path, x))
if (uuid == vbd_uuid):
found = 1
real_device =
xstransact.Read("%s/backend/vbd/0/%s/node" % (dom
_path, x))
# Swap out the /dev/null now
xstransact.Store("%s/backend/vbd/0/%s" % (dom_path, x),
('dev',
real_device))
break
else:
msg = "Unable to find VBD: %s" % vbd_uuid
log.error(msg)
raise VmError(msg)
msg = "ISCSI Device Detected: %s on %s" % (disk, real_device)
fn = real_device
log.info(msg)
This actually works very well... for one iSCSI boot, because of the dummy
device problem. I may have misunderstood how file: devices work and where that
is handled, so I'll dig further. (And it doesn't seem right that I'm doing this
in the bootloader section, by pygrub needs it that early.) I'm worried that
while this WORKS, that this isn't the right place to be triggering the device
creation. Perhaps, it needs to happen before the call to
_configureBootloader(), either _initDomain() or _constructDomain()...
Thanks,
Joe
----- Original Message -----
From: "Stefan de Konink" <skinkie@xxxxxxxxx>
To: jpranevich@xxxxxxxxxxx
Cc: "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Stephan Seitz"
<s.seitz@xxxxxxxxxxxx>
Sent: Friday, August 22, 2008 5:41:16 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Xen-devel] Almost working iSCSI booting, need advice
jpranevich@xxxxxxxxxxx schreef:
> My big issue involves the creation of the dummy device. It's a
> chicken and egg problem with create_vbd() that I'm not sure how to
> get around. (The hotplug scripts have to run to get the device, but
> need the device to run the hotplug script.) I may be able to fix that
> by simply writing the correct information to the xenstore in the
> right places after I learn them, but I don't know what places need
> updating for the different parts of Xen. (I also haven't tested this
> with Xen-API or migrations, so I may discover more problems if I'm
> not structuring this in the right way.)
Can you show me your code of create_vbd? Because in my code I never
specify any device name. And if you look at file:/// syntax, do you ever
specify /dev/loop0 as filename?
Stefan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home