Jump to content

brian89gp

Members
  • Posts

    173
  • Joined

  • Last visited

Posts posted by brian89gp

  1. Quote from another user:

     

    In the end the best solution would be to create and start / stop those machines using the vSphere CLI - which I already tested.

    The only problem with the free license key for ESXi is that you cannot start / stop them anymore remotely from the command line and so we need a full license if we decide to go with a direct CLI remote start / stop:

    "Fault detail: RestrictedVersionFault"

     

    Figures.  They dangle that damn carrot.

  2. I must admit that the whole concept of snapshots is an absolute dream out of management point of view, so even with only one vm there is benefit .. Allthough I now have 3 (plain unraid, mediabeast for all nntp/torrent stuff and a test unraid I use for preclears and stuff).

     

    Indeed it is.  Just be sure not to forget about them, the snapshot locks the original disk and then starts creating a delta disk for each snapshot.  If it is a high rate of change server these delta's can grow to be quite large and if you run out of space on the volume ESXi will pause all disk IO until you free up some space (most guest OS's will eventually crash if left for any length of time).  Same thing happens if you over provision many thin provisioned disks and they use up all the free space.  Having a 1-2gb 'dummy' file on your host volumes that you can delete in emergencies is very usefull as all other operations other then a hard power off require free disk space to operate.

     

    So, keep an eye on free disk space, and if you have a disk on a guest that does not need snapshotted then make it an independent/persistant disk so that way you don't create snapshots of it in the first place.

     

    One last tip, when commiting large snapshots they will sometimes fail or say sucessfull but not get rid of of the delta vmdk file and it also will no longer show up in snapshot manager.  What you got is an orphaned snapshot.  If this happens create another snapshot and then do a "delete all", it will go through and commit all delta disks even if they are  not showing up as a snapshot in the manager.

  3. Definitely no way to put ESXi to sleep - it was never designed with this in mind, and I would imagine that, even if you could, putting a hypervisor to sleep would have some serious repercussions when you wake it up.

     

    There is a standby mode built into it, if you are running VirtualCenter there is an option to manually put a host into standby and exit standby either by WOL or iLO.  They tie it into the DPM (Dyanamic Power Management) feature in clusters to shut down and boot up hosts on demand to meet/match resource demands to save on power.

     

    You could probably find some method to trigger it through the remote CLI since I would assume they built it into the CLI API.  You would also need to suspend/shut down the guests manually by script since this is normally a task VirtualCenter does before the host standby (the function being to VMotion all guests off).

     

    I've never used it so have no idea how similar it is to normal sleep mode.

  4. The "unknown" is my ASMedia SATA controller, there is 2 on this MB

     

    And your boot time is quick  :D comparing to mine

     

    //Peter

     

    Couple things:

     

    1. VMFS 5 is formated to a 1MB block size, this is normal.

    2. Decrease your CPU to 2 or 3.  Your sig lists you using a 4 core CPU, you are likely to incur some some high CPU wait times just from the hypervisor process running, let alone any other VM.

    3. Remove your floppy and CDROM unless you have a good reason to use it.  Disable it in the BIOS too.

    4. Try removing your APC USB device.

     

    It sounds vaguely like a resource scheduling issue, so try the CPU decrease first.  As a general rule, a VM guest will ONLY run faster with more CPU's if it actually needs them to run, in all other cases adding more CPU's then is needed will slow it down.  Official stance from VMware even is to use only 1 CPU if at all possible.

  5. Might add to add the VMDK as Indepentent - Non Persistent.  That way if you somehow corrupt/delete/format the VMDK from inside UNRAID all you got to do is power cycle the guest and all is well again.

     

    I've also deleted the bzroot/bzimage off of my thumb drive and the config directory off of the VMDK I make so its impossible to get them confused with each other.

  6. I have just bought a IBM M1015 for my new unRAID server. As soon as I receive the card I am going to flash it the usual HBA FW - but!

     

     

    If I one day want to use another OS than unRAID, say windows server 8 maybe, is there then anyway I can reverse the process and get back the original IBM RAID FW?

    Yes. The same way. Almost all the instructions tell you how.

     

    Sent from my SGH-I727R using Tapatalk 2

     

    Though as far as RAID cards go, its not the fastest.

  7. For the purposes of unRaid is there any functional differences between the M1015 and the BR10i?  I'm guessing that once we flash these to just be HBAs, they all pretty much perform the same.  Is that correct?  The M1015 seems to be going for $70-80 on ebay and the BR10i can be had for as little as $40.  Not being real familiar with this kind of tech I'm wondering if there any reason to spend the extra money on the M1015.

     

    The M1015 supports 6gb/s SAS and also larger drives.

  8. There is a website out there that calculates the payoff period for the investment.  Within the past few months it has become more expensive to buy the hardware then could ever be regained by generating bitcoins.

×
×
  • Create New...