Hi Daniel, [...] > Hum, yes that is different from all other implementations so far. > > But nameserver and hostname feels a bit misplaced. To me nameserver > should go somewhere else, it's kind of a duplicate of the networking stuff. > And what would happen if you have also IPv6, suddenly nameserver structure > breaks. I don't know yet how to best fix this but those two are problematic > as-is. OpenVZ doesn't deal with any kind of devices anyways and since it is a container system, I don't think it will do in the future either. There only one kernel and the host and the guests and thus no device based interfaces between them. Why not do away with the "devices" tag for OpenVZ and rather do something like this: <network> <ipaddress>192.168.1.101</ipaddress> <hostname>fc7-openvz</hostname> <gateway>192.168.1.1</gateway> </network> What do you feel? > > > One of the main reasons many people(especially hosting providers) use > > OpenVZ is since it can be used to provide service level agreements. > > There must be a way to set/get various VPS parameters from libvirt. I > > understand concerns about driver specific code in libvirt based clients > > like virt-manager. The capabilities paradigm will not fit here, since > > this is simply about various properties of the VE/domain, not the > > hardware or the VM capabilities. Please correct me, if I am wrong. So, > > how to we do it? > > piggy-back on virDomainGetSchedulerParameters/virDomainSetSchedulerParameters > that looks like the API flexible enough and closest in spirit. Yeah, I will do this. -- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list