|
Currently evaluating PHDvirtual's 5.4 product here myself, we are a current user of their older esXpress 4 product. The older version has always been rock-stable and hasn't let us down yet. It's pretty fantastic and the licensing and support costs are a steal, in my eyes (licensed per host, quoted for $1045/yr for the first year and $280/yr afterwards for Platinum support.. Probably the biggest reason we're looking at them, beyond being somewhat familiar already with the product. Also, set up was so ridiculously easy. It took me longer to configure the NAS then it did to set up the VBAs only five hosts along with installing the console. And it only took five minutes to configure the NAS... But our situation is a bit different, as we're looking to stay with them and are only playing with new features/features my predecessor didn't use. I looked at Veeam real quick but their licensing costs turned me off right away. Wonder_Bread fucked around with this message at 02:21 on Mar 4, 2012 |
#
¿
Mar 4, 2012 02:17
|
|
|
|
| # ¿ Apr 25, 2024 16:45 |
|
|
Also... The only true flaw (and I don't THINK it's an issue with my network or storage) is that initial backup and replication jobs using PHDvirtual take FOR-loving-EVER. Is this normal? I tested it using direct-attached storage (local disk via datastore) and it was still equally as slow the first time.
|
|
#
¿
Mar 5, 2012 23:16
|
|
|
 click for big I feel as if something is wrong here, but it shouldn't be. Each VBA has 2GB of RAM and two vCPUs. The backups are all being done on an isolated gigabit network with verified near-line speeds. Pushing data to/from the target outside of PHD hits normal speeds. Yet, all my initial backups (and replications) take forever. The selected task has been running since 3pm yesterday... e: Also you can see the weird issue I'm having where it very rarely states speeds and estimated time left. Which further makes me wonder WTF is going on. I've got a call with my sales rep tomorrow and going to try to have him pull an engineer in. Wonder_Bread fucked around with this message at 23:56 on Mar 6, 2012 |
|
#
¿
Mar 6, 2012 23:53
|
|
|
Nevermind. I have no idea. This turned out to not be the problem.
Wonder_Bread fucked around with this message at 03:25 on Mar 7, 2012 |
|
#
¿
Mar 7, 2012 02:14
|
|
|
Apparently my issues with the PHDvirtual software are because I am using CIFS shares, 'cause my Drobo doesn't support multi-target iSCSI or NFS. Ugh... not really sure where to go from here. Don't have any money for storage, already pushing it with trying to get the five grand to get the backup software upgraded.
|
|
#
¿
Mar 9, 2012 17:50
|
|
|
I'm getting faster performance (seeing almost a 1/2 reduction in initial backup time) by switching to NFS on a lovely Cisco NSS4000 NAS. I'm also getting post-processing linking errors fairly frequently. According to the engineer I spoke to, CIFS is the least preferable of the bunch. Next week I am going to rotate the Drobo to a different server (currently hosted on Server 2003, going to try switching it to a Server 2008 R2 box) to see if that cures it, but I don't have high hopes. e: Keep in mind here I am currently stuck using Prosumer technology, which I am sure has something to do with it. Wonder_Bread fucked around with this message at 20:36 on Mar 9, 2012 |
|
#
¿
Mar 9, 2012 20:33
|
|
|
How dangerous is it and/or what should I expect when upgrading ESX from the service console by hand (through SSH)? Right now my hosts are running ESX 4.1.0 build 260247, horribly out of date. I've upgraded my home ESXi server before, but I have never attempted an ESX upgrade, or one that is so far out of date. Can I directly apply the Build 582267 patch? I don't have shared storage (everything is local), my vCenter isn't used for anything beyond looking at all of our hosts in a central location. Also, my vCenter is 4.1.0 build 258902. Does this need to be upgraded in order to keep managing the vHosts? Basically I am worried that somehow doing this is going to backfire on me and something will poo poo the bed.
|
|
#
¿
Mar 12, 2012 15:43
|
|
|
Bitch Stewie posted:This is what's not so clear to me so far. So if I use, say, an E1000, you're saying the OS might report a 1gbps NIC but it can actually transfer data in/out of the vSwitch at greater than 1gbps? I don't believe this is the case at all. It doesn't even make sense to me. The E1000 is an emulated 1Gb Intel NIC, I don't see how it could go faster. In my mind the only reason to not use the VMXNET3 interface is for driver/compatibility issues. Rhymenoserous posted:I have this sudden desire to test this. Using iperf between two of my VMs with VMXNET3 adapters gets me around 9Gb/s.
|
|
#
¿
Apr 17, 2012 23:48
|
|
|
This has been baffling me for days. We use PHD Virtual to do backups. I had an issue last week and another a month ago where during the Snapshot stage of backups, the host machine fails to create them and times out after a few hours. During this, and after the operation times out, the host becomes dog slow and all VMs on it become nearly unusable. Even the host itself crawls to a stop -- it will take 3-5 seconds to log in via SSH, or even run a command. I have no idea why... there is no visible problem as far as we have been able to tell. All performance tracking looks normal, 'esxtop' via SSH shows nothing out of the ordinary, and neither does a regular 'top'. It's making me insane. The only thing that fixes it is a total host reboot. Anyone seen anything like this before? Host is ESX4.1 (Build 260247), for reference. It's making me borderline angry since I can't figure it out and I feel dumb as bricks.
|
|
#
¿
Jun 25, 2012 19:38
|
|
|
|
| # ¿ Apr 25, 2024 16:45 |
|
|
No snapshots were visible or in the datastore folders of the VMs that were being snapshotted. First thing I checked, I thought maybe snapshots went out of control... or maybe it was even still trying to create them. It's also local storage, for reference. It seems that the logs were cleared up on reboot, so I'll need to wait again to get a look. I didn't find anything obvious last time, though.
|
|
#
¿
Jun 25, 2012 20:23
|
|