Hi,
we are in the process of deploying a number of Filers which will provide Storage for VMWARE. To date we have always run CIFS as our Storage has up until now served Windows client requests only. Our new Filers will be running with NFS licensed as opposed to CIFS. As I am a self confessed UNIX illiterate I will want to presist with managing these new Filers from my Windows Clients. I know that ISCSI. which will be licenced. will provide us with some CIFS features such as the ability to register the devices within AD and create CIFS shares which will be read-only. However we will still want to retain the ability to read-write the root volume and in generally manage these devices as we have done until now. I assume to achieve this I will need to install NFS Client software. Does anyone have an recommendations on such client software or any other observations that may be of use to us as we step beyond our familiar boundaries?
Jimmy C.
Windows Services for UNIX?
http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx
Otherwise using rdfile/wrfile (or ftp for this matter) makes wonder ☺
С уважением / With best regards / Mit freundlichen Grüβen
--- Andrey Borzenkov Senior system engineer
________________________________ From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jimmy Corncrake Sent: Wednesday, February 20, 2008 1:22 PM To: toasters@mathworks.com Subject: Accessing a Filer Root Volume from Windows with only NFS Licensed
Hi,
we are in the process of deploying a number of Filers which will provide Storage for VMWARE. To date we have always run CIFS as our Storage has up until now served Windows client requests only. Our new Filers will be running with NFS licensed as opposed to CIFS. As I am a self confessed UNIX illiterate I will want to presist with managing these new Filers from my Windows Clients. I know that ISCSI. which will be licenced. will provide us with some CIFS features such as the ability to register the devices within AD and create CIFS shares which will be read-only. However we will still want to retain the ability to read-write the root volume and in generally manage these devices as we have done until now. I assume to achieve this I will need to install NFS Client software. Does anyone have an recommendations on such client software or any other observations that may be of use to us as we step beyond our familiar boundaries?
Jimmy C.
Hi Jimmy,
On Feb 20, 2008 11:22 AM, Jimmy Corncrake oisintno@gmail.com wrote:
Hi,
we are in the process of deploying a number of Filers which will provide Storage for VMWARE. To date we have always run CIFS as our Storage has up until now served Windows client requests only. Our new Filers will be running with NFS licensed as opposed to CIFS. As I am a self confessed UNIX illiterate I will want to presist with managing these new Filers from my Windows Clients. I know that ISCSI. which will be licenced. will provide us with some CIFS features such as the ability to register the devices within AD and create CIFS shares which will be read-only. However we will still want to retain the ability to read-write the root volume and in generally manage these devices as we have done until now. I assume to achieve this I will need to install NFS Client software. Does anyone have an recommendations on such client software or any other observations that may be of use to us as we step beyond our familiar boundaries?
There is an NFS client available in Windows 2003, you can just add is as a client service to your NIC, should do the job just fine.
Offcourse, the performance is a bit lower than using NFS on a unix server, but since you need it for management tasks only, you should be fine.
Hi
To manage "root" volume from Windows you don't need a CIFS license.
/vol/vol0 is default shared as C$ also without a CIFS license and this permit you i.e. to unzip new Data Ontap releases, manage the /etc files accessing to the filer in workgroup mode and so on (no AD integration without a real CIFS license, if I well remember).
If you need the filers to let VMware servers put their data you can do it with the bundles iSCSI or the NFS (that you've licensed).
For iSCSI with VMware you don't need CIFS to attach to the LUN you will prepare or you don't need to share the volume that will contain those LUNs...(think as opposite to SnapDrive from Windows hosts...in this case you need also CIFS to "see" the volume/lun path to connect/create a disk).
With VMware the only thing you have to do is to create the LUNs and map them to an initiator group containing the iSCSI iqn names of the iSCSI storage adapters created on VMware ESX servers.
Da: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] Per conto di Jimmy Corncrake Inviato: mercoledì 20 febbraio 2008 11.22 A: toasters@mathworks.com Oggetto: Accessing a Filer Root Volume from Windows with only NFS Licensed
Hi,
we are in the process of deploying a number of Filers which will provide Storage for VMWARE. To date we have always run CIFS as our Storage has up until now served Windows client requests only. Our new Filers will be running with NFS licensed as opposed to CIFS. As I am a self confessed UNIX illiterate I will want to presist with managing these new Filers from my Windows Clients. I know that ISCSI. which will be licenced. will provide us with some CIFS features such as the ability to register the devices within AD and create CIFS shares which will be read-only. However we will still want to retain the ability to read-write the root volume and in generally manage these devices as we have done until now. I assume to achieve this I will need to install NFS Client software. Does anyone have an recommendations on such client software or any other observations that may be of use to us as we step beyond our familiar boundaries?
Jimmy C.
Many thanks for your replies. I will look at the Windows Host for Unix as detailed at http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx
With regards registering a non CIFS licensed device in the AD the impression I had was that with CIFS 'lite' installed as part of the ISCSI or FC license this was possible. This is based partially on the solution below which seems to imply this when it states that "CIFS Setup can be run and the filer can be accessed through CIFS".
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb31674
I can test this myself of course but if anyone knows for sure that a non-cifs filer can the registered into a AD it would be good to hear confirmation.
Jimmy
On 2/20/08, Milazzo Giacomo G.Milazzo@sinergy.it wrote:
Hi
To manage "root" volume from Windows you don't need a CIFS license.
/vol/vol0 is default shared as C$ also without a CIFS license and this permit you i.e. to unzip new Data Ontap releases, manage the /etc files accessing to the filer in workgroup mode and so on (no AD integration without a real CIFS license, if I well remember).
If you need the filers to let VMware servers put their data you can do it with the bundles iSCSI or the NFS (that you've licensed).
For iSCSI with VMware you don't need CIFS to attach to the LUN you will prepare or you don't need to share the volume that will contain those LUNs…(think as opposite to SnapDrive from Windows hosts…in this case you need also CIFS to "see" the volume/lun path to connect/create a disk).
With VMware the only thing you have to do is to create the LUNs and map them to an initiator group containing the iSCSI iqn names of the iSCSI storage adapters created on VMware ESX servers.
*Da:* owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] *Per conto di *Jimmy Corncrake *Inviato:* mercoledì 20 febbraio 2008 11.22 *A:* toasters@mathworks.com *Oggetto:* Accessing a Filer Root Volume from Windows with only NFS Licensed
Hi,
we are in the process of deploying a number of Filers which will provide Storage for VMWARE. To date we have always run CIFS as our Storage has up until now served Windows client requests only. Our new Filers will be running with NFS licensed as opposed to CIFS. As I am a self confessed UNIX illiterate I will want to presist with managing these new Filers from my Windows Clients. I know that ISCSI. which will be licenced. will provide us with some CIFS features such as the ability to register the devices within AD and create CIFS shares which will be read-only. However we will still want to retain the ability to read-write the root volume and in generally manage these devices as we have done until now. I assume to achieve this I will need to install NFS Client software. Does anyone have an recommendations on such client software or any other observations that may be of use to us as we step beyond our familiar boundaries?
Jimmy C.
Well, sure, CIFS is actually completely separate from AD. AD is just kerberos + ldap and essentially only passes out tokens that the cifs client & server use to do the authentication phase. My understanding of the limited version of cifs is that most of the non-filerview functionality is there. Drop down to a console/ssh connection and give it a go, and I¹ll bet you¹ll be fine.
-Nick
On 2/20/08 6:15 AM, "Jimmy Corncrake" oisintno@gmail.com wrote:
Many thanks for your replies. I will look at the Windows Host for Unix as detailed at http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx
With regards registering a non CIFS licensed device in the AD the impression I had was that with CIFS 'lite' installed as part of the ISCSI or FC license this was possible. This is based partially on the solution below which seems to imply this when it states that "CIFS Setup can be run and the filer can be accessed through CIFS".
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb31674
I can test this myself of course but if anyone knows for sure that a non-cifs filer can the registered into a AD it would be good to hear confirmation.
Jimmy
On 2/20/08, Milazzo Giacomo G.Milazzo@sinergy.it wrote:
Hi
To manage "root" volume from Windows you don't need a CIFS license.
/vol/vol0 is default shared as C$ also without a CIFS license and this permit you i.e. to unzip new Data Ontap releases, manage the /etc files accessing to the filer in workgroup mode and so on (no AD integration without a real CIFS license, if I well remember).
If you need the filers to let VMware servers put their data you can do it with the bundles iSCSI or the NFS (that you've licensed).
For iSCSI with VMware you don't need CIFS to attach to the LUN you will prepare or you don't need to share the volume that will contain those LUNs(think as opposite to SnapDrive from Windows hostsin this case you need also CIFS to "see" the volume/lun path to connect/create a disk).
With VMware the only thing you have to do is to create the LUNs and map them to an initiator group containing the iSCSI iqn names of the iSCSI storage adapters created on VMware ESX servers.
Da: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] Per conto di Jimmy Corncrake Inviato: mercoledì 20 febbraio 2008 11.22 A: toasters@mathworks.com Oggetto: Accessing a Filer Root Volume from Windows with only NFS Licensed
Hi,
we are in the process of deploying a number of Filers which will provide Storage for VMWARE. To date we have always run CIFS as our Storage has up until now served Windows client requests only. Our new Filers will be running with NFS licensed as opposed to CIFS. As I am a self confessed UNIX illiterate I will want to presist with managing these new Filers from my Windows Clients. I know that ISCSI. which will be licenced. will provide us with some CIFS features such as the ability to register the devices within AD and create CIFS shares which will be read-only. However we will still want to retain the ability to read-write the root volume and in generally manage these devices as we have done until now. I assume to achieve this I will need to install NFS Client software. Does anyone have an recommendations on such client software or any other observations that may be of use to us as we step beyond our familiar boundaries?
Jimmy C.
We are in the preliminary stages of moving our 500 VM system to NFS (from fibre). The goal is to SnapVault everything off site, and I'd like to use A-SIS on our production volumes if at all possible (our VMs are almost identical and 95% reads so this should give us a great level of compression). My question to you is this:
Should I put the swap file on a different VMDK and put that in a different volume? The reasoning behind this is that 1) The swap wants reasonably fast disk and 2) I think that the swap file will not "play nicely" with A-SIS, at least not as nicely as normal data and 3) There is no need to actually waste bandwidth snapping the swap file offsite since it's not needed to recover the machines (as long as in a DR standpoint we create the drive that contained the swap windows will create it at boot).
Thoughts or experiences welcome.
Jeremy M. Page____________________
Systems Architect
* email:Jeremy.Page@gilbarco.com - * phone: 336.547.5399 - 6 fax: 336.547.5163 - * cell: 336.601.7274
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
Page, Jeremy wrote:
We are in the preliminary stages of moving our 500 VM system to NFS (from fibre). The goal is to SnapVault everything off site, and I’d like to use A-SIS on our production volumes if at all possible (our VMs are almost identical and 95% reads so this should give us a great level of compression). My question to you is this:
Should I put the swap file on a different VMDK and put that in a different volume? The reasoning behind this is that 1) The swap wants reasonably fast disk and
Actually, I remember that VMware suggests you use iSCSI (or FC) for swap. I couldn't find any pointers easily, could be my knowledge on this is outdated. But, I would certainly not put swap on the same volume, with or without A-SIS. Swapfiles are a very movable targets, and it's no point snapvaulting them either.
Eino Tuominen wrote:
Should I put the swap file on a different VMDK and put that in a different volume? The reasoning behind this is that 1) The swap wants reasonably fast disk and
Actually, I remember that VMware suggests you use iSCSI (or FC) for swap. I couldn't find any pointers easily, could be my knowledge on this is outdated. But, I would certainly not put swap on the same volume, with or without A-SIS. Swapfiles are a very movable targets, and it's no point snapvaulting them either.
I found it:
http://www.netapp.com/library/tr/3428.pdf
It states:
When configuring virtual machines to run on NFS, it was stated at VMworld 2006 to move the VMware swap file (one is created for each VM) to a VMFS datastore. With NFS deployments an easy no cost solution to this need is to deploy an iSCSI LUN. At the time of writing this document, this recommendation could not be validated. For more information on data layout, including VMware swap file relocation, see “VMware Swap and Log File Data Layout,” later in this document.
I think that's the ESX swap file, I was more thinking of the one for Windows itself. We have almost a TB in swap alone, I hate to replicate that over our WAN link, especially considering it probably has a pretty high rate of change.
Jeremy
-----Original Message----- From: Eino Tuominen [mailto:eino@utu.fi] Sent: Thursday, February 21, 2008 1:09 PM To: Page, Jeremy Cc: Toasters Subject: Re: Mulling over virtual disk layout
Eino Tuominen wrote:
Should I put the swap file on a different VMDK and put that in a different volume? The reasoning behind this is that 1) The swap wants reasonably fast disk and
Actually, I remember that VMware suggests you use iSCSI (or FC) for swap. I couldn't find any pointers easily, could be my knowledge on this is outdated. But, I would certainly not put swap on the same volume, with or without A-SIS. Swapfiles are a very movable targets, and it's no point snapvaulting them either.
I found it:
http://www.netapp.com/library/tr/3428.pdf
It states:
When configuring virtual machines to run on NFS, it was stated at VMworld 2006 to move the VMware swap file (one is created for each VM) to a VMFS datastore. With NFS deployments an easy no cost solution to this need is to deploy an iSCSI LUN. At the time of writing this document, this recommendation could not be validated. For more information on data layout, including VMware swap file relocation, see "VMware Swap and Log File Data Layout," later in this document.
Page, Jeremy wrote:
I think that's the ESX swap file, I was more thinking of the one for Windows itself. We have almost a TB in swap alone, I hate to replicate that over our WAN link, especially considering it probably has a pretty high rate of change.
Well, I can't see any difference between VMware's own swap and a hosted OS's swapfile. Of course, it will complicate configuration a little bit, but with 500 VMs I'm sure you already have some sort of provisioning environment to handle that.
"1) The swap wants reasonably fast disk"
With 500 vms I'd hope you have a decent amount of spindles to play with (it is certainly justified), if the swap needs to be really fast why not carve a dedicated aggregate for them and FC attach them. I don't see how putting the swap luns in a different volume on the same aggregate will make the swap any faster, other than removing ASIS from the equation.
- Hadrian
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Page, Jeremy Sent: Thursday, February 21, 2008 5:04 AM To: Toasters Subject: Mulling over virtual disk layout
We are in the preliminary stages of moving our 500 VM system to NFS (from fibre). The goal is to SnapVault everything off site, and I'd like to use A-SIS on our production volumes if at all possible (our VMs are almost identical and 95% reads so this should give us a great level of compression). My question to you is this:
Should I put the swap file on a different VMDK and put that in a different volume? The reasoning behind this is that 1) The swap wants reasonably fast disk and 2) I think that the swap file will not "play nicely" with A-SIS, at least not as nicely as normal data and 3) There is no need to actually waste bandwidth snapping the swap file offsite since it's not needed to recover the machines (as long as in a DR standpoint we create the drive that contained the swap windows will create it at boot).
Thoughts or experiences welcome.
Jeremy M. Page____________________ Systems Architect * email:Jeremy.Page@gilbarco.com - ( phone: 336.547.5399 - 6 fax: 336.547.5163 - ( cell: 336.601.7274
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
I'm not concerned with making them faster, I just don't see any reason for snapping a TB or so of swap files offsite.
Jeremy M. Page____________________
Systems Architect
* email:Jeremy.Page@gilbarco.com - * phone: 336.547.5399 - 6 fax: 336.547.5163 - * cell: 336.601.7274
________________________________
From: Hadrian Baron [mailto:Hadrian.Baron@vegas.com] Sent: Thursday, February 21, 2008 12:44 PM To: Page, Jeremy; Toasters Subject: RE: Mulling over virtual disk layout
"1) The swap wants reasonably fast disk"
With 500 vms I'd hope you have a decent amount of spindles to play with (it is certainly justified), if the swap needs to be really fast why not carve a dedicated aggregate for them and FC attach them. I don't see how putting the swap luns in a different volume on the same aggregate will make the swap any faster, other than removing ASIS from the equation.
- Hadrian
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Page, Jeremy Sent: Thursday, February 21, 2008 5:04 AM To: Toasters Subject: Mulling over virtual disk layout
We are in the preliminary stages of moving our 500 VM system to NFS (from fibre). The goal is to SnapVault everything off site, and I'd like to use A-SIS on our production volumes if at all possible (our VMs are almost identical and 95% reads so this should give us a great level of compression). My question to you is this:
Should I put the swap file on a different VMDK and put that in a different volume? The reasoning behind this is that 1) The swap wants reasonably fast disk and 2) I think that the swap file will not "play nicely" with A-SIS, at least not as nicely as normal data and 3) There is no need to actually waste bandwidth snapping the swap file offsite since it's not needed to recover the machines (as long as in a DR standpoint we create the drive that contained the swap windows will create it at boot).
Thoughts or experiences welcome.
Jeremy M. Page____________________
Systems Architect
* email:Jeremy.Page@gilbarco.com - * phone: 336.547.5399 - 6 fax: 336.547.5163 - * cell: 336.601.7274
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
If your ESX hosts have local disk, create VMFS partition and put them there. ( this is actually a suggestion in the 3.5 install guide)
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Page, Jeremy Sent: Thursday, February 21, 2008 10:46 AM To: Hadrian Baron; Toasters Subject: RE: Mulling over virtual disk layout
I'm not concerned with making them faster, I just don't see any reason for snapping a TB or so of swap files offsite.
Jeremy M. Page____________________
Systems Architect
* email:Jeremy.Page@gilbarco.com - * phone: 336.547.5399 - 6 fax: 336.547.5163 - * cell: 336.601.7274
________________________________
From: Hadrian Baron [mailto:Hadrian.Baron@vegas.com] Sent: Thursday, February 21, 2008 12:44 PM To: Page, Jeremy; Toasters Subject: RE: Mulling over virtual disk layout
"1) The swap wants reasonably fast disk"
With 500 vms I'd hope you have a decent amount of spindles to play with (it is certainly justified), if the swap needs to be really fast why not carve a dedicated aggregate for them and FC attach them. I don't see how putting the swap luns in a different volume on the same aggregate will make the swap any faster, other than removing ASIS from the equation.
- Hadrian
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Page, Jeremy Sent: Thursday, February 21, 2008 5:04 AM To: Toasters Subject: Mulling over virtual disk layout
We are in the preliminary stages of moving our 500 VM system to NFS (from fibre). The goal is to SnapVault everything off site, and I'd like to use A-SIS on our production volumes if at all possible (our VMs are almost identical and 95% reads so this should give us a great level of compression). My question to you is this:
Should I put the swap file on a different VMDK and put that in a different volume? The reasoning behind this is that 1) The swap wants reasonably fast disk and 2) I think that the swap file will not "play nicely" with A-SIS, at least not as nicely as normal data and 3) There is no need to actually waste bandwidth snapping the swap file offsite since it's not needed to recover the machines (as long as in a DR standpoint we create the drive that contained the swap windows will create it at boot).
Thoughts or experiences welcome.
Jeremy M. Page____________________
Systems Architect
* email:Jeremy.Page@gilbarco.com - * phone: 336.547.5399 - 6 fax: 336.547.5163 - * cell: 336.601.7274
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
You REALLY don't want any kind of swap/temp/paging file on a volume you're going to snapshot, since the data changes often and is useless from a recovery point of view. So you want that on a different volume anyway. If it's ESX swap you're referring to, I agree with Brent, put it on local disk, that way it has a dedicated 100MB/s (or whatever your local drives can write/read at) channel- if you're using swap you're going to slow down anyway, so you'll want to reduce contention for that.
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Brent Wilkinson Sent: Thursday, February 21, 2008 4:14 PM To: Page, Jeremy; Hadrian Baron; Toasters Subject: RE: Mulling over virtual disk layout
If your ESX hosts have local disk, create VMFS partition and put them there. ( this is actually a suggestion in the 3.5 install guide)
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Page, Jeremy Sent: Thursday, February 21, 2008 10:46 AM To: Hadrian Baron; Toasters Subject: RE: Mulling over virtual disk layout
I'm not concerned with making them faster, I just don't see any reason for snapping a TB or so of swap files offsite.
Jeremy M. Page____________________
Systems Architect
* email:Jeremy.Page@gilbarco.com - ( phone: 336.547.5399 - 6 fax: 336.547.5163 - ( cell: 336.601.7274
________________________________
From: Hadrian Baron [mailto:Hadrian.Baron@vegas.com] Sent: Thursday, February 21, 2008 12:44 PM To: Page, Jeremy; Toasters Subject: RE: Mulling over virtual disk layout
"1) The swap wants reasonably fast disk"
With 500 vms I'd hope you have a decent amount of spindles to play with (it is certainly justified), if the swap needs to be really fast why not carve a dedicated aggregate for them and FC attach them. I don't see how putting the swap luns in a different volume on the same aggregate will make the swap any faster, other than removing ASIS from the equation.
- Hadrian
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Page, Jeremy Sent: Thursday, February 21, 2008 5:04 AM To: Toasters Subject: Mulling over virtual disk layout
We are in the preliminary stages of moving our 500 VM system to NFS (from fibre). The goal is to SnapVault everything off site, and I'd like to use A-SIS on our production volumes if at all possible (our VMs are almost identical and 95% reads so this should give us a great level of compression). My question to you is this:
Should I put the swap file on a different VMDK and put that in a different volume? The reasoning behind this is that 1) The swap wants reasonably fast disk and 2) I think that the swap file will not "play nicely" with A-SIS, at least not as nicely as normal data and 3) There is no need to actually waste bandwidth snapping the swap file offsite since it's not needed to recover the machines (as long as in a DR standpoint we create the drive that contained the swap windows will create it at boot).
Thoughts or experiences welcome.
Jeremy M. Page____________________
Systems Architect
* email:Jeremy.Page@gilbarco.com - ( phone: 336.547.5399 - 6 fax: 336.547.5163 - ( cell: 336.601.7274
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
One caveat with ESX is that before 3.5 you could not Vmotion with your swap files on local storage. This is now possible with 3.5.
If you want to isolate your guest OS swap files with ESX just create a separate LUN/VMFS datastore and for every machine you create make a second small drive on that dedicated swap LUN and point your guest OS to utilize that drive as the swap directory.
________________________________
From: Glenn Dekhayser [mailto:gdekhayser@voyantinc.com] Sent: Thursday, February 21, 2008 3:23 PM To: Brent Wilkinson; Page, Jeremy; Hadrian Baron; Toasters Subject: RE: Mulling over virtual disk layout
You REALLY don't want any kind of swap/temp/paging file on a volume you're going to snapshot, since the data changes often and is useless from a recovery point of view. So you want that on a different volume anyway. If it's ESX swap you're referring to, I agree with Brent, put it on local disk, that way it has a dedicated 100MB/s (or whatever your local drives can write/read at) channel- if you're using swap you're going to slow down anyway, so you'll want to reduce contention for that.
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Brent Wilkinson Sent: Thursday, February 21, 2008 4:14 PM To: Page, Jeremy; Hadrian Baron; Toasters Subject: RE: Mulling over virtual disk layout
If your ESX hosts have local disk, create VMFS partition and put them there. ( this is actually a suggestion in the 3.5 install guide)
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Page, Jeremy Sent: Thursday, February 21, 2008 10:46 AM To: Hadrian Baron; Toasters Subject: RE: Mulling over virtual disk layout
I'm not concerned with making them faster, I just don't see any reason for snapping a TB or so of swap files offsite.
Jeremy M. Page____________________
Systems Architect
* email:Jeremy.Page@gilbarco.com - * phone: 336.547.5399 - 6 fax: 336.547.5163 - * cell: 336.601.7274
________________________________
From: Hadrian Baron [mailto:Hadrian.Baron@vegas.com] Sent: Thursday, February 21, 2008 12:44 PM To: Page, Jeremy; Toasters Subject: RE: Mulling over virtual disk layout
"1) The swap wants reasonably fast disk"
With 500 vms I'd hope you have a decent amount of spindles to play with (it is certainly justified), if the swap needs to be really fast why not carve a dedicated aggregate for them and FC attach them. I don't see how putting the swap luns in a different volume on the same aggregate will make the swap any faster, other than removing ASIS from the equation.
- Hadrian
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Page, Jeremy Sent: Thursday, February 21, 2008 5:04 AM To: Toasters Subject: Mulling over virtual disk layout
We are in the preliminary stages of moving our 500 VM system to NFS (from fibre). The goal is to SnapVault everything off site, and I'd like to use A-SIS on our production volumes if at all possible (our VMs are almost identical and 95% reads so this should give us a great level of compression). My question to you is this:
Should I put the swap file on a different VMDK and put that in a different volume? The reasoning behind this is that 1) The swap wants reasonably fast disk and 2) I think that the swap file will not "play nicely" with A-SIS, at least not as nicely as normal data and 3) There is no need to actually waste bandwidth snapping the swap file offsite since it's not needed to recover the machines (as long as in a DR standpoint we create the drive that contained the swap windows will create it at boot).
Thoughts or experiences welcome.
Jeremy M. Page____________________
Systems Architect
* email:Jeremy.Page@gilbarco.com - * phone: 336.547.5399 - 6 fax: 336.547.5163 - * cell: 336.601.7274
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
You can download Services For Unix from Microsoft for free and it will let you map a drive to a NFS share the same was as a CIFS share. Save yourself the CIFS license if this really is only for management.
From a management standpoint you can still you the Computer Management MMC to manage everything.
Jeremy M. Page____________________
Systems Architect
* email:Jeremy.Page@gilbarco.com - * phone: 336.547.5399 - 6 fax: 336.547.5163 - * cell: 336.601.7274
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jimmy Corncrake Sent: Wednesday, February 20, 2008 5:22 AM To: toasters@mathworks.com Subject: Accessing a Filer Root Volume from Windows with only NFS Licensed
Hi,
we are in the process of deploying a number of Filers which will provide Storage for VMWARE. To date we have always run CIFS as our Storage has up until now served Windows client requests only. Our new Filers will be running with NFS licensed as opposed to CIFS. As I am a self confessed UNIX illiterate I will want to presist with managing these new Filers from my Windows Clients. I know that ISCSI. which will be licenced. will provide us with some CIFS features such as the ability to register the devices within AD and create CIFS shares which will be read-only. However we will still want to retain the ability to read-write the root volume and in generally manage these devices as we have done until now. I assume to achieve this I will need to install NFS Client software. Does anyone have an recommendations on such client software or any other observations that may be of use to us as we step beyond our familiar boundaries?
Jimmy C.
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
FWIW - This is changed if you're running Vista. Vista Enterprise and Ultimate include the necessary Unix environment with the OS though they're not installed by default.
Under the "Classic View": Control Panel -> Programs and Features -> Turn Windows features on or off Then look under "Services for NFS" to get just the NFS client.
The filer will treat the system just like a *nix host so anything you want to access will need to be listed appropriately in the exports file. Mount operations are handled from the command line, but go to drive letters just like mapping a CIFS share.
Jeff Mery - MCSE, MCP National Instruments
------------------------------------------------------------------------- "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade -------------------------------------------------------------------------
From: "Page, Jeremy" jeremy.page@gilbarco.com To: "Jimmy Corncrake" oisintno@gmail.com, toasters@mathworks.com Date: 02/21/2008 08:05 AM Subject: RE: Accessing a Filer Root Volume from Windows with only NFS Licensed
You can download Services For Unix from Microsoft for free and it will let you map a drive to a NFS share the same was as a CIFS share. Save yourself the CIFS license if this really is only for management.
From a management standpoint you can still you the Computer Management MMC to manage everything.
Jeremy M. Page____________________ Systems Architect * email:Jeremy.Page@gilbarco.com - ( phone: 336.547.5399 - 6 fax: 336.547.5163 - ( cell: 336.601.7274
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jimmy Corncrake Sent: Wednesday, February 20, 2008 5:22 AM To: toasters@mathworks.com Subject: Accessing a Filer Root Volume from Windows with only NFS Licensed
Hi,
we are in the process of deploying a number of Filers which will provide Storage for VMWARE. To date we have always run CIFS as our Storage has up until now served Windows client requests only. Our new Filers will be running with NFS licensed as opposed to CIFS. As I am a self confessed UNIX illiterate I will want to presist with managing these new Filers from my Windows Clients. I know that ISCSI. which will be licenced. will provide us with some CIFS features such as the ability to register the devices within AD and create CIFS shares which will be read-only. However we will still want to retain the ability to read-write the root volume and in generally manage these devices as we have done until now. I assume to achieve this I will need to install NFS Client software. Does anyone have an recommendations on such client software or any other observations that may be of use to us as we step beyond our familiar boundaries?
Jimmy C. This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
-
Borzenkov, Andrey -
Brent Wilkinson -
Eino Tuominen -
Glenn Dekhayser -
Hadrian Baron -
jeff.mery＠ni.com -
Jimmy Corncrake -
Milazzo Giacomo -
Nicholas Bernstein -
Nils Vogels -
Page, Jeremy