[virt-tools-list] ostype in virtinst and libvirt

Cleber Rosa crosa at redhat.com
Thu Feb 18 18:32:33 UTC 2010


Elaborating a bit more on the LXC support... 

My idea is to support both system and app containers, but I'm focusing initially on system containers, because they are the most complex. App support would then be trivial. 

I've coded a AnacondaInstaller.py that basically invokes anaconda installing to a directory which would be container root fs. I'm testing a F12 install, which completes sucessfully, but the LXC container initialization is having some quirks, mostly related to device nodes and console /mingetty. I've not implemented any cgroups logic yet, but I do plan on doing that. 

As soon as this is usable, I'll post the code for review. 

Thanks. 

CR. 


--- 
Cleber Rodrigues < crosa at redhat.com > 
Solutions Architect - Red Hat, Inc. 
Mobile: +55 61 9185.3454 

----- Mensagem original ----- 
De: "Cole Robinson" <crobinso at redhat.com> 
Para: "Cleber Rosa" <crosa at redhat.com> 
Cc: virt-tools-list at redhat.com 
Enviadas: Terça-feira, 16 de Fevereiro de 2010 12:47:52 (GMT-0300) Auto-Detected 
Assunto: Re: [virt-tools-list] ostype in virtinst and libvirt 

On 02/16/2010 09:08 AM, Cleber Rosa wrote: 
> Folks, 
> 
> I've been playing around with python-virtinst, with the primary goal of adding an initial round of LXC support to it. 
> 

Sweet, LXC support would be great. 

> While reading the code, I've found that "os_type" is quite misleading. This is already recognized and one example is this comment in virtinst/Guest.py: 
> 
> # GAH! - installer.os_type = "hvm" or "xen" (aka xen paravirt) 
> # guest.os_type = "Solaris", "Windows", "Linux" 
> # FIXME: We should really rename this property to something else, 
> # change it throughout the codebase for readability sake, but 
> # maintain back compat. 
> 
> libvirt also refers to "ostype" all over the place, one example is in conf/capabilities.c: 
> 
> * virCapabilitiesAddGuest: 
> * @caps: capabilities to extend 
> * @ostype: guest operating system type ('hvm' or 'xen') 
> 
> I feel that, even prior to adding LXC support to python-virtinst, I would benefit from learning more about the code while fixing this. I would like to have feedback on a couple of questions: 
> 
> * Should libvirt be targeted also? Would this have any impact on ABI/API stability? 

Like Dan said, this can't be changed for compat reasons 

> * Has a consensus been formed about alternative names for "ostype", "installer.os_type", "guest.os_type" and the like? 
> 

I think os_type/ostype should continue to refer to the <os><type> field 
in the domain XML, and we should change the guest.os_type to 
'distro_type' (and os_variant to distro_variant). Even though this will 
eventually be obsoleted by libosinfo integration, it will improve code 
readability. 

This should be as simple as s/_os_type/_distro_type/g in Guest.py, and 
and adding 

distro_type = property(get_distro_type, set_distro_type) 
# Back compat 
get_os_type = get_distro_type 
set_os_type = set_distro_type 

Probably also want to change virt-install to match. 

Thanks, 
Cole 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20100218/b82e490c/attachment.htm>


More information about the virt-tools-list mailing list