[et-mgmt-tools] Virt-disk-path selection patch and other virt. attributes...
mdehaan at redhat.com
Tue Jul 17 14:37:23 UTC 2007
Adam Rosenwald wrote:
> Thanks, Michael! See inline for comments...
> Michael DeHaan wrote:
>> I've checked in some modifications to the --virt-path code and
>> rearranged it somewhat.
>> To use a standard disk image with koan:
>> leave --virt-path off and assume defaults (like /var/lib/xen/images)
> While observing this (reasonable -- although should be documented in
> Koan (if not already)) default, I think a free-space check is in order
> for the filesystem that contains /var/lib/xen/images. If there is not
> enough free space to accommodate --virt-size, then an error message
> should be printed out. The current (virtinst?) reaction is to let the
> filesystem fill up to 100% and /then* */alert the user about free
> space. This doesn't make sense, and either cobbler/koan or dependency
> libraries should show awareness of this problem.
Patches accepted -- though this should probably this should go in
virtinst as it wouldn't apply just to koan.
>> or specify --virt-path=/path/to/directory
> What will the full virtual path be then? /path/to/directory/<name>?
If there is a specified name chosen on the client with --virt-name=bar,
For a profile: /path/to/directory/$macaddress
For a system: /path/to/directory/$nameofsystemobject
>> or specify --virt-path=/path/to/directory/filename
>> To use an existing partition:
>> specify --virt-path=/dev/sda4, or equivalent
>> To carve out of a chunk of a volume group, of the requested
>> --virt-size, using the name cobbler would ordinarily choose:
>> have an existing LVM volume group named something, such as
>> VolGroup00, with some free space on it
>> specify --virt-path=VolGroup00, or equivalent
>> or be more specific: --virt-path=VolGroup00 --virt-name=asdf
>> (this creates /dev/mapper/VolGroup00/asdf)
> The --virt-name can be confusing with --name. What's wrong with
> --virt-vg=VolGroup00 --virt-lv=asdf? Or --virt-path=VG:[LV]? To make
> the second form clearer, '--virt-path=VolGroup00:' (notice the
> trailing colon) or '--virt-path=VolGroup00:asdf'.
Those arguments are, IMHO, slightly confusing. Partitions start with
"/dev" (example: /dev/sda4), paths start with "/", so it's clear from
the path what the user is intending -- and much easier to
document/understand. It also helps keep koan/cobbler from getting too
many new arguments.
> If you were concerned about the rare case where VolGroup or LogVol
> included a colon in the name (e.g. "VolGroup\:" or "Log\:Vol00"), the
> colon-checking could check for the existence of colons in the actual
> filename and ignore them. Honestly, I don't think anyone would ever
> consciously put a colon in their device name, unless (s)he were mad!
> And this is a reasonable assumption!
While I'm not concerned with that, it also would not cause problems with
the current implementation.
>> Sidenote -- I've tested the above with qemu-kvm and they perform
>> quite well. When virt-manager's next-release supports installing
>> via kickstart locations (like Xen), I'll move the kvm bits over to
>> use virtinst -- until then, qemu-kvm systems created with koan do not
>> show up
>> in virt-manager and you have to use the standard KVM tools for basic
>> management. That should change very shortly.
>> Additionally I've added a --virt-graphics flag to koan which enables
>> VNC in both virt types ("qemu", "xenpv"). virt-graphics is
>> currently not read as a default
> Cool! Should --virt-graphics check for the existence of vnc? Or are
> you satisfied with xenlibs' awkward stack tracing output?
Koan is set to not-require a lot of optional things -- kvm, qemu, xen,
virtinst -- because the user might just be using --replace-self and we
do not want to pull in those dependencies.
>> value from cobbler, but it probably should be. --virt-path and
>> --virt-type can be passed to both koan and cobbler (profile add and
>> system add).
> Awesome! Would you like me to follow your example in implementing the
> other koan virt attributes? Or do you have these covered?
They are already implemented -- see upstream source.
>> et-mgmt-tools mailing list
>> et-mgmt-tools at redhat.com
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
More information about the et-mgmt-tools