]> http://www.moka5.com/node/51 Comments for "Dependency on VMWare Player, Other Details" en http://www.moka5.com/node/51#comment-712 Can this explanation be included in the FAQ? It should be explained that the cache is sometimes persistent storage of a complete LivePC. Wed, 14 Feb 2007 17:16:23 -0800 http://www.moka5.com/node/51#comment-17 Hi Raj, >> When the VM is updated, since you're managing things at the block level, does the user get only the changed blocks or the whole enchilada? This is actually up to the publisher/creator. By default, only updated blocks are uploaded (by publisher/creator) and downloaded (by end user). However, the LivePC creator may also choose to create a 'deep copy' for a new LivePC or for an update. If you are interested in the details, please read this section on packaging from the creator guide: http://internal.moka5.com/docs/creatorguide#winplay Regards, -Gerald moka5 Team Fri, 18 Aug 2006 08:25:47 -0700 http://www.moka5.com/node/51#comment-16 Wow. With that explanation, I am now genuinely blown away with what you are doing. When the VM is updated, since you're managing things at the block level, does the user get only the changed blocks or the whole enchilada? It almost sounds like your LivePC Library is quasi-torrent tracker. Thu, 17 Aug 2006 17:22:49 -0700 http://www.moka5.com/node/51#comment-15 Lots of good questions there Raj. You are interpreting it correctly that we build on top of VMware's virtualization, providing a new way of managing, distributing, and sharing VMs. To share a VM with the beta software, the VM files (created by the 'Package' command) must be hosted on an HTTP server. Then you "post a new livepc" in our LivePC Library, telling us the URL where your VM is hosted. Our server generates an RSS feed which points to the VM. Why an RSS feed? It is an update mechanism we've implemented for a VM - this is what turns a VM into a LivePC. You can make changes to the VM, put the changes on an HTTP server, and then edit the LivePC entry in our Library. The RSS feed will be updated, and any clients subscribed to the feed for this VM will see the update and begin using the new VM immediately the next time they start it. When you Download a LivePC from our Library and it appears in our client, here's what happens. The client subscribes to that RSS feed and locates the most recent version of the VM. It then starts fetching the VM, block by block, and storing it in a local VM block cache. When you run a VM with our player, it is running out of that cache. If a block is not in cache and you are connected to the network, then the block will be demand paged over the network and stored in the cache. The client is constantly prefetching blocks for the LivePCs you have subscribed to. This is throttled so it should not impact your normal internet usage. We you create a VM using our Package command, optimization information is included so the prefetcher will get the most useful blocks first, such as those needed for bootup and common applications. When you chose to "let me use this offline", you are pinning all blocks associated with that VM in your cache, so they will not be evicted by another VM later if your cache gets full. This guarantees that once the LivePC is fully in cache, it will stay there - making it safe to use the LivePC even without an Internet connection. -Andy Thu, 17 Aug 2006 10:29:44 -0700 http://www.moka5.com/node/51 I'm trying to find a more technical description of LivePC than what's on the "How LivePC Works" page. For instance, why the dependence on VMWare Player? Am I interpreting correctly by saying that you're not competing with VMWare, but building on top of them using their virtualization? Where does the VM actually reside when I share it? Does it reside locally until the remote user chooses the option to "Let me use this offline?" What's actually being downloaded when I connect to one being distributed by moka5 for instance? Wed, 16 Aug 2006 16:12:31 -0700