If you want support from Novell for your machines you should go for
ESX/ESXi
> I would like to use my RAID as a shared disk for all of my OES servers
> and also have the ability to access the files from SLES and other SLED
> workstations. I was also going to rsync the server RAID to another
> server to have a backup of the data files... 1. Can OES servers mount
> Linux volumes (ReiserFS probably) and then distribute these to
> WinXP/Vista workstations via drive mappings?
Yes, sure.
> 2. Should I access the RAID using iSCSI in the VM's or is there
> another/better solution? (SLES server would be the iSCSI target, the
> OES VMs would be the iSCSI initiators...)
Depends on your needs. Using iSCSI would mean that you are accessing the
RAID on a "hardware-like" level (since iSCSI emulates a SCSI disk). That
would mean that you would need a clustered file system that allows you
to access the disk simultaneously without corruption (OCFS or similar).
An easier solution would be to mount the iSCSI storage on one machine
and then share it to other machines via NFS, SMB, AFP or NCP.
It's also not clear whether this RAID shall host your VM's virtual disk
or if it should just be "attached storage" for your data files.
So depending on your needs the recommendations and possible solutions
would vary.
Thorsten
I would generally advise against using NFS (< v4) in any professional
environment because of the weirdness of its design (stateless) and the
resulting effects. I would go for either SMB or NCP. If installing an
NCP client is not a problem, I would go for NCP.
Thorsten
Thorsten Kampe wrote:
> If installing an
> NCP client is not a problem, I would go for NCP.
And since when can SLES share data via NCP?
CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de
LarryResch wrote:
>
> I am playing with SLES 10.3 to host multiple virtual OES servers via
> vmWare Server.
I hope that "playing" is really waht you do, e.g testing, and that isn't
meant to be a productive setup, right?
> 1. Can OES servers mount Linux volumes (ReiserFS probably) and then
> distribute these to WinXP/Vista workstations via drive mappings?
Sure.
> 2. Should I access the RAID using iSCSI in the VM's or is there
> another/better solution?
There are exactly two solutions through vmware server. Either via iSCSI
(which kills your rsync idea above, in that case all such stuff has to
happen from the VM, and not the host), or vmware virtual disks. What is
"better" depends on your needs.
I have a very similar setup here to test cluster stuff, but again, it's
exclusively for testing. I wouldn't ever use this in production. If what
you plan to do here is for production use, you may want to have a look
at VMWare ESXi for instance.
Thorsten Kampe wrote:
>
> * LarryResch (Tue, 19 Jan 2010 13:36:02 GMT)
> > I am playing with SLES 10.3 to host multiple virtual OES servers via
> > vmWare Server.
>
> If you want support from Novell for your machines you should go for
> ESX/ESXi
Huh? How so?
Larry was talking about OES and OES clients. SLES is just the host for
the VMs. The VMs will be OES.
Thorsten
http://www.novell.com/partners/xen_yes.html
Thorsten
> Larry was talking about OES and OES clients. SLES is just the host for
> the VMs. The VMs will be OES.
The guests will be OES. The host is SLES, and unless I'm
misunderstanding Larry's original post he's looking for a way to get
access to the DAS of the host. Thus NCP isn't an option.
--
Joe Marton
Novell Knowledge Partner
> http://www.novell.com/partners/xen_yes.html
There's a difference between being YES certified versus being supported.
Taken directly from that website:
"The YES Certified logo ensures compatibility, interoperability, quality
and support from both the product vendor and Novell."
VMware won't give any support for VMware Server unless you purchase
support, but Novell still supports running SLES/OES under VMware Server.
It's just not YES certified which means VMware hasn't tested it. That's
all.
> 2. Should I access
> the RAID using iSCSI in the VM's or is there another/better solution?
> (SLES server would be the iSCSI target, the OES VMs would be the iSCSI
> initiators...)
Is VMware Server installed locally on this SLES server or are you using a
remote SLES box as just a storage server for virtualization? If it's
local, then definitely skip iSCSI. You'll have to create a datastore for
VMware Server at a minimum so that you can create virtual disks to
install the guest OSes on. At that point why use iSCSI for the data
drives within the VMs which would require you to do some complicated
stuff with your local storage (single logical drive in the array
partitioned out separately for regular storage vs iSCSI, or create
multiple logical drives in the array, or even other weird stuff) as well
as run the iscsitarget software?
As far as production vs test goes, you probably could do this for
production in a small environment as long as what you run does not
require a lot of disk I/O. But if it's to be production you may want to
look into ESXi which is free as well.
> What does ESX get me
> that vmWare Server does not?
Better performance for one. More comprehensive testing from both Novell
& VMware for another.
> As for the disks, I am leaning to try OES2 on the SLES host to share the
> disk space with the VM's via NSS. IOW, the SLES host would end up being
> the file server for the network but not sure how much that will
> undermine my rsync'ing ability...
Hmm... you won't create NSS volumes directly on the SLES host to share
with the OES2 guests. Rather, just use regular ext3 partitions (or
possibly xfs--haven't ever tried that though) to create the virtual
machines. Then within the VMs themselves create NSS volumes that are
shared with clients.
> The NSS volumes in the VM would show up as
> vmWare disks
Well... sort of the other way around. The VMware disks show up first. :-)
> and I can then manage the partitions holding the vmWare
> disks as Linux files (i.e. rsync for backups etc)... I guess I was
> getting too complicated.
That *may* work but I'm not sure since the files would be in use unless
you had powered off the virtual machines.
> Any issues with moving a VM from vmWare Server to ESX?
Shouldn't be a problem. I've done it a few times here in the past. Just
use VMware Converter and it should go fairly easy.
I heard different from Novell (in that particular case it was
VirtualBox).
That's why I asked him
> > It's also not clear whether this RAID shall host your VM's virtual
> > disk or if it should just be "attached storage" for your data files.
and he responded:
> The RAID that I am playing with would be attached storage for all of
> the VMs data files. The actual VM is being stored in a separate RAID 1
> partition.
Thorstwn
LarryResch wrote:
>
> My hope was that I could use the underlying OS (SLES in this case) for
> managing the VM files (i.e. rsync'g the snapshots to other systems for
> backup)
Make that "snapshot" (singular) if you use VMWare Server (another reason
why this is just suitable for tests, but not productive).
> and also managing the diskspace that the VM's use for data
> (again, rsyncing the partitions holding use data to other systems for
> backup). This would allow me (in theory) to easily move a virtual server
> to other hardware in the case of hardware failure.
Well, that's the whole point of virtualization, yes. However, you wanted
(at least it sounded so), to have the majority of your storage *outside*
of the virualized servers. That sort of kills that idea.
> What does ESX get me that vmWare Server does not? IOW, what risks am I
> accepting using Server?
A whole lot. For one, everything Joe already mentioned. In addition,
ESXi can directly use iSCSI for the VMs, and a lot of other things
VMWare Server just can't do.
> As for the disks, I am leaning to try OES2 on the SLES host to share
> the disk space with the VM's via NSS.
No way, that won't work. You can neither store VMs on NSS, nor can you
"share" the disk space with the VMs in any whatsoever sensible way.
>> The RAID that I am playing with would be attached storage for all of
>> the VMs data files. The actual VM is being stored in a separate RAID 1
>> partition.
Yes, so it seems clear NCP isn't an option.
Clear as mud. He wants to share the direct attached storage via iSCSI
(SLES target). And the OES VMs mount these data partitions as iSCSI
clients. There is no reason why these OES VMs shouldn't be able to share
these partitions via NCP to OES clients. That's what OES is supposed to
do.
Thorsten
> Clear as mud. He wants to share the direct attached storage via iSCSI
> (SLES target).
Yes, but for this to work he needs an iSCSI initiator in the guest. This
means getting the guest OS up and running first, and that will have to be
done by just creating simple VMDKs. See my post to Larry elsewhere in
this thread on the problems he will experience trying to mix this along
with guest-based iSCSI.
> There is no reason why these OES VMs shouldn't be able to share
> these partitions via NCP to OES clients.
Sure. But he can't use NCP on SLES to share the datastore with the
guests as NCP or with clients directly as NCP.