Do you have a sample. I will only be using a limited number of iscsi targets which will be well defined for our organization.
On 2009-02-18 Gary W. Smith wrote:
> Makes sense. I used to use xvd[x] syntax but when I switched to FC8
> my host some time ago it didn't work so I ended up with sd[x]. I've
> updated it a few times so I'm sure it probably works now.
> Problem is that I have this on a countless number of VM's (plus
> templates). If that's what it takes, I guess I will need to do it.
> I was just hoping there was a simpler way to get around this (like
> creating a reserved /dev/sda that does nothing or something so that
> hotplug would skip it.
> Actually, is there a way to block specific ones in hotplug? I
> some time ago (probably years now) there was discussion somewhere
> setting specific hotplug entries for usb mounts. I didn't follow it
> see if there was ever a resolution.
> ps: sorry for top post ... OWA
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx on behalf of Fajar A.
> Nugraha Sent: Wed 2/18/2009 9:05 AM To: Gary W. Smith Cc:
> xen-users@xxxxxxxxxxxxxxxxxxx Subject: Re: [Xen-users] partitions +
> iscsi = mass confusion
> On Wed, Feb 18, 2009 at 11:55 PM, Gary W. Smith <gary@xxxxxxxxxxxxxxx>
>> just fine giving. The problem is that it tries to setup the disk as
>> sda since I don't have a physical sda (as the VM's are already
>> with the direct paritions that I want.
> That's probably one of the reasons why Redhat decided to promote the
> use of xvda for domU's disks instead of hda or sda :)
> Try changing your domU config and fstab to use xvda1, xvda2, etc.
> PS: Personally I use hda :P
A workaround may be to write udev rules to give your iSCSI devices
persistent alternate names. If you are connecting multiple targets then
the device names would change if the order they connected changed. I
have set my system up to create a /dev/iscsi/... device which I
reference instead of the /dev/sd... one.
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Xen-users mailing list