On 04/05/2013 07:32 PM, Eric Blake wrote: > On 04/05/2013 05:24 PM, John Ferlan wrote: >> On 04/04/2013 03:37 PM, Osier Yang wrote: >>> This adds a new helper qemuTranslateDiskSourcePool which uses the >>> storage pool/vol APIs to tranlsate the disk source before building >> >> s/tranlsate/translate/ >> >>> the drive string. Network volume is not supported yet. Disk chain >>> for volume type disk may be supported later, but before I'm confident >>> it doesn't break anything, it's just disabled now. >> >> >> How would 'network volume' differ from "<disk type='network'"? And all >> the variants therein? >> >> Still trying to figure the 'benefit' of the volume tag since each of the >> types looked up in the pool could also be specified as "<disk >> type='xxx'" types (where xxx is file, block, dir). > > One huge benefit of pool designations is that you can specify a domain > that uses volume "foo" within pool "bar", and migrate it between two > machines where pool "bar" has two different locations for the two > machines (maybe /mnt/nfs/bar on one machine and /longer/path/to/bar on > the other), and the XML on the destination will automatically find the > absolute path to foo relative to the pool bar. If you specify with disk > type='file', you have to specify an absolute path in your XML, and on > migration, if the destination doesn't have the same absolute path, you > are forced to pass alternate xml that you manage yourself to touch up > the path as part of the migration. ahh.. something to consider putting in the domain html file as a reason to use volume as opposed to the other Of course I'd have concerns/thoughts that how do we "ensure" that volume "foo" in "bar" has the same storage considerations on both systems. I understand that's not for this code to decide, but migrating storage that isn't "shared" in some manner (whether that's via some adapter or nfs or something else not yet invented) means some sort of validation takes place on source and destination for "likeness". No sense in trying to migrate a 10g source to a 5g target. John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list